EROS is currently distributed under two licenses: the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL). The general rule for choosing a license within the EROS code is:
In order to ensure that Core EROS remains open, and to ensure that we are able to provide security assurance for EROS in the future, we require that modifications and enhancements to Core EROS be assigned to The EROS Group.
As we include more and more application function, the distribution will come to include materials covered under other open source licenses such as the BSD license, the X Consortium License, and/or the Apache License.
The obvious reason to use GPL is that it is widely used and there is wide agreement about what it means. Also, there is a large amount of code covered by GPL that we might wish to incorporate into the EROS system. In spite of some very bad problems, these are the reasons that we use GPL. So what are the problems?
GPL is horribly ambiguous, and it is missing some very important protections for everyone about patents. GPL does not adequately define what a ``combined work'' is, and these are very difficult things to define in modern systems. For example, there has been a long debate about whether dynamically linking an extension into a GPL application requires the extension to be distributed under GPL. The Free Software Foundation says "yes." The Linux community (and many others) say "no."
The ``combined work'' problem is especially bad for systems like EROS. In EROS, applications are typically built out of components. Each of these components is a completely separate program that invokes other components using capabilities. When two components are a ``combined work,'' and one is distributed under GPL, they must both be distributed under GPL. The question is: when are two components considered a ``combined work?''
Because of this ambiguity, we are periodically asked to consider changing the license terms. The two most common reason for this request are:
So the question is: how does the license apply to EROS?
What MUST be Opened
If you modify an existing piece of code, creating a derived work, you must license the derived work under GPL.
If you modify an existing EROS program in such a way that it depends on or makes use of some other program, then the two programs together may be a combined work. If they are a combined work, then both programs must be released under GPL. Here are the guidelines that determine whether two components (programs) are a combined work:
These guidelines are subject to change, because we have probably missed something important and it is impossible to anticipate the questions that people will raise in the future. Revisions will be made for the purpose of clarification and to address unforseen situations. Revisions will not be made for the purpose of subverting the ability to create proprietary software that runs on EROS.
What SHOULD be Opened
Above and beyond what must be opened, there are some things that should be opened:
What NEED NOT be Opened
Unless the resulting program is a derived or combined work as described above, there is no obligation to release it as open source at all, and there is certainly no obligation to release it under GPL.
Proprietary drivers are a commonly raised concern. We believe that they are misguided: a driver is too easily reverse engineered, and there is rarely any benefit to preventing people from using your hardware. There is no security achieved by keeping a driver proprietary.
If you are really determined to do this, however, here is one way to go about it:
We are planning to include in the kernel a "generic" driver intended for testing and debugging purposes, but this generic driver could probably be used as a basis for proprietary drivers.
Proprietary Input Methods
Some companies have proprietary input devices or proprietary code that interprets these input devices. This code does not need to be made open if it can be left out of the system by the user and still have a functional system or if it can be replaced by the user.
The main problem with this type of code from our perspective is the fact that the security of the system relies completely on the correctness of this code, and a trusted system should not be built on code that cannot be independently analyzed and verified by the user.
Copyright 2000 by Jonathan Shapiro. All rights reserved. For terms of redistribution, see the GNU General Public License