Dear community,
with the upcoming release 17.02, we are planning to change Genode's open-source license.
The current GPLv2 license -------------------------
The Genode OS Framework is currently licensed under the terms of the version 2 of the GNU General Public License. We originally picked this license in 2008 for the following reasons:
* It captures the spirit of Free Software, which we deeply share with the FSF. The license ultimately empowers the authors and the end users of software. Genode would not exist without Free Software. It is built on the shoulders of software like GCC, the GNU system, or Linux. All software that we at Genode Labs develop is Free Software.
* At the time of the first Genode release, the GPLv2 was a time-tested and widely used license.
* It enables the dual-licensing business model of Genode Labs. If Genode is commercially leveraged for proprietary solutions, Genode Labs benefits from the success of such products. This way, Genode has a long-term strategy to fund its development without relying on donations, public funding, or venture capital. We value this independence as fundamental for the sustainability of our project.
* Adopting the same license as Linux made a lot of sense because we are routinely reusing Linux driver code inside Genode components.
Affero General Public License -----------------------------
The time did not stand still. The GPLv3 became widely spread and well-understood. It rectifies several shortcomings of the GPLv2. Furthermore, the Affero General Public License [1] closes loopholes of the GPL license with respect to web applications. Unlike 2008 when most applications were programs executed directly on the end user's computer, web applications have become predominant by now.
For Genode, we ignored the deficiencies of the GPLv2 for a long time. At the same time, with more and more software being added to our "ports" - the library of 3rd-party software ported to Genode - the license compatibility question, which we tried to avoid for Linux kernel code, arises for other 3rd-party software that is combined with Genode.
Admittedly, one reason for our hesitance was our fear of long-winded and opinion-loaded discussions around the licensing topic. But we ultimately have to acknowledge that an update to a modern license and a clarification of our stance with respect to the interoperability of Genode with other Open-Source software is long overdue.
The AGPLv3 encapsulates exactly the spirit, which originally attracted us to the GPL. After careful review, it makes perfect sense to use it for Genode. The following Wikipedia article nicely explains the rationale behind this license:
https://en.wikipedia.org/wiki/Affero_General_Public_License
Addressing interoperability concerns ------------------------------------
Unlike most end-user software, which falls into a tangible category (application, library, kernel), Genode plays a special role. Not just because it is an operating system. But it is very unconventional at that: It is a collection of programs (Genode components). It is also a set of application libraries. It is also a "system library". It also comprises a dynamic linker. It may also be the kernel (i.e., our base-hw kernel). The lines between the categories become blurry.
For this reason, we intend to add a linking clause to Genode's version of the AGPL license text, similar to the classpath linking exception but restricted to software licenses that are blessed by the Open-Source Initiative, the Free Software Foundation, or Genode Labs.
Inspired from the text of the classpath linking exception, our clause would look as follows:
Linking Genode code statically or dynamically with other modules is making a combined work based on Genode. Thus, the terms and conditions of the GNU Affero General Public License version 3 (AGPLv3) cover the whole combination.
As an "additional permission" as defined by Section 7 of the AGPLv3, Genode Labs as the copyright holder of Genode gives you permission to link Genode source code with "independent modules" to produce an executable if the independent modules are licensed under an "approved license", and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.
An "approved license" is a license that is officially approved as an Open-Source license by the Open Source Initiative [1], or listed as a Free-Software license by the Free Software Foundation [2], or explicitly approved by Genode Labs.
An "independent module" is a module which is not derived from or based on Genode.
If you modify Genode, you may extend this exception to your version of Genode, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.
[1] https://opensource.org/licenses [2] https://www.gnu.org/licenses/license-list.en.html
With this clause in place, we want to express our consent to use Genode in combination with other open-source software. Note, however, that - unlike the classpath exception clause, our clause excludes the combination of Genode with proprietary software. This is our deliberate decision.
With Genode becoming AGPLv3, we face the question of how to integrate 3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode component. To address this concern, Genode-specific glue code that is needed to integrate the 3rd-party code with the Genode API ("system library") will have a license that is compatible with both the license of the 3rd-party code and Genode's AGPLv3 as such glue code is a derivative of both Genode and the incorporated code, e.g., the MIT license. In line with the wording of the exception clause above, when distributing binaries of such components, the licenses of both Genode and the incorporated 3rd-party code must be respected.
I hope that you support our plan to relicense Genode to AGPLv3 along with our linking exception clause. Should you have doubts about us taking this direction, please let me know.
Best regards Norman
On Wed, Dec 14, 2016 at 10:54:16AM +0100, Norman Feske wrote:
Dear community,
with the upcoming release 17.02, we are planning to change Genode's open-source license.
Fascinating!
For this reason, we intend to add a linking clause to Genode's version of the AGPL license text, similar to the classpath linking exception but restricted to software licenses that are blessed by the Open-Source Initiative, the Free Software Foundation, or Genode Labs.
Sounds good.
Inspired from the text of the classpath linking exception, our clause would look as follows:
Linking Genode code statically or dynamically with other modules is making a combined work based on Genode. Thus, the terms and conditions of the GNU Affero General Public License version 3 (AGPLv3) cover the whole combination.
The AGPLv3 also talks about use of the software over a network service, and I imagine with the focus on IPC and proxying it might be better to clarify this usage too as a combined work. Unless all this doesn't apply to IPC?
With Genode becoming AGPLv3, we face the question of how to integrate 3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode component. To address this concern, Genode-specific glue code that is needed to integrate the 3rd-party code with the Genode API ("system library") will have a license that is compatible with both the license of the 3rd-party code and Genode's AGPLv3 as such glue code is a derivative of both Genode and the incorporated code, e.g., the MIT license. In line with the wording of the exception clause above, when distributing binaries of such components, the licenses of both Genode and the incorporated 3rd-party code must be respected.
This sounds a bit sketch. Could you elaborate more on how this works?
Best regards Norman
Cheers, Jookia.
Hello Jookia,
The AGPLv3 also talks about use of the software over a network service, and I imagine with the focus on IPC and proxying it might be better to clarify this usage too as a combined work. Unless all this doesn't apply to IPC?
Admittedly, I don't completely understand the question. Neither AGPLv3 nor our linking exception mention IPC. The use of IPC is unrelated to licensing.
Let me still try to comment on it: If a custom component uses Genode's IPC mechanism, it is naturally linked against Genode's base libraries and uses Genode's API headers (otherwise, it could not invoke the IPC in the first place). Consequently, when distributing the binary of such a component to a user or providing the component's functionality as a web service to a user, the AGPLv3 requires one to also provide the source code of Genode and the custom source code. Thanks to our exception clause, the latter does not need to be licensed under AGPLv3 (the custom code is not "infected" by the Genode's license). Any "approved" open-source license is fine.
With Genode becoming AGPLv3, we face the question of how to integrate 3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode component. To address this concern, Genode-specific glue code that is needed to integrate the 3rd-party code with the Genode API ("system library") will have a license that is compatible with both the license of the 3rd-party code and Genode's AGPLv3 as such glue code is a derivative of both Genode and the incorporated code, e.g., the MIT license. In line with the wording of the exception clause above, when distributing binaries of such components, the licenses of both Genode and the incorporated 3rd-party code must be respected.
This sounds a bit sketch. Could you elaborate more on how this works?
First, let me point you to the excellent FAQ at gnu.org:
https://www.gnu.org/licenses/gpl-faq.html
I will try to explain the situation with own words and examples. In the following, assume that we want to combine a GPLv2 driver into a Genode component. We also can - for this discussion - regard AGPLv3 as the same as GPLv3.
"Combining" can have different forms that must be distinguished:
* Both licenses (GPLv2 and GPLv3) are known to be mutually incompatible with each other. This means, one is not allowed to copy GPLv2 code snippets into an GPLv3-licensed source code or vice versa. This practice would ultimately "re-license" the code snippet. This is a no-go.
* In practice, 3rd-party code is most often used as an "independent module". For example, when combining a Linux device driver with Genode, the Linux device driver is definitely not a derivate from Genode. Vice versa, Genode is clearly not a derivate of the Linux device driver. Both were developed independent from each other.
In the latter situation, both parts can in principle be combined. But as the resulting binary contains both the Linux driver code and Genode, the licensing terms of both licenses apply. That means, when distributing a binary, one has to provide all the source code that is needed to reproduce the binary from source. This includes the Genode source code and the source code of the Linux driver. In addition, the GPLv3 also requires one to provide the user with the ability to actually use the reproduced binary (look for "tivoization"). In short, it is possible to combine independent modules as long as the license of each individual module is respected.
In practice, when combining such independent modules, some form of glue code is needed to interface both parts. This glue code is typically quite simple, as small as possible, and - in contrast to the glued-together parts - not of great general value. It is ultimately "tainted" by the interfaces of both modules. Hence, the question of license "compatibility" (the first point above) enters the picture.
To go out of the way of possible compatibility concerns, it is a good practice to use a liberal license for such glue code whenever possible. However, this ultimately is a case-by-case decision. For example, consider the Linux device-driver example above. If it is infeasible to craft the glue code without copying some functions and data structures from the Linux kernel code into the glue code, the glue code will naturally inherit Linux' GPLv2 license. But in another situation where clean interfaces exist and the glue code is written completely from scratch, it is reasonable to use a liberal license for the glue code rather than a strict copyleft license like GPLv3. This allows other (non-GPLv3) projects to reuse parts of the glue code, and it avoids any friction when contributing generally useful parts of the glue code to the upstream project.
Could I help to dissolve the "sketchiness" you observed?
Cheers Norman
On Thu, Dec 15, 2016 at 11:39:39AM +0100, Norman Feske wrote:
Hello Jookia,
Admittedly, I don't completely understand the question. Neither AGPLv3 nor our linking exception mention IPC. The use of IPC is unrelated to licensing.
Let me still try to comment on it: If a custom component uses Genode's IPC mechanism, it is naturally linked against Genode's base libraries and uses Genode's API headers (otherwise, it could not invoke the IPC in the first place). Consequently, when distributing the binary of such a component to a user or providing the component's functionality as a web service to a user, the AGPLv3 requires one to also provide the source code of Genode and the custom source code. Thanks to our exception clause, the latter does not need to be licensed under AGPLv3 (the custom code is not "infected" by the Genode's license). Any "approved" open-source license is fine.
I see. How does proprietary userspace code work then?
Could I help to dissolve the "sketchiness" you observed?
Many projects have used the idea of glue code as a way to link proprietary and free software together as a way 'around' the GPL, and this sounds a bit like the same thing. It's questionable if it works though.
Cheers Norman
Greetings
I see. How does proprietary userspace code work then?
Could I help to dissolve the "sketchiness" you observed?
Many projects have used the idea of glue code as a way to link proprietary and free software together as a way 'around' the GPL, and this sounds a bit like the same thing. It's questionable if it works though.
Through magic wrapper, as usual, when one does not want to share sources but should link with open source library.
@Norman: I think many of us are needed in something like decision tree with examples, what and how we should do with source code, how to wrap own code in accordance with the license.
Hi Vasily,
Many projects have used the idea of glue code as a way to link proprietary and free software together as a way 'around' the GPL, and this sounds a bit like the same thing. It's questionable if it works though.
Through magic wrapper, as usual, when one does not want to share sources but should link with open source library.
I am afraid this is a misconception. Thank you for this remark, so I can rectify it.
Genode's open-source license is (and always has been) fundamentally incompatible with proprietary software. This is on purpose.
The switch to AGPLv3 does not change that. Also note that the linking exception that I presented does deliberately not cover proprietary software but is restricted to open-source software.
For using Genode for proprietary purposes, a commercial license can be obtained from Genode Labs. By purchasing such a license, vendors of proprietary products contribute to Genode (and thereby the open-source community), not by the means of code but by the means of funding.
@Norman: I think many of us are needed in something like decision tree with examples, what and how we should do with source code, how to wrap own code in accordance with the license.
If by "your own" code you mean proprietary code, the only plausible approach to combine it with Genode without a commercial license is stuffing your code into a virtual machine. The (virtual) machine interface is an universally accepted license boundary.
Best regards Norman
On Fri, Dec 16, 2016 at 12:02:00AM +0100, Norman Feske wrote:
For using Genode for proprietary purposes, a commercial license can be obtained from Genode Labs. By purchasing such a license, vendors of proprietary products contribute to Genode (and thereby the open-source community), not by the means of code but by the means of funding.
If by "your own" code you mean proprietary code, the only plausible approach to combine it with Genode without a commercial license is stuffing your code into a virtual machine. The (virtual) machine interface is an universally accepted license boundary.
To my understand the GPL and AGPL allow combining with proprietary code as long as you don't convey it to others. Is this wrong?
Jookia.
Hello Jookia,
If by "your own" code you mean proprietary code, the only plausible approach to combine it with Genode without a commercial license is stuffing your code into a virtual machine. The (virtual) machine interface is an universally accepted license boundary.
To my understand the GPL and AGPL allow combining with proprietary code as long as you don't convey it to others. Is this wrong?
I presumed that Vasily intends to actually distribute/deploy his own software. If he keeps it private, he can do whatever he likes.
As a side note, I would prefer to not side-track the discussion too much. For general GPL questions, one may refer to existing and comprehensive resources like the GPL FAQ. Let us keep the discussion focused on Genode's particular case.
Regards Norman
Hi Jookia,
I see. How does proprietary userspace code work then?
please see my reply to Vasily.
Many projects have used the idea of glue code as a way to link proprietary and free software together as a way 'around' the GPL, and this sounds a bit like the same thing. It's questionable if it works though.
I wonder, is this a vague gut feeling or a well-informed concern? If the former, I would very much appreciate you to not spread uncertainty. It is definitely not my intention to work around the GPL!
Genode's license is delicate because Genode plays a number of roles. One particularly important role for this discussion is its role of a "system library". As stated in the GPL FAQ, the GPL acknowledges that system libraries may be proprietary [1]. Even if Genode was solely proprietary, its role of a "system library" would allow the combination of GPL code with it (at least the portions of Genode that correspond to the functionality of a system library).
[1] https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException
If proprietary software is accepted to have this role but GPL software would not because of the GPLv2/v3 incompatibility, this would be a gross contradiction with the spirit of Free Software. Furthermore, with the linking exception clause, we make our stance unmistakably clear that we are fine with linking Free Software - regardless of potential license-version incompatibilities - with Genode.
Please be assured that I'm not careless. In fact, I approached the Free Software Foundation for reviewing my original announcement and incorporated their feedback *before* I sent it to the mailing list.
Regards Norman
On Fri, Dec 16, 2016 at 01:10:56AM +0100, Norman Feske wrote:
If proprietary software is accepted to have this role but GPL software would not because of the GPLv2/v3 incompatibility, this would be a gross contradiction with the spirit of Free Software. Furthermore, with the linking exception clause, we make our stance unmistakably clear that we are fine with linking Free Software - regardless of potential license-version incompatibilities - with Genode.
From my understanding:
The Linux kernel is under the GPLv2 only so the only way to combine code with this is to comply with the GPLv2's terms. The AGPLv3 adds more restrictions than the GPLv2 so it's incompatible.
Independent modules (things equivalent to userspace programs in Linux I guess) are allowed to create executables (this doesn't apply to interpreted languages) that include Genode code under whatever license they like as long as it's using an approved open source license.
Genode will provide a liberal license for code that integrates Linux drivers in to Genode.
Why does the AGPL not apply to the integration code if it uses Genode libraries?
Jookia.
Hello Jookia,
Independent modules (things equivalent to userspace programs in Linux I guess)
Linux has a special preamble to the GPLv2 that defines the kernel interface as a license boundary [1].
[1] https://www.kernel.org/pub/linux/kernel/COPYING
Why does the AGPL not apply to the integration code if it uses Genode libraries?
I think we agree that it should not. More generally, it is not our intention to force-feed the AGPLv3 or any other particular license to Genode-component developers. The choice of the open-source license of a component should be up to the component's developer.
The original version of our linking exception clause is somewhat lacking in this respect. It defines an "independent module" as:
"a module which is not derived from or based on Genode."
This wrongly implies that a component that merely uses the Genode API is not an "independent module". To better express our intention, an "independent module" may better be defined as:
"a module which is not derived from or based on Genode, or merely uses the Genode API as defined in the official documentation."
For example, a component forked from an existing component would not qualify as "independent". But a custom component that interacts with the Genode API without copying non-trivial amounts of Genode code into its own code base would meet the definition of "independent". With non-trivial, I mean code that implements actual functionality as opposed to simple boiler-plate code.
Coming back to the glue-code example, with this clarification in place, it should hopefully be clear that the glue code does not get "tainted" with Genode's AGPLv3, only by the license of the 3rd-party code.
Would that modification make the situation sufficiently clear to you?
Thank you for your scrutiny!
Regards Norman
On Fri, Dec 16, 2016 at 12:27:59PM +0100, Norman Feske wrote:
Hello Jookia,
Hi again :)
Independent modules (things equivalent to userspace programs in Linux I guess)
Linux has a special preamble to the GPLv2 that defines the kernel interface as a license boundary [1].
[1] https://www.kernel.org/pub/linux/kernel/COPYING
Why does the AGPL not apply to the integration code if it uses Genode libraries?
I think we agree that it should not. More generally, it is not our intention to force-feed the AGPLv3 or any other particular license to Genode-component developers. The choice of the open-source license of a component should be up to the component's developer.
The original version of our linking exception clause is somewhat lacking in this respect. It defines an "independent module" as:
"a module which is not derived from or based on Genode."
This wrongly implies that a component that merely uses the Genode API is not an "independent module". To better express our intention, an "independent module" may better be defined as:
"a module which is not derived from or based on Genode, or merely uses the Genode API as defined in the official documentation."
For example, a component forked from an existing component would not qualify as "independent". But a custom component that interacts with the Genode API without copying non-trivial amounts of Genode code into its own code base would meet the definition of "independent". With non-trivial, I mean code that implements actual functionality as opposed to simple boiler-plate code.
Coming back to the glue-code example, with this clarification in place, it should hopefully be clear that the glue code does not get "tainted" with Genode's AGPLv3, only by the license of the 3rd-party code.
Would that modification make the situation sufficiently clear to you?
Yes, that clears it up for me. However, it's unclear to me how this will work with proprietary relicensing of Genode. How will proprietary Genode distributions use GPLv2 code from Linux or other copyleft projects, or do they just not?
Thank you for your scrutiny!
No problem.
Regards Norman
Jookia.
Am I correct that software that doesn't link directly to any AGPLv3 code (e.g. code that just uses libc) is okay to have proprietary licenses? That seems to be the logical interpretation, and probably the most beneficial, as it wouldn't discourage companies from porting their software to Genode.
On Dec 16, 2016 6:43 AM, "Jookia" <166291@...9...> wrote:
On Fri, Dec 16, 2016 at 12:27:59PM +0100, Norman Feske wrote:
Hello Jookia,
Hi again :)
Independent modules (things equivalent to userspace programs in Linux
I guess)
Linux has a special preamble to the GPLv2 that defines the kernel interface as a license boundary [1].
[1] https://www.kernel.org/pub/linux/kernel/COPYING
Why does the AGPL not apply to the integration code if it uses Genode
libraries?
I think we agree that it should not. More generally, it is not our intention to force-feed the AGPLv3 or any other particular license to Genode-component developers. The choice of the open-source license of a component should be up to the component's developer.
The original version of our linking exception clause is somewhat lacking in this respect. It defines an "independent module" as:
"a module which is not derived from or based on Genode."
This wrongly implies that a component that merely uses the Genode API is not an "independent module". To better express our intention, an "independent module" may better be defined as:
"a module which is not derived from or based on Genode, or merely uses the Genode API as defined in the official documentation."
For example, a component forked from an existing component would not qualify as "independent". But a custom component that interacts with the Genode API without copying non-trivial amounts of Genode code into its own code base would meet the definition of "independent". With non-trivial, I mean code that implements actual functionality as opposed to simple boiler-plate code.
Coming back to the glue-code example, with this clarification in place, it should hopefully be clear that the glue code does not get "tainted" with Genode's AGPLv3, only by the license of the 3rd-party code.
Would that modification make the situation sufficiently clear to you?
Yes, that clears it up for me. However, it's unclear to me how this will work with proprietary relicensing of Genode. How will proprietary Genode distributions use GPLv2 code from Linux or other copyleft projects, or do they just not?
Thank you for your scrutiny!
No problem.
Regards Norman
Jookia.
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Ben,
Am I correct that software that doesn't link directly to any AGPLv3 code (e.g. code that just uses libc) is okay to have proprietary licenses?
this is not correct because the proprietary code would still linked to Genode in addition to the libc.
That seems to be the logical interpretation, and probably the most beneficial, as it wouldn't discourage companies from porting their software to Genode.
This statement is interesting because it raises the question of the motives and goals behind Genode. What does "most beneficial" mean? Beneficial to whom? Let me try to look at this question from different perspectives.
1. The Free Software user
For an end user who consciously uses a Free Software ecosystem, proprietary applications are not interesting because they restrict the freedom of the user. Frankly speaking, I am an example of such a user. I have not touched proprietary applications on my computer since several years. But I vividly remember the inconvenience of using opaque installers, the lack of security updates, the inability to fix bugs, or the suspicion about backdoors and vulnerabilities introduced by such applications. The argument that an operating system would be useless without proprietary applications was probably valid 15 years ago. Today, the Free Software world is so strong and diverse that this argument does not hold anymore.
2. The consumer
Many end users are neither aware nor interested in technical details. They just want to get work done, browse the web, play games, or watch movies. From the operating-system's perspective, I also see professionals (like photographers, writers, business users) in this category. A typical consumer uses the OS that comes pre-installed on the device, and accepts the inherent dependency from commercial vendors. The user does not care too much about the uppercase Freedom of software. I am sometimes such a user. E.g., when using my portable audio player, I just want to listen to music.
3. The proprietary application vendor
For a proprietary application vendor, the consumer (2) is a business case. The application vendor wants to create and distribute applications with as little costs as possible and sell them to the consumer at the highest price possible. The latter would not be easily possible if the application vendor published its own "intellectual property" to everyone for free. Hence, the applications tend to stay proprietary to uphold the business case. The application vendor has to consider expenses like paid-for development tools, licenses of commercial libraries, or app-store fees as cost factors. It is clear that proprietary application vendors welcome liberally licensed open-source libraries or platforms for hosting and distributing proprietary software at no costs.
4. The proprietary platform vendor
A vendor may use Genode as the basis of a proprietary platform, for example an appliance designated for a specific market. But such a platform may in principle also be targeted at the consumer mass market. In order to use Genode as the basis of a proprietary platform, the platform vendor obtains a commercial license of Genode. In this case, the choice of Genode's regular open-source license is not a concern for such a platform vendor.
5. The Free Software developer
The motives of Free-Software developers are diverse. But regardless of the motives, they generally improve the lives of Free-Software users. If the software addresses consumer needs, Free-Software developers often find themselves as competing with proprietary applications.
Of course, the categories are not clear-cut. But they help to address two questions: (1) Who would benefit from the ability to host proprietary applications on top of the open-source Genode system, and (2) whom do we want to cater with the open-source license of Genode?
Regarding question (1), only the proprietary application vendor would immediately benefit, but only under the condition that Genode is a platform used by their target audience (consumers). This is of course not the case. Hence, for an application vendor, there is no business case for porting their applications to Genode at all. Instead, application vendors focus on popular end-user platforms like iOS, Android, Windows.
Regarding question (2), with Genode's open-source license, we want to cater Free-Software users and Free-Software developers in the first place. Acknowledging that the open-source Genode system is not a consumer platform as is, there is no benefit in catering the interests of proprietary application vendors with Genode's open-source license.
Please don't get me wrong. I don't dismiss consumers. I see two principle ways of how Genode can reach popularity among consumers, by becoming a consumer platform, or by consumers gravitating towards Free Software. Regarding the former, I am convinced that Genode can become a popular consumer platform only with strong commercial incentives of a platform vendor. Should a platform vendor develop such an interest, it would seek a commercial license. The funding obtained from the commercial licensing would ultimately help Genode and thereby the Free-Software community. The second direction is that consumers would buy products that are solely based on Free Software. Personally, as a Free-Software user, I find this prospect quite exciting.
Given this line of thinking, I hope that you agree that the ability to host proprietary applications on top of the open-source Genode system would not bring any tangible value. But maybe I have overlooked something? Please don't hesitate to share your thoughts.
Regards Norman
Thanks, Norman, for that well-structured review of the proprietary software issue.
One aspect came to mind that I don't see covered, thought. One some platforms, proprietary device drivers are mandatory even on Linux to get certain functionality working. Think of popular 3D graphics cards as an example. The much I'd like to see open source device drivers all over the place (as yourself, I belong to the pure-OSS users category), I'm pessimistic about that. Especially for complex 3D graphics we won't see major vendors release open source driver, let alone proper documentation.
Still, it would be highly beneficial for any kind of user to have these proprietary binary-only drivers on Genode instead of other platforms. In contrast to Linux kernel modules, we can run them as unprivileged users space process, set up IO virtualization etc.
(How) can proprietary binary-only drivers be included in the open source version of Genode under the new license scheme?
Cheers, Alex
On 17.12.2016 16:37, Norman Feske wrote:
Given this line of thinking, I hope that you agree that the ability to host proprietary applications on top of the open-source Genode system would not bring any tangible value. But maybe I have overlooked something? Please don't hesitate to share your thoughts.
Hi Alexander,
* Alexander Senier <alex@...331...> [2016-12-18 13:02:15 +0100]:
One aspect came to mind that I don't see covered, thought. One some platforms, proprietary device drivers are mandatory even on Linux to get certain functionality working. Think of popular 3D graphics cards as an example. The much I'd like to see open source device drivers all over the place (as yourself, I belong to the pure-OSS users category), I'm pessimistic about that. Especially for complex 3D graphics we won't see major vendors release open source driver, let alone proper documentation.
Do not use this platform then. I know, easier said than done but you have to start somewhere and in the end it is actually that simple. Not buying hardware that requires proprietary device drivers is certainly a start and may point vendors into the “right” direction by showing that customers care about those things. (I fear this is the perfect topic to de-rail the thread so I am going to stop here ☺)
Still, it would be highly beneficial for any kind of user to have these proprietary binary-only drivers on Genode instead of other platforms. In contrast to Linux kernel modules, we can run them as unprivileged users space process, set up IO virtualization etc.
That would be beneficial indeed. However, before vendors care about other systems, there has to be an incentive. For example look at Sailfish OS — they have to wrap Android user space drivers to use them on there glibc based system because nowadays Android is the only system a certain group of vendors cares about. My best guess is that Android currently is the only relevant market to them. So what would be the incentive to provide proprietary drivers for Genode in the first place? For better or worse I do not see any and a Genode “end user” presumably does not care much about proprietary drivers anyway. At least that is what I assume given the fact the current Genode “end users”, according to my perception, value having a open/free/libre/whatever system.
Now a user of the Genode framework, as in someone who builds a system or rather a product with Genode, may care about having support for a certain piece of hardware where only a proprietary binary-only driver is provided by the vendor. But again, the vendor will not provide the driver for Genode out of the blue without a given incentive. In this case the user can pay the vendor to provide the driver (and also has to pay for future updates). If it is a proprietary product there is already a commercial Genode license involved and everything is fine. If it is a non-proprietary product, that obviously is a problem because the binary only driver may not be used (the most fitting example that comes to my mind is someone who wants to use the open-source version of Genode in an automotive context using NVidias Terga Drive platform and has to hire NVidia to port their binary-only driver to Genode).
That being said, in any case, I do not think that the license itself is a reason that prevents people from using Genode.
(How) can proprietary binary-only drivers be included in the open source version of Genode under the new license scheme?
No but that was also the case under the old license — switching to AGPLv3 does not change anything in that regard.
Given that, the only example I can come up with from my personal requirements would be GPU and to some extent GSM/LTE drivers (a well documented smartphone SoC for running Genode would be great). In the former case I would mostly need them to run proprietary binary-only software that is not available for Genode anyway and again I see no incentive for publishers to change that for now, even if the license would permit it. We probably will never have a native Netflix client on Genode either as long as it depends on proprietary binary-only DRM component. I can, however, use Chrome on Linux in a VM on Genode which works well enough. So for me do not having proprietary software is a non-issue and quite frankly I would rather not add another exception to the license prematurely because “it would be nice to have the chance of having XY on Genode”. In the past nobody cared about not having proprietary software on Genode but rather some people cared about being not able to use open source software because of the missing exceptions for other open source licenses.
I probably see the matter to strict but for me Genode as a project first and foremost follows the open-source or rather free software values which is made clear by the choice of the license and proprietary sofware (e.g. by using a commercial license) is only used to fund the development. Being open source benefits “any kind of user” of a Genode system in the long run.
Regards Josef
On Sun, Dec 18, 2016 at 04:03:47PM +0100, Josef Söntgen wrote:
Now a user of the Genode framework, as in someone who builds a system or rather a product with Genode, may care about having support for a certain piece of hardware where only a proprietary binary-only driver is provided by the vendor. But again, the vendor will not provide the driver for Genode out of the blue without a given incentive. In this case the user can pay the vendor to provide the driver (and also has to pay for future updates). If it is a proprietary product there is already a commercial Genode license involved and everything is fine. If it is a non-proprietary product, that obviously is a problem because the binary only driver may not be used (the most fitting example that comes to my mind is someone who wants to use the open-source version of Genode in an automotive context using NVidias Terga Drive platform and has to hire NVidia to port their binary-only driver to Genode).
Shouldn't the user be able to buy a product, rip the proprietary code out and use that in their free version?
Hello Jookia,
How will proprietary Genode distributions use GPLv2 code from Linux or other copyleft projects, or do they just not?
under the commercial license, Genode is an ingredient of a proprietary operating system, let's call it "Vendor OS". The Vendor OS comes with a proprietary system library. The fact that this proprietary system library is somehow based on Genode does not matter. The end user only sees the Vendor OS, not Genode.
So your question can be more generally stated as "Can a proprietary operating use GPL software?". The answer is obviously yes. E.g., before the Linux kernel was born, GNU was primarily running on top of proprietary Unix variants. Also, GPL software runs on top Windows OS or other proprietary OSes.
When shipping a Vendor OS that includes GPL components, the Vendor needs to comply with the GPL licenses of the used components. In particular, the Vendor needs to provide the used GPL source code as well as all the prerequisites that would be needed by the user to reproduce the binary. (e.g., since Vendor OS is based on Genode, the most practical approach for the Vendor to comply with the GPL would be to provide the Genode source code that was used for building the binaries present in Vendor OS)
The interaction of GPL software with proprietary software in general is well understood and documented by the FSF. All the established rules and practices apply to Vendor OS. For example, whereas it would be fine to use the Linux USB driver as a component on Vendor OS as it is a separate program, it would not be possible for a proprietary component to directly use the Linux TCP/IP stack because on Genode, the TCP/IP stack is a library, not a separate program.
Does this explanation answer your question?
Regards Norman
hello Norman,
I am watching the GenodeOS for quite some time. A while ago I started a port of Erlang language to genode. Erlang is licensed under ASFv2. In order to compile it under GenodeOS it needs a c library. please clarify how it would be possible to combine ASF and AGPL.
Best regards, ILYA
On December 14, 2016 1:54:16 AM PST, Norman Feske <norman.feske@...1...> wrote:
Dear community,
with the upcoming release 17.02, we are planning to change Genode's open-source license.
The current GPLv2 license
The Genode OS Framework is currently licensed under the terms of the version 2 of the GNU General Public License. We originally picked this license in 2008 for the following reasons:
- It captures the spirit of Free Software, which we deeply share with
the FSF. The license ultimately empowers the authors and the end users of software. Genode would not exist without Free Software. It is built on the shoulders of software like GCC, the GNU system, or Linux. All software that we at Genode Labs develop is Free Software.
- At the time of the first Genode release, the GPLv2 was a time-tested
and widely used license.
- It enables the dual-licensing business model of Genode Labs. If
Genode is commercially leveraged for proprietary solutions, Genode Labs benefits from the success of such products. This way, Genode has a long-term strategy to fund its development without relying on donations, public funding, or venture capital. We value this independence as fundamental for the sustainability of our project.
- Adopting the same license as Linux made a lot of sense because we
are routinely reusing Linux driver code inside Genode components.
Affero General Public License
The time did not stand still. The GPLv3 became widely spread and well-understood. It rectifies several shortcomings of the GPLv2. Furthermore, the Affero General Public License [1] closes loopholes of the GPL license with respect to web applications. Unlike 2008 when most applications were programs executed directly on the end user's computer, web applications have become predominant by now.
For Genode, we ignored the deficiencies of the GPLv2 for a long time. At the same time, with more and more software being added to our "ports" - the library of 3rd-party software ported to Genode - the license compatibility question, which we tried to avoid for Linux kernel code, arises for other 3rd-party software that is combined with Genode.
Admittedly, one reason for our hesitance was our fear of long-winded and opinion-loaded discussions around the licensing topic. But we ultimately have to acknowledge that an update to a modern license and a clarification of our stance with respect to the interoperability of Genode with other Open-Source software is long overdue.
The AGPLv3 encapsulates exactly the spirit, which originally attracted us to the GPL. After careful review, it makes perfect sense to use it for Genode. The following Wikipedia article nicely explains the rationale behind this license:
https://en.wikipedia.org/wiki/Affero_General_Public_License
Addressing interoperability concerns
Unlike most end-user software, which falls into a tangible category (application, library, kernel), Genode plays a special role. Not just because it is an operating system. But it is very unconventional at that: It is a collection of programs (Genode components). It is also a set of application libraries. It is also a "system library". It also comprises a dynamic linker. It may also be the kernel (i.e., our base-hw kernel). The lines between the categories become blurry.
For this reason, we intend to add a linking clause to Genode's version of the AGPL license text, similar to the classpath linking exception but restricted to software licenses that are blessed by the Open-Source Initiative, the Free Software Foundation, or Genode Labs.
Inspired from the text of the classpath linking exception, our clause would look as follows:
Linking Genode code statically or dynamically with other modules is making a combined work based on Genode. Thus, the terms and conditions of the GNU Affero General Public License version 3 (AGPLv3) cover the whole combination.
As an "additional permission" as defined by Section 7 of the AGPLv3, Genode Labs as the copyright holder of Genode gives you permission to link Genode source code with "independent modules" to produce an executable if the independent modules are licensed under an "approved license", and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.
An "approved license" is a license that is officially approved as an Open-Source license by the Open Source Initiative [1], or listed as a Free-Software license by the Free Software Foundation [2], or explicitly approved by Genode Labs.
An "independent module" is a module which is not derived from or based on Genode.
If you modify Genode, you may extend this exception to your version of Genode, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.
[1] https://opensource.org/licenses [2] https://www.gnu.org/licenses/license-list.en.html
With this clause in place, we want to express our consent to use Genode in combination with other open-source software. Note, however, that - unlike the classpath exception clause, our clause excludes the combination of Genode with proprietary software. This is our deliberate decision.
With Genode becoming AGPLv3, we face the question of how to integrate 3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode component. To address this concern, Genode-specific glue code that is needed to integrate the 3rd-party code with the Genode API ("system library") will have a license that is compatible with both the license of the 3rd-party code and Genode's AGPLv3 as such glue code is a derivative of both Genode and the incorporated code, e.g., the MIT license. In line with the wording of the exception clause above, when distributing binaries of such components, the licenses of both Genode and the incorporated 3rd-party code must be respected.
I hope that you support our plan to relicense Genode to AGPLv3 along with our linking exception clause. Should you have doubts about us taking this direction, please let me know.
Best regards Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Ilya,
I am watching the GenodeOS for quite some time. A while ago I started a port of Erlang language to genode.
interesting!
Erlang is licensed under ASFv2. In order to compile it under GenodeOS it needs a c library. please clarify how it would be possible to combine ASF and AGPL.
The Apache Software License v2 is compatible to AGPLv3. That means you are in principle even allowed to copy code ASFv2 code into a AGPLv3 code. The result would be AGPLv3. You cannot, however, copy AGPLv3 code into ASFv2 code.
That said, as a matter of license hygiene, mixing code of different licenses in the same source code files should be avoided whenever possible. Even if licenses are compatible, such practice is generally not in the interest of the original author. E.g., imagine an author who once published some code under a liberal (MIT/BSD) license and later rediscovers the exact code as part of a file with a strong copyleft license. So the original author cannot legally backport bugfixes of his/her own work into the original liberally licensed code. This would leave a bitter taste.
Combining ASFv2 code with AGPLv3 code as "independent modules" is not a problem at all. ASFv2 is both approved by OSI and listed as a Free Software license by the FSF. As expressed by our linking exception clause, we have absolutely no concern about combining such code with Genode.
Was I able to clarify your question?
Cheers Norman
-
Alexander Senier -
ILYA Khlopotov -
Jookia -
Josef Söntgen -
Nobody III -
Norman Feske -
Vasily A. Sartakov