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.

Why GPL?

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:

1. Somebody wishes to use some propretary piece of hardware, and does not wish to disclose the code for the driver.

   We don't think that there are compelling economic reasons to avoid proprietary drivers, and we think that in the end this approach to hardware is doomed, but we do not want to stall the progress of EROS while people figure this out. There is a great deal of value to all of us in having EROS widely deployed.

2. Somebody has some piece of valuable proprietary software that they wish to distribute with an EROS system, and they cannot determine if they are obligated to distribute this code under GPL.

   We encourage people to consider whether it might be better to open their software, but this is not an unreasonable question and it deserves a clear answer.

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:

1. Inseparable Components. If neither component has a reasonable and useful function when taken in isolation, the two programs are a combined work.

2. Separable Components. If one of the components has reasonable and useful function in isolation, but is not installed in such a way that it can be used by a third party developer, then the components are a combined work.

3. Security Dependency. If component A is claimed to provide security guarantees, and depends on component B to satisfy its security guarantees, then the two components are a combined work unless:

   1. Component B is a separable component whose source code is available to the user under an open source license, or

   2. Component B is a separable component that has been certified under the ITSEC or Common Criteria process to meet all requirements that are necessary to support the security claims made about A, or

   3. The party installing the system may easily omit or replace component B without rendering component A or the system as a whole non-functional.

4. Interfaces. Interface stubs and header files that must be incorporated into a program in order to use some other program must be opened under LGPL or a similarly permissive license in order to be incorporated into the EROS repository. By ``similarly permissive,'' we mean that the mere linking of interface code into a program should not require that program to be published under any particular open source license.

5. Documentation. Documentation for open components should be openly redistributable.

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:

1. If equivalent function is provided by an existing open source application, then the new program should be distributed as open source.

   These programs should be opened because we all want the EROS system to remain competative with other systems.

2. If the security of the system critically depends on the new program or component, it should be distributed as open source.

   These programs should be opened because security is a major advantage of EROS, and it will be trusted only if people can see for themselves that the system is secure. You may say it's secure, and I may say it's secure, but when an independent party can examine the software to see if it's secure the users are much more confident that we are telling the truth.

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

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:

1. Create a minimal, generic open source driver that knows how to speak to your hardware, but does not know what to say. This will expose the addresses of the hardware registers and memory, but will not expose how to use them. It will also expose a minimal amount of demultiplexing logic for interrupts.

2. Expose this driver via a capability interface.

3. Write the real driver as an application program that uses this interface.

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