OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.
We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.
We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.
GrapheneOS does include GPLv2 code both via AOSP and our own but not GPLv3. We want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3.
We do need to be careful with GPLv2 due to license incompatibilities. For example, GPLv2-only licensing such as the Linux kernel is incompatible with Apache 2 and GPLv3. GPLv3 is compatible with Apache 2 so GPLv2-or-later can be compatible but only by using it as GPLv3 with the extra restrictions too.
I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.
At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).
That cannot be true, when I install e.g., Ubuntu system, there are plenty of applications installed for me, with incompatible licenses.
OS components don't need to have compatible licenses if they're separate from each other. The Linux kernel is GPLv2-only which forbids GPLv3 licensing. That doesn't mean GPLv3 code can't be used in a Linux-based OS.
We use GPLv2 and permissive licensing for GrapheneOS to avoid more restrictive licensing than the AOSP. We'll happily use GPLv3 and AGPLv3 for components outside of GrapheneOS if we think it's the best fit for specific projects. We aren't currently licensing anything as GPLv3/AGPLv3 but we aren't strictly opposed to it outside of the OS.
We'll use what we think are the best open source licenses for what we want to achieve. What we want to achieve is usually broad adoption of our code with painless usage of it. That means we usually choose permissive licenses. We use GPLv2 in certain cases such as Vanadium where we decided we wanted extensions to our code to be under a compatible open source license instead of a source available license or GPLv3.
There's 5 licenses :o
Can you please elaborate on what you mean?
Ubuntu does not aim to be a permissively-licensed system. It can include copyleft (e.g. GPL) and permissive (e.g. MIT) without issue.
Permissively-licensed systems like FreeBSD and GrapheneOS cannot include GPL code if they want to remain permissive.
GrapheneOS does include GPLv2 code both via AOSP and our own but not GPLv3. We want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3.
We do need to be careful with GPLv2 due to license incompatibilities. For example, GPLv2-only licensing such as the Linux kernel is incompatible with Apache 2 and GPLv3. GPLv3 is compatible with Apache 2 so GPLv2-or-later can be compatible but only by using it as GPLv3 with the extra restrictions too.
1 reply →
It is true, and if Ubuntu is shipping apps as a part of the OS with incompatible licenses, that is a crime.
I think you are confused. You can have a Linux distribution with software with incompatible licenses (e.g. GPLv2 and Apache License version 2), because the license for a particular program or library only applies to that specific work, not other works that it is distributed with. The GPL is very clear on this:
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
There are some cases where a separate work can be considered derivative and thus the GPL can apply. E.g. I think it is generally accepted that a program linked statically against a GPL library is considered a derivative work (and must thus must have a license compatible with the GPL). More controversial is whether dynamic linking creates a derivative work. To cover the latter case, a lot of copyleft libraries are licensed under the LGPL or the GPL with a dynamic linking exception.
At any rate, shipping a Linux distribution with GPLv2 code (e.g. the Linux kernel) and a GUI application that is under the Apache v2 license is not a problem at all (as long as the GUI application is not a derivative of a GPLv2 work).
(IANAL of course, so this is not legal advice.)
Not a crime a civil matter.
IANAL, but I would expect that to fall under "mere aggregation"