TinyMCE (also) moving from MIT to GPL
github.com
github.com
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.
Otherwise, I think it's generally the other way around. Permissive can be used in stronger copy-left licenses, but strongly copyleft libraries can't be used (there's a lot of detail skipped when it comes to what counts as "used" here) in works provided under a more permissive library since a permissive license doesn't provide the terms required by the strong copyleft license (which generally try to ensure freedom of the code, which permissive licenses don't do so well).
See also: <https://www.kernel.org/doc/html/latest/process/stable-api-no...>
You can look at any Linux (or BSD) distribution for hundreds of examples of BSD/MIT code linked to GPL code. The BSD/MIT code packages are not "relicensed" as GPL, but the Linux distribution, as a whole, is distributed as GPL.
The many examples of MIT/BSD linked to GPL code are, I believe, cases of either:
1. The GPL code using the GNU C library exception, like the GNU C library. Or libraries licensed using the LGPL. Any MIT/BSD code is allowed to link with that, because the exception in the licence explicitly permits it.
2. The link is done at “arm’s length”; i.e. the MIT/BSD is not actually requiring the GPL code, and so is not considered a derived work.
or possibly
3. The GPL code is the code which links to the MIT/BSD code, which is obviously allowed, as the whole thing is then distributable under the GPL.
Do you have any examples where none of these are the case?
For futher information, I suggest reading the GPL FAQ: <https://www.gnu.org/licenses/gpl-faq.html>
Nothing changes with ssddanbrown's repo, license, or anything. At a future time should they "code it out" and substitute another non-GPL library, their code is still MIT.
From the GPL FAQ, emphasis mine:
FAQ (#IfLibraryIsGPL): If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
A: Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. See also: What does it mean to say a license is “compatible with the GPL”?
Note, "work as a whole" here means the runnable, binary distribution or downloadable. The source that accompanies the downloadable binary may still be in separate archives with their original licenses. Again, this is exactly how Linux distributions work.
One way many programs do in that situation is to redesign the program with plugins in mind. Those that wish to use a strict set of MIT parts can choose to do so, and those who do not care about licenses can use all parts. A alternative way some program do is to use compile flags, like ffmpeg.
It depend of course how heavily tied to TinyMCE your work is, and if multiple versions are worth it. Forking is always a possibility, but unless there is zero threat vectors I would not go that route.
[0] https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietar...
No, if it meets the definition of a single work (which is the only time the GPL has an effect on licensing the other material at all), the whole thing must licensed under the GPL. Within certain bounds, to allow compatibility, additional restrictions from the upstream licenses may be imposed, and for things you own you may give additional pernissions (but you cannot add permissions to upstream software included, and downstream licensors under the GPL can remove your additional permissions.)
Honestly a better choice for a library would always be LGPL. I don't know how TinyMCE even expects to monetize this thing...
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".
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.
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?
The whole process could even be automated otherwise, nullifying the gpl effectively.
I am NOT a lawyer. And maybe it depends on the country (it seems USA has a very "what-the-law-say-exactly" while France (and maybe Europe) tend to look at the "spirit" of the law.
EDIT more about this question here ? https://news.ycombinator.com/item?id=15105920
EDIT 2:
(Rpc are listed)
https://www.gnu.org/licenses/gpl-faq.en.html
"Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
[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.
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.
People you distributed binaries to have a right to the source code via the same method that the binaries are provided in. Or at least that was my understanding.
In practice, this isn't a very good option to take. Much better to provide it on a "network server" as they were called at the time the license was written.
"b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge."
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.
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.
https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
See Tomte's sibling comment to yours (https://news.ycombinator.com/item?id=39840391) and my own other comment (https://news.ycombinator.com/item?id=39841923).
That‘s not happening in Drew‘s second scenario.
The same answer in the FAQ (https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean) contains a caveat mentioned by Tomte's sibling comment (https://news.ycombinator.com/item?id=39840391): the distribution as a whole must be GPL-licensed.
Suppose that you wrote an MIT-licensed Hello World function (one work) and have a copy of someone else's GPL-licensed FizzBuzz function (a separate work). If you distribute both works together (in the same repository, for example) then the combination (a new work) must be under the same GPL version (or a later version, if the license notice for the FizzBuzz function that function says something like "or any later version" [1].
If you write and then distribute a Fibonacci function which calls someone else's GPL'd add function (or your Fibonacci function body includes code from that GPL'd add function), then your distributed Fibonacci function must be under the same GPL version (or a later one, if the license grant lets you).
Also shouldn't the answer to 5) be: Depends on what exactly the licenses of the used libraries are, but usually lol no?
The situation is exactly that: a GPL library incorporated into an MIT project:
"You wrote a library in Rust and uploaded it to Cargo using the GPL license. Someone grabs it via cargo and uses it in their own project, which is distributed with the MIT license."
A GPL-non-compatible example would be a Business Source License or something non-free. It’s impossible for you to merge a BSL project and a GPL project, because the GPL would require that the result be usable for any purpose, and the BSL would require that the result is not used in production.
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.
> 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.
Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."
I don't think that you believe that, but many developers do.
Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.
Also be aware that sublicensing is not the same as relicensing.
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.
[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.