Unrelated Question
Hey I have a question, I want to create a repo to post my custom merge methods, I was wondering if I need to use the mergekit license as they would be derivatives perhaps? Also wondering If I would have to put the GNU license in the code. Would it be enough to put the Gnu license in the repo would that be enough? Just wanted a opinion to be careful and such.
First as a disclaimer: I'm not a lawyer and am no expert when it comes to software licenses. If you need legal advice hire an attorney. This is my personal interpretation based on the experience made with open-source projects and could be wrong.
If you copy any source code from a different project you cannot change the license for the code you copied except if you get permission from everyone that contributed to said code. You either license your project under the same license as the code you copied or create a code base with multiple licenses. If you go for multiple licenses make sure to provide all the licenses and clearly specify which license applies to which code. Ideally you would import any code following a different license as shared library/python packet to keep them as separate as possible. Be careful not to violate any of the conditions of any license included in your project. Nothing requires you to put the license in every source code file. It's enough to provide them as separate file in a way everyone looking at your code base or using your products can see them and knows to what part of your code/product they apply. Keep in mind that many open-source licenses require you to provide a copy of the source code if you create derivates of it so should you release a commercial product you will need to provide the source code for those parts of your software to your customers.
Regarding licensing mergekit is a total mess. When I check the source code latest commit changed the license from BUSL to LGPL-3.0. If you use latest master or any future version you will have to license it under LGPL-3.0. If you use master minus one commit (the commit before the license change) you have to license it under BUSL. Keep in mind that if you decide for BUSL you will forever be stuck on master minus one commit and cannot adopt any future upstream changes unless you switch to LGPL-3.0.
If you solely get the idea from them without copying any of their code you are free to license it in any ways you want especially if you are from Europe where software patents are luckily not a thing.
Thank you for the thorough response.
That sounds mostly correct. I'm not a lawyer either, but to my understanding you generally shouldn't be able to mix GPL and proprietary/commercial code in a project, the LGPL is more forgiving as it's good for libraries to include in other things (like a general purpose compression library, etc). The GPL is also considered viral, in that any code derived form it also takes the GPL license as well, which is good for open free projects, but not so good if you don't want that. (If you read stallman's book about how Xerox started with NDA's in order to use their printers and access the drivers back in the 70's?, he was quite annoyed, which likely heavily lent towards how the GPL is written to be this way)
Also it's possible if it's your own creation, you can license it out under different licenses i believe. For example making something available in different programming languages to make it compatible with distribution.
Being able to sell GPL software is a completely unrelated, to my understanding it's totally legal to do so; Though companies that 'sell' their software/OS offer the software free (as an ISO download) and what you're purchasing is technical support in the event you have issues, unlike the usual to grant you permission to use it (RedHat being an easy example).
As for mergekits and training sources... I'd think they should probably be under the same licensing that's used in public programming libraries (so using glibc's qsort or templates won't make FSF or Microsoft own your code for using their compilers/standard libraries). But hopefully that will get solved later if problems arise. For now I'd assume almost everything is simply 'use at your own risk'.
True for GPL/AGPL you really cannot mix them in the same project unless you do inter-process communication and keep them as dedicated applications that interact with each other’s while for LGPL separating the LGPL code as shared library is fine. Yes you can sell GPL/AGPL software but if you do so you obviously need to provide the license and source code and I don't think you can do anything to prevent someone from creating and publishing a fork of it.
As for mergekits and training sources... I'd think they should probably be under the same licensing that's used in public programming libraries
It should be if it is not released as such this is not the case.
using glibc's qsort or templates won't make FSF or Microsoft own your code for using their compilers/standard libraries
If you use a framwork such as the GCC runtime library for standard C functions statically linked into your application you need to follow the license under which they were created. For GCC this is solved using the "GCC Runtime Library Exception" as you can see under https://www.gnu.org/licenses/gcc-exception-3.1.html. If no such an exception exists only GPL code could use GCC.
using glibc's qsort or templates won't make FSF or Microsoft own your code for using their compilers/standard libraries
If you use a framwork such as the GCC runtime library for standard C functions statically linked into your application you need to follow the license under which they were created. For GCC this is solved using the "GCC Runtime Library Exception" as you can see under https://www.gnu.org/licenses/gcc-exception-3.1.html. If no such an exception exists only GPL code could use GCC.
Mhmm. Templates included in the compilers create code from their templates; If you can't write and distribute the software (because you rely on a template, and that makes your code XXX) as you want that's a major problem. I haven't delved that deeply into that. But I'm glad those exceptions are there.
Of course linking into a different library is workable too; I've made/compiled code that hooked into the windows msvcrt.dll instead and compiled as exe's, mostly to avoid including a giant cygwin1.dll (the resulting programs were like 20k in size vs the 1.6Mb). Using alternate libraries work a little differently vs normally so you gotta tweak your code to work correctly. like using fopen the order of the second argument string is far more strict than glibc, but once you get it working it works fine.