[quote=PulkoMandy]Yes, you have to distribute the whole kernel under GPL in that case. However, this does not mean you distribute each component of the kernel under GPL. If someone gets your GPL kernel, remove all the source files that are licensed under the GPL and keep only the MIT licensed one, what they get is enough to build another kernel, which is MIT licensed.
In practise, this means we have to distribute the sources under the conditions of the GPL (at the same place where we distribute binaries, and keep them available for a very long time). This is not a big restriction for people downloading from the website (they can use git to get the sources), but is a bit more annoying when it comes to CDs sold and shipped by Haiku, inc. In order to comply with this, our alpha CDs contain the full sourcecode of everything GPLed shipped in there.
So, we don't need to stay completely away from GPLed code, but we try to make it possible to remove/replace it easily and still get a complete running system. This means if someone wants to make a non-free derivative of Haiku, they can start with that work (replacing the GPLed parts). We will accept patches that improve our --enable-gpl-addons configure switch in case we missed something there.[/quote]
Makes sense, thanks for the explanation
That’s not true at all.[/quote]
Why?
That’s not true at all.[/quote]
Why?[/quote]
Kernels generally have a lot of drivers built in. For example, they need to know how to access the screen and keyboard etc, and often will have many other drivers built in. To achieve this the source files (for e.g. drivers, boot code, process scheduler, memory management and all the other things you need to create a kernel) are built into separate object files and then linked together to create one large executable/object file that is executed to start the OS - they are a single program.
Drivers may also be linked to the kernel at run time as modules. In this case, they are a built into an object file that is separate from the kernel and has a special format so that they can be linked at run time. However, once linked, the driver and kernel are a single program. The driver isn’t a program in it’s own right, it requires the kernel to function.
Most drivers support both of these options - linking at kernel compile time or later (at run time).
Basically, you can’t call a library, or a driver, a “program” in their own right, because they can’t be executed alone - they don’t become a program until linked to something else.
In the case of run time linking, from a licensing perspective, it’s a bit more complicated. Some licenses see the binaries to be linked as separate entities and some do not. Linking a driver at run time is similar to the way that libraries are linked to an executable at run time, and in general the libraries may have a different license to the code making use of them. However, the GPL sees no difference between run-time (dynamic) or compile time (static) linking. So anything linked in any way with GPL code should be distributed as GPL. Other licenses vary, the obvious example is the LGPL - this allows a library (or driver) licensed under the LGPL to link to a program (or kernel) that is not GPL.
Then add them (GPL) to Haiku as additional software. Will be fine, I think.
Also BeOS had GNU software in official distro.
I might also add that anything licensed with the more permissive LGPL instead should be able to work in a better fashion alongside other licenses, such as Haiku’s… as it does not have all the requirements of the standard GPL (particularly the GPL v3). I’m only mentioning that as an option to safely integrate outside software, but if anything, it is just an idea…