Hacker News Reader

Comment by ssddanbrown | Hacker News Reader

TinyMCE provided a bit more information about this change in a GitHub discussion thread here: https://github.com/tinymce/tinymce/discussions/9496

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.

View on HN

Would it be out of the question to relicense your project to GPL? I guess you want to allow people to use your work without releasing their source, but that's at odds with the fact that TinyMCE doesn't want that any more and you presumably rely on their work too.

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.

That's definitely an option, but I originally chose the MIT due to the simplicity & low friction/requirement for users, and for me it'd be a shame to change that, especially as it could impact users that have been using my software over the last 8 years. While I've gained a lot of understand & respect for GPL licenses over the years of being involved in open source, I'd still have a preference for MIT for this particular project for the reasons I originally chose it.

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.

I thought when your program/library has a more permissive license you can use a GPL library without changing your license. You just need to make this clear so that someone using your code knows that it also pulls in GPL code and thus they cannot be more restrictive (e.g. closed source) than GPL. Only your program will be MIT licensed, the GPL library stays GPL of course. (And since MIT is more permissive anyone can fork your code and put it under GPL.) Did I misunderstand anything?

There are subtleties, but what I inferred from OP's post was that they modify or extend TinyMCE's code and that they don't want to relicense the modifications. If you just use TinyMCE without modification as a non-essential part of a larger whole it should be fine [0].

[0] https://www.gnu.org/licenses/gpl-faq.en.html#GPLInProprietar...

> I thought when your program/library has a more permissive license you can use a GPL library without changing your license.

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.)

That's generally what LGPL is. It does get a bit murky outside of standard compiled applications though.

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).

You can always make two versions, one with TinyMCE and one without. The one without can be any license you want, while the one with TinyMCE would be provided under GPL.

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.

To me "used in" makes not much sense and I think of it as "used together with", but I might be wrong. Just because main() comes from that one object file and not the other, does that really make so much difference? In my assumption you just have to provide the source and clearly state which parts are under which license. Anyone can fork your MIT code and base their GPL program on it anyway. So providing your program part as MIT should be fine?

Confirming what panzi is saying here, ssddanbrown you do not need to relicense your work. GPL and MIT are compatible. GPL only requires that you distribute the _combined_ work as GPL. So, your github project remains MIT and others can use your code under that license, but when _they_ link to TinyMCE and distribute, that distribution must include source code and also be licensed GPL as a whole.

The “user-does-the-linking” theoretical loophole has been discussed to death on Usenet for decades. The opinion of the FSF (as advised by their lawyers), and the general consensus, is that does not work. If a program A is designed to work connected to, and only connected to, a GPL program B, then program A is considered to be a derived work of A, as evidenced by its unusable state without B.

And that's not what I mean. I understand the linking issue. What I'm saying is that the GPL does not force or require someone to relicense their code. Their code is theirs. They only have to license the distribution as a whole with the GPL to be GPL compliant.

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.

I don’t think that’s true. If a program A is a derived work of B, and B is GPL, I don’t think you are allowed to license A as MIT. It’s legally the same as if you’d taken code from B and altered it; you aren’t allowed to license that under MIT, either.

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>

Your (3) is ssddanbrown's case. The whole must be distributable under the GPL.

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.

What does that mean for proprietary drivers for Linux? They aren't shipped with Linux/a Linux distribution, Nvidia doesn't ship any Linux, but they can only be used with Linux.

It means exactly what you think: Linux cannot permit proprietary drivers. Long ago, someone made a thought experiment and predicted what would happen if proprietary Linux drivers were officially allowed: <https://lwn.net/Articles/162686/>

Unless your users are of the kind who re-distribute your work (or something containing/extending your work - mostly aka software developers) all the time, switching from MIT to GPL is going to be just about no hassle at all to them.

Yeah, it wouldn't affect most users, but some users will be in that group. Plus it may (stupidly) raise legal term alerts for a portion of users it won't affect. As I said, is an option but one with concerns/considerations as per my last comment.

I very briefly took a look at your project and seems to be an entire application, for which I'd expect TinyMCE would be a wrapper around input/textarea fields to add wysiwyg functionality. If that's the case, I (and no sane person/lawyer) would consider your project derivative work, thus except for the need to relicense the code as GPL. If you get that in written even better.

Honestly a better choice for a library would always be LGPL. I don't know how TinyMCE even expects to monetize this thing...

Note that there are two ways to look at derivative works.

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.

> Honestly a better choice for a library would always be LGPL.

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".

Reply on news.ycombinator.com