TinyMCE (also) moving from MIT to GPL
github.comTinyMCE 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.
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/>
See also: <https://www.kernel.org/doc/html/latest/process/stable-api-no...>
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".
In 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 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.
> if modules are designed to run linked together in a shared address space.
How does this not apply to javascript?
That happens after distribution of "unlinked" code. GPL's copyleft doesn't apply to binaries that aren't distributed.
But would bundled and minified JavaScript not be very much like a binary? And isn't it distributed every time someone opens the web page?
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.
> 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?
The GNU FAQ addresses this [1]. If the binaries are communicating intimate information, then they are considered combined. If they can function independently or they are based on open protocols, then they can be considered separate. Ask yourself whether a user can realistically swap in their own binary.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
That should be fine. In this setup you'd essentially have a closed source 'client' talking to a GPL 'server', which is allowed.
I am not so sure about that. I think I remember from a very very old memory that, actually, this specific case has been encountered or discussed and that the answer is no, you aren't allowed to do that. Basically, if you create your own custom protocol etc. You are just reinventing an inefficient wheel, but it's still a wheel. It's still linking.
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."
More or less, it’s what happens to any app that uses a gpl db
I hope Redis's license being changed makes more people wake up to the reality of the differences between copyleft and permissive.
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.
To me, this is, over the long-term, a self-solving problem. Especially for simpler projects.
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.
> There are already forks that are FOSS.
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.
If I'm understanding the changes Redis made, it's FOSS until you decide you want to use their server to create a cloud service offering. Am I mistaken?
Then it isn't FOSS, because it violates freedom 0: The freedom to run the program as you wish
That's my view of FOSS as well; was asking for clarification on that.
It still is, you just have to publish the whole derived work that you created under the SSPL - not just the source to create redis.exe but also the whole source to create the backend of myhostedredisservice.com
I have also personally moved from non-PD permissive licenses for my own works, preferring an explicit public domain dedication or equivalent, and occasionally using a full copyleft license. I do know they are technically different (one important aspect being the patent clause), but the value added by those permissive licenses is not really significant.
Can you please clarify what's the difference between the two?
The way I think of it is that with permissive licences the freedoms can be removed from the code, but with copyleft the freedoms can't be removed from the code. By freedoms I mean the freedom to study the source code, to run it for whatever purpose you want, to make modifications and to share the code with other people.
GPL forces you to always supply the source code but only if you distribute the application.
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.
Another way to look at it is that MIT gives freedom to the developers and GPL gives freedom to the users. It's a conflict between the two groups.
> people have the right to ask you for the source code.
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.
If it's a non-commercial affair, you can give them a "written offer valid for at least 3 years" and then you don't have to actually supply it unless someone asks.
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.
This sounds like a very sane option to take, id like it to be codified in a license. Eternal availability sounds like a real hassle to maintain.
It is codified...
You're right! thanks for the education.
"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."
There 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.
Drew Devault forked Redis, made the fork LGPL, then got so many questions that he created a fun little licensing quiz:
Can anyone explain why the answer to the second question (https://fosstodon.org/@drewdevault/112156847020462949) is "no"? The MIT license grants all the rights that the GPL requires to be granted for derivative works (it is GPL-compatible). Is the problem here just that they don't distribute or offer the source code of the GPL-licensed library along with the pre-built binaries?
The answer to 2) surprises me. I mean, they only said MIT and didn't explicitly state that they provide the source and didn't say that they use a library under GPL. I guess if they provide the source with the binary and make the licenses of the used libraries clear it is ok? Having your part under MIT doesn't change the license of the library. MIT is not more but less restrictive than GPL.
Also shouldn't the answer to 5) be: Depends on what exactly the licenses of the used libraries are, but usually lol no?
> and didn't say that they use a library under GPL.
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."
I see. Thanks!
Yes. The fact that the MIT license is compatible means that the MIT license allows you to fulfill the terms of the GPL—you can fulfill both at the same time. However, fulfilling the (more permissive) terms of the MIT license does not mean that you have fulfilled the terms of the GPL.
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.
I would like to know too. I suspect the question should have been phrased "they offer pre build binaries but no source code".
it is because GPL is viral
https://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean
I'm aware of that, but I'd like to know what specifically violates the GPL in the posed scenario. Your very link states that it's okay to distribute combinations of GPL-licensed code with code licensed under another, GPL-compatible license (which MIT is).
> Your very link states that it's okay to distribute combinations of GPL-licensed code with code licensed under another, GPL-compatible license (which MIT is).
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).
"provided the combination is released under the same GNU GPL version"
That‘s not happening in Drew‘s second scenario.
Confuses me too. Maybe its because they didn't say that the code was also distributed and that they didn't explicitly say that they use a certain library that is under the GPL?
It's the very act of distribution that contains the problem. If you use a GPL'd work in another work, your distribution of the other work must be GPL'd as well. GPL'd part + non-GPL'd-but-compatible part = GPL'd whole, but the parts still exist on their own under their respective original licenses.
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).
I see. Thanks!
But then they will sell you a license to use the whole project including their GPL bits. It's legal, but it's kind of a bait and switch and can be perceived negatively by the community. It's similar to what was done to Akka.
I'm not a lawyer, but my understanding is that I can create a fork of any MIT licensed project right now, and relicense it as GPL. I can't do that the other way around because GPL explicitly forbids it.
> 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
> I can create a fork of any MIT licensed project right now, and relicense it as GPL
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.
The entire work can be licensed under GPL, but those parts that were MIT remain, individually, still under MIT. MIT specifically and explicitly allows for 'sublicense'ing
Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.
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.
> I'm not a lawyer, but my understanding is that I can create a fork of any MIT licensed project right now, and relicense it as GPL
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.
They can't relicense contributions, but they can add new GPL-licensed contributions. That makes the whole work a derivative work in the sense of the GPL, which means the requirements of the GPL apply to all of it. Effectively this is the same as if all the contributions were relicensed under the GPL. The only significant difference is that you can still cut out a part of the code that hasn't been touched by a GPL-licensed contribution and use it under the terms of the MIT license. None of this violates the MIT license of the original contributions, as it allows you to do basically anything, including sublicensing, with the code, provided that you retain the copyright notice.
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.
> You can’t just relicense contributions willy-nilly
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.
IANAL, but this does not cancel the MIT license retroactively. MIT fork is still possible.
They can, because MIT.
I needed a WYSIWYG web editor specifically for HTML[1] and landed on Fastmail's Squire <https://github.com/fastmail/Squire>. It's MIT so you may enjoy it too...
[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
> "It's MIT"
You mean: "It's MIT at the moment", right?
It's also a very "done" software component that sees very few changes, so there's not much downside. TinyMCE feels like a company pushing a v7 just to make you remember they exist.
Recently I was shocked when I came to know that both CKeditor and TinyMCE are now owned by the same parent company. The acquisition has happened silently, that many people think TinyMCE and CKEditor are different competing companies.
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.
Compared to other projects moving to their own weird licenses, GPL2+ isn't the worst outcome. It's interesting to see how the sentiment around open source is changing in the last few years
For 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.
TinyMCE is switching to a licensing model akin to CKeditor's.
What does the change mean if we have TinyMCE editor in our internal CMS tool and we plan on upgrading to version 7?
Probably nothing. An internal tool is not “distributed”, right?
What must one do on their project for GPL