Enhydra Licensing Rationale

Preamble

Enhydra, Enhydra Enterprise, and various inclusive technologies have certain open source licenses that apply to them. The original base Enhydra Server and tools were distributed under probably the most liberal of licenses: FreeBSD style. This choice has lead to the rapid adoption of the Enhydra technology base but did little to focus and consolidate development efforts.

With Enhydra Enterprise, a new license was introduced, called the Enhydra Public License, or EPL. The EPL is based on the Mozilla License. New technologies that are developed for Enhydra will in most cases also use this license, except where they are sourced from projects that require another type of license.

Why the new EPL License?

There are three motivations for introducing the EPL (see below for full discussion):

• As discussed on the Enhydra community mailing list, the GPL license (XMLC) is problematic for Java development: Any application code that you write that is run by a GPL license application server must itself adopt the GPL license! (see succeeding discussion).
• The current license is confusing for code contributions in that it is not "sticky" and does not spell out what rights a contributor must give up when donating their code.
• To encourage developers to contribute their work and ingenuity back into the community (and back into the product) so that the whole community benefits without concern for how the code might be used.

What were we looking for in the EPL license?

In seeking a new license for the continued evolution of Enhydra we were looking to address the following concerns:

• How do we ensure that enhancements and contributions made to Enhydra benefit the Community as a whole?
• How do we best ensure that innovations made by the Enhydra community stay within the community and are not swallowed up by a competing closed-source commercial product?
• How do we encourage and make it easy for contributors to submit enhancements?
• How to we properly acknowledge the authors of contributions?

The EPL license

After much agonizing and research, we have concluded that the new license known henceforth as "The Enhydra Public License" or EPL should be a variation of the Mozilla Public License, which may be found at Mozilla.org.

We wish to make it clear that we are actively evaluating our license and would appreciate your feedback. Please read the following to understand our current thoughts on this issue.

The EPL license rationale

In trying to find an appropriate license for new Enhydra development, we have read and debated at length most of the popular Open Source licenses that are out there including BSD style, GNU GPL, LGPL, Artistic and the new MPL, created by Netscape. There is no doubt that with all of the activity in Open Source, aspects of licensing will continue to evolve. We see strong merits in the GPL, and share most of its idealism. We also like the MPL, which has much of the spirit of the GNU but is less ambiguous in many areas.

The Open Source Definition (OpenSource.org) served as a guideline, and says that all of the licenses fit under the definition. Three motivations/principles really stand out for us:

• Allow free and unrestricted use of and modification to the software.
• Encourage developers to contribute their work and ingenuity back into the community (and back into the product) so that the whole community benefits.
• We would like for external modules, which are dynamically linked at runtime and which we do not consider part of the application server, to not fall under the license.

Here are options that we considered:

FreeBSD / Artistic License

We are currently using the FreeBSD style license on the Enhydra product. This has served it well, but as probably the least restrictive of all licenses, FreeBSD makes it too easy for the whole server to be snatched up and resold. Many developers have voiced they don't want their work to be "taken advantage of" this way. Still, FreeBSD style has some advantages for certain cases where a party would like to base a product on a modified version of Enhydra. This has happened with the current Enhydra (why the current code will continue to remain under the FreeBSD style license) and while we are happy to see this, the community is unable to benefit from the results. The other problem is that the license makes no requirements on the contributed code even if the author wants to donate it back to Enhydra.org.

The Artistic license didn't seem appropriate for Enhydra as its language is perhaps too specific to implementation.

Creating a New License

Recently Sun and IBM have created completely new licenses. Creating yet a new license seems to us to be "creating additional confusion". We tried this tack with our misappropriated change to XMLC and one thing that we did learn is that there are very few lawyers that can help!

GPL

The GNU license (GPL) has its roots before modern Object Oriented languages became popular. It is viral in nature since it affects all code that extends or uses it. It is not entirely clear about where to draw the lines as to where external software gets "infected" by GPL's viral nature. In fact, one could easily argue that with Java, where everything is a library (class), any code that includes a GNU component must convert into GPL.

The Enhydra Application Server provides an environment for application code to be loaded and executed, thus extending the original functionality of the base server. This is the primary way of developing systems built with Enhydra, and one might say that providing such an environment is the primary purpose of an Application Server. This is thus clearly incompatible with the GPL license since all the code that you might develop must also become GPL.

Here is what we like about GPL:

• Any code contributed must also be open source.
• Popular with many developers already, including the Linux community.
• Carries the "code should be free" religion.
• It, by nature, has good survival traits.

Things we don't like:

• Commercial enterprises might be scared away from getting involved because of the fuzziness or ambiguity in it.
• It is especially ambiguous when applied to the Java programming language.
• Certain developers might be turned off because it is too radical.
• It is not an easy license to contribute code to — it does not cater to the allocation of Intellectual Property.

LGPL

The LGPL takes the GPL license a step in the right direction by addressing libraries and clarifying that code that uses a library can carry any license, while code that modifies the library itself is subject to the LGPL license. We don’t feel that we can use it because the Enhydra Server is not by any definition a library, but is a server or platform designed to call other code. Although LGPL has been used in Open Source Java initiatives, we believe that it still suffers from GPLs ambiguities for Java and we don’t ever want to have to change our license again!

The Enhydra Public License (EPL)

We are thus left with the Mozilla style license. While not perfect, it does solve all of our current issues and concerns and has the benefit of having the best legal clarity. This license has had some undeserved bad press from some Open Source advocates primarily because of its mention of Intellectual Property. We believe that these concerns are unfounded because the license protects the licensee of the code by explicitly granting IP rights.

Let’s summarize its good points:

• It is sticky: Any modification to the Enhydra core code (explicitly at the Java package level) must be made available to Enhydra.org for possible inclusion in the base product. This will help to keep the Enhydra engine consistent and reduces the chances of having different version of Enhydra in use.
• The license mandates that contributions to the core must be of the same license as the rest of Enhydra and that any Intellectual Property owned by the contributor are granted to end users of Enhydra for the intended purpose.
• The license satisfies the widely regarded Debian Free Software Guidelines describing free software.
• Via the "Contributor Version" it is easy to recognize and credit contributors other than the original author.
• By protecting the core APIs and functionality, the license still allows proprietary closed-source innovation to be built on top of these APIs.

To spell out that last point some more, consider this: If some developers are motivated to write value-add modules on top of Enhydra with the intent of selling them, it helps the end user of the Enhydra platform by providing them with more choices. A user can choose to use a free module, or if one exists with sufficiently compelling value, they can pay for a commercial one.

Now here is a key point: We believe that over time, as long as there is a sufficiently demonstrated need coupled with a large enough pool of interested developers, a module to perform needed functions will become available as Open Source. If a need is observed by a commercial entity, it can create the software that addresses the need and sell it. If the market becomes sufficiently large, an open source version appears, which better addresses the need. The commercial entity has to move on and find a new need to address. Allowing this type of cycle to occur gives Enhydra and its users advantages: commercial developers AND non-commercial developers create software. All potential parties that can be involved are encouraged to do so and are encouraged to innovate. As a result, innovation is more diverse and plentiful.

Since the original Mozilla license was written for Netscape, it must be modified to be useable with Enhydra. This modified license is known as the Enhydra Public License or EPL.

Given the Open Source nature of Enhydra under EPL, and that value-add modules would need to be written to the Open Sourced APIs, it is a level playing field. Competing commercial entities must differentiate themselves by rate of innovation, understanding of need, and by brand. If they succeed, they will likely be replaced by the Open Source version that comes along. Enhydra will grow and evolve and the users will benefit. Any changes to Enhydra's APIs will also have to be Open Sourced.

In summary, we feel that the EPL will best serve Enhydra and its community. It allows Enhydra to be used and modified without licensing fees, encourages developers to share ideas and contribute them back to the community (the stickiness of GPL), allows traditional commercial entities to get involved and contribute while keeping a level playing field for non-contributed innovation, and prevents the Enhydra Server itself from ever becoming proprietary.

--------------------------
It should be noted that some of the code included in the Enhydra and Enhydra Enterprise distributions does contain code from other Open Source efforts. In those cases, that code is covered by the license that specifically pertains to it.
--------------------------

After reading this proposal the Lutris team and I would appreciate your feedback