Enhydra Licensing
Preamble
Enhydra, Enhydra Enterprise, and various inclusive technologies have certain
open source licenses that apply to them. The base Enhydra Server and tools have
been distributed under probably the most liberal of licenses: FreeBSD
style. This choice has lead to the rapid adoption of the Enhydra technology
base. The only exception for the base Enhydra is that the XMLC component is
under the GPL license.
With Enhydra Enterprise, a new license was introduced, called the Enhydra Public
License, or EPL.
The EPL is based on the Mozilla License.
New releases of XMLC will also fall under the EPL. 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 rational
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 condidered:
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
|