Cheiron

1. General
   1. News
   2. Blogs
   3. Mission
   4. Guidelines
2. Projects
   1. JSC
   2. Seven
   3. Utils
3. Participate
   1. Overview
   2. Repositories
   3. Mailing lists
   4. References
   5. Issue tracking
4. Misc
   1. License
   2. Credits
   3. Legal

License

Throughout the Cheiron project various licenses are exercised, this is partly due to the Sun Community Source License (SCSL) required for using the Jini™ technology. It took us, and others, a lot of energy to fully comprehend all the licensing issues. Therefore we felt it our obligation to share this knowledge with you, either to make you feel comfortable participating in Cheiron or to set up your own Open Source project involving Jini™ technology.

Disclaimer: the information with regard to licensing is no legal advice. Although we went to great lengths to make sure our information is accurate and useful (if not please tell us), we recommend you to consult a lawyer if you want professional assurance that our information, and your interpretation of it, is appropriate to your particular situation.

Rationale

We considered the GPL or LGPL License for use in some of the projects, but after carefully studying the GPL/LGPL license terms and a lot of debating about its various implications we felt much more comfortable with the BSD license.

On the surface, the GPL/LGPL seems to be the better license for our goals. One thing we want to avoid is for innovation to be stymied by proprietary interests. However we also realize evolution is maximized by eliminating restrictions rather than enforcing them, for that you need a BSD License.

The GPL had to be abandoned straight away for it would rule out the use of Jini™, the reason for starting this project. GPL code can only make use of other GPL compatible code because of section 2.b "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License". Some people tell you that because of the Java™ dynamic linking model this section doesn't apply to a Java™ program calling a GPL incompatible library, but the GNU itself thinks differently about this, see their FAQ. You are sometimes allowed to add an exception to your GPL license terms for specific libraries, but you are not allowed to distribute the library with your product.

Another major problem of exercising the GPL would be the lock-out of Seven for use in 'closed' products and services, at least if you want to respect the GNU interpretation of their License. We want to have a framework for the implementation of vertical services, whether open or closed, commercial or free. We don't recall the JBoss and GPL discussion, but the fact JBoss is LGPL nowadays says enough about the importance of this.

The LGPL works around some of the GPL problems by addressing libraries and clarifying that code using the library can carry any license, while code that modifies the library is subject to the LGPL license. Still being complex (almost nobody cares to read and comprehend), the possibility of GPL hijacking and people considering it having ambiguities for Java™, we found it a less attractive option.

We also have no principal objection against people and/or companies having expertise in specific fields to create 'closed' derived works to compete and to make money. As long as the Cheiron project will keep momentum we think these people and/or companies will submit their less distinct enhancements, hopefully after time even their proprietary ones. Software engineers know the effort it takes to keep various code lines in sync and to bugfix their own initial code, for exactly this reason many commercial companies participate in various open source projects.

A number of other open source licenses have been considered, most of them somewhere between the BSD and GPL license terms. Ultimately we believed these middle-of-the-spectrum licenses create restrictions that only show marginal, if any return, at the cost of increased complexity. Therefore we decided to keep the license terms as simple as possible.

If there would become a need for the Cheiron Licenses could be changed into more restrictive ones. We guess the chance of full support for this scenario is higher than for changing a LGPL license into a more liberal one.

In general we think the real force behind these projects is not the license but how well we foster the community, only they will ultimately determine the fate of the projects. In this spirit we think and hope the Cheiron BSD License serves this goal the best, time will tell ...

Cheiron BSD License

The Cheiron BSD License is a general BSD license without the advertising clause, almost as liberal as a license can get. The terms of this license are a choice for all code that is not under direct effect of the SCSL License, this will be explained in more detail at the Cheiron Dual License that gives these license terms as a choise.

SCSL License

In the article Sun Community Source License Principles the design principles behind the SCSL are explained and if you think compatibility of Jini™ services is a high priority you will agree with much of the rationale. But by using the Jini™ Technology and therefore agreeing to the terms of the Sun Community Source License v 3.0/Jini Technology Specific Attachment v 1.0 you risk the chance of infecting your own license terms by the SCSL. The SCSL is a 'viral' license, not to the extent of the GPL, but you should be aware of this.

The 'viral infection' occurs when you create Covered Code "any and all code (including Modifications) implementing all or any portion of the Technology Specifications". The Technology Site will give you an exact overview of the Technology Specifications. Main problem is section IV.D of the SCSL "Distribution Requirements" that will restrict your distribution rights severely. This term would for example exclude a dual license strategy in most cases. If the alternative license terms are incompatible with the SCSL you can't apply the dual license to your Covered Code.

With regard to Contributed Code not considered Covered Code the SCSL is quite liberal, see section III.B.1. For Contributed Code you can use almost any license you like, a dual licensing strategy is a good option and is gaining popularity, see our Cheiron Dual License for more information.

You have noticed your licensing possibilities are a direct result of the type of code you create, the examples below can be used to clarify the definitions of section I:

• net.jini.core.lookup.ServiceRegistrar interface code is "Reference Code";
• com.sun.jini.reggie.RegistrarImpl code is "Covered Code" as well as "Contributed Code";
• com.sun.jini.reliableLog.ReliableLog used in RegistrarImpl is "Contributed Code" according to us. But one could argue it is being used to implement the Technology Specifications, making it "Covered Code". This question has been asked to a Sun official and the answer was: "I'm not sure here".

Our main problem with the SCSL is therefore what to consider as Covered Code, based on Sun Microsystems definition there is still a lot of room for interpretation. Because of 'infection' we want to keep the amount of Covered Code as thin as possible. We also would like to see the restrictions loosened with regard to Covered Code or them to really narrow their definition.

Cheiron Dual License

As SCSL licensee we have to put our Covered Code under a SCSL compatible license, we didn't see any advantage in figuring out a license ourselves, therefore we decided to stick with the SCSL.

For all our other code we exercise the Cheiron BSD License. But as our main audience is the Jini™ community that is familiar with the SCSL, we felt it our obligation to license that code under the SCSL as well. This enables the distribution of Reference Code as well as Contributed Code of Community Members together with our packages. This will save the pain of downloading the various libraries yourself.

This decision resulted in the Cheiron Dual License giving you the possibility of choosing between the terms of the Cheiron BSD License or the SCSL License. We hope people appreciate our decision, however as a consequence we can only accept code in our repositories that are committed under the Cheiron Dual License.