As I posted there, this directly affects my open source project which is heavily tied to TinyMCE so I may end up forking, and reducing down to what my project needs to reduce maintenance scope & burden.
TinyMCE have been jumping around with their licensing. They were under LGPL, with some (what I believe were) misleading guidance into meeting the LGPL (they specified rules about keeping specific branding elements). They then jumped to MIT, and since moved some of the open plugins to their commercial offering. Now they're making this change.
I certainly don't want to reopen any tired debates, I'm just interested in what the perspective of a downstream developer is like here.
Feels a bit annoying to change the licensing (and philosophy) of my project based upon a change from a dependency (but to be clear I respect their right to change license, and the value they've provided us to this point). Additionally, due to their licensing changes/hijinks over the years, I'm not overly confident there wouldn't be more changes ahead in favour of proprietary enterprise offerings.
Honestly a better choice for a library would always be LGPL. I don't know how TinyMCE even expects to monetize this thing...
You're describing a Venn diagram of two independent circles, LibraryA and AppB, and saying AppB does not use any code internally from LibA, share code, modify code from LibA, etc. From that perspective it's not deriving code from LibraryA. You're not wrong.
The other view is two interlocking puzzle pieces, LibraryA and AppB. Can AppB function without LibA? Is there a standard library API that we can swap those libraries out? Can AppB be built or executed if LibA is not linked at build or runtime? GPL operates at this level and is why LGPL exists. If AppB requires LibA, AppB is derivative. If AppB does not link to LibA as distributed and can function without it, but links only at runtime on the user's system, AppB is not derivative.
That's what they used originally, but I get the impression they want someone a little more forceful to move folks onto their commercial licenses.
> I (and no sane person/lawyer) would consider your project derivative work, thus except for the need to relicense the code as GPL.
I wouldn't consider it a derivative work either, but from what I know that does not matter. TinyMCE is a core part that we also currently distribute with the application. The technical details of GPL combined works can get fuzzy in these contexts as it seems like a lot of it was originally written for compiled code. There are ways we could maybe technically put it at "arms distance" but there are still considerations if users have to add that (currently core) element back in. It can help our distribution but the end result is kind of the same really. This may be more significant in my case since It's a core value to me that this project is very much "batteries included".
But there’s a lot of confusion around the license because it’s not clear how these concepts transfer to interpreted languages. The GNU FAQ for determining if two programs have been combined into a derived works asks “if the modules are included in the same executable file” and “if modules are designed to run linked together in a shared address space.”
If I’m writing a JavaScript library or a server-side framework or even bare metal microcontroller code, I’m not going to use the GPL, just because it’s not at all obvious how to apply the license.
How does this not apply to javascript?
For programs written in interpreted languages, it is a bit less obvious how tightly coupled a program is to their libraries. It depend a lot on the design, intended use and the environment. Some programs regardless of language is going to be heavy dependent and based on a specific library, rather than a generic API for which any library could implement. The more the program incorporates aspects of the library as part of the program, the stronger the argument is for derivative status.
Does it mean I can put GPL code into a separate binary, communicate with it over RPC and use it in a closed-source product without contributing anything back?
[1] https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
Permissive is, in practice, public domain. Any corporation can take your code and use it as closed-source. All they have to do is credit your name somewhere deep in the documentation, a completely meaningless gesture. They also can't sue you for copying "their" library. But that's about it.
It took a decade for GNU/Linux to get to the point where CTOs would throw it in the same category as commercial UNIXes, but when that happened, well... when was the last time you logged into a brand-spankin'-new HP-UX machine?
And that was an operating system, one of the more ambitious types of software projects.
Redis is trading short-term profit for their sustainability as a business. There are already forks that are FOSS; there will be more. Cloud service providers have every incentive to not have to pass on Redis license fees to the customer.
TL;DR: you can't effectively compete over the long-term with the FOSS branches off the trunk that your now-closed-source software branches from.
FWIW Redis is still FOSS since SSPL is FOSS - very strong copyleft. It's not a proprietary license, it's rather "more AGPL than AGPL."
Even if [the OSI](https://opensource.org/sponsors) disagrees.
E.g. if you fork Nano and sell or make binaries available for download for free, people have the right to ask you for the source code.
If you don't distribute it in any form, then you don't need to.[1]
With MIT you can fork, distribute and people can't demand anything.
[1]: Contrary to popular misinformation, modified GPL software can be used by businesses as long as it is not distributed.
Did they all either consent to the repeated license changes or sign away their rights with an CLA?
You can’t just relicense contributions willy-nilly - without an CLA or similar agreement assigning ownership, contributions retain copyright of their original author.
I said the same thing about the recent Redis change. Apparently, the old contributions are still under the old license, and new contributions will be GPL. Because the old license is MIT, those contributions can be incorporated in the new GPL version.
So there the old contributions are not relicensed and there is no need for it. If the old license were GPL and they wanted to move to e.g. BUSL, then they would have to ask all the contributors because GPL doesn't allow that.
> without an CLA or similar agreement assigning ownership, contributions retain copyright of their original author.
Wouldn't that mean that any contribution without an CLA to an open source project is unlicensed? Meaning anybody using a project that appears to be MIT is actually screwed because different parts are owned by different people who can claim infringement since they never explicitly licensed it to you?
EDIT: SLA->CLA :P
A common misunderstanding, but no!
You can incorporate the MIT project into your X-licensed project, and now have three parts you need to consider: the MIT project, your X project and your (presumably x-licensed) composition of the other two projects.
It means, for example, that when distributing your composite project, downstream users do not only have to comply with X, but also with MIT (for that part). So they havbe to reproduce the MIT license (they would not need to do so if you truly relicensed the code!), and they need to distribute the copyright marks of the MIT project etc.
absolutely not, you can't relicense other people's code.
you can combine some MIT code with some GPL code you wrote, though, and the aggregate can be distributed under the intersection of both licenses, which is ~the GPL.
the license of each bit of code is still whatever license it had originally, though.
It's a good thing that the MIT licence allows sublicencing, which means that you can add a single GPL file to a project to immediately relicence it to the GPL as a combined work.
[1]: not just the usual "we have a rich document model" that has plenty of options, but as in my input data is HTML, and conversions back and forth aren't reliable enough
You mean: "It's MIT at the moment", right?
Given that they are from the same governing body, it's no surprise they want to make TinyMCE adopt CKEditor's licensing path as well.
So in other words, corporations are more likely to use code that's licensed under a permissive licence, and so they're more likely to contribute, simply out of their own self interest.
