Enhydra Licensing Rationale
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):
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:
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:
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!
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:
Things we don't like:
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 dont 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 dont 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.
Lets summarize its good points:
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.
After reading this proposal the Lutris team and I would appreciate your feedback