What must one do on their project for GPL
TinyMCE (also) moving from MIT to GPL
11–20 of 87 posts
Re: TinyMCE (also) moving from MIT to GPL
#12TinyMCE 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…
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.
Re: TinyMCE (also) moving from MIT to GPL
#13In my opinion it’s a shame that the GPL is so clearly designed for licensing applications written in C being run by end users. When evaluated on that basis, it makes a lot of sense as a license. 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 m…
> if modules are designed to run linked together in a shared address space.
How does this not apply to javascript?
Re: TinyMCE (also) moving from MIT to GPL
#14There are 219 contributors going back over a decade.
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.
Re: TinyMCE (also) moving from MIT to GPL
#15TinyMCE 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…
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.
Re: TinyMCE (also) moving from MIT to GPL
#16For my projects I prefer a permissive licence, specifically the MIT No Attribution Licence. People argue that corporations will just take your code and make it proprietary. They might, but an internal fork like that means that it's difficult to benefit from improvements in the original project. So in my experience corporations don't create an internal fork, they use the code as it is. Then if they find a bug for example they will contribute the fix to the project rather than forking, because it's the easiest option.
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.
Re: TinyMCE (also) moving from MIT to GPL
#17There are 219 contributors going back over a decade. 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.
The general understanding is you can relicense MIT to GPL, but not the other way around. MIT has no requirement that you use the same license, only that the permission and attribution notice remains.
Re: TinyMCE (also) moving from MIT to GPL
#18In my opinion it’s a shame that the GPL is so clearly designed for licensing applications written in C being run by end users. When evaluated on that basis, it makes a lot of sense as a license. 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 m…
Programs written in C is a bit more obvious in how tightly coupled a program is to their libraries. It takes quite a lot of intention, work and design to make a C program independent of their library dependencies. If you remove a library and the work is completely inoperative and will practically never function without reapply the library, then the legal argument that they are independent and separate works start to loose strength.
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.
Re: TinyMCE (also) moving from MIT to GPL
#19In my opinion it’s a shame that the GPL is so clearly designed for licensing applications written in C being run by end users. When evaluated on that basis, it makes a lot of sense as a license. 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 m…
> 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.”
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?
Re: TinyMCE (also) moving from MIT to GPL
#20There are 219 contributors going back over a decade. 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.
Do you mean CLA?
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.