It's actually happening! The JINI specifications and the JINI 2.1 beta have just been made available under ALv2. For full details on all the changes, see here
After several weeks of on-list discussion and an opinion survey, the JINI team have elected to switch to the Apache 2.0 License. This is good news for everyone from opensource developers to commercial JINI users. You can read the announcement here.
SUN have announced that they intend to revise the license for JINI technology. They are currently favouring either the MIT license or Apache 2.0 license with a preference for the MIT terms. In addition they are aiming to make this change in time for the Porter Beta release which they are estimating will be delivered in March. Fingers crossed....
A number of people have written to me and stated that they have concerns similar to mine regarding the SCSL as it is structured for JINI. Many of these people have stated that they do not use JINI/JavaSpaces because of these concerns.
Forgive me, but I think that's the wrong attitude. A large number of users saying "we would deploy JINI/JavaSpaces but for the SCSL" is an excellent means of encouraging SUN to address the problems with the current license. How do you know if you want to use JINI? You've got to download it and take it for a spin!
I use JINI and JavaSpaces all the time, and am assisting companies in the construction of systems based on these technologies. I am keen to see JINI/JavaSpaces achieve wider adoption and firmly believe, based on feedback from the companies I work with, and the emails I receive, that the SCSL inhibits greater usage. This is what drove me to write the article below.
In conclusion: Don't ignore JINI because of it's license. It's a great technology and deserves your attention. If you like what you see but still have concerns, please lobby SUN to address them.
Being a good JINI community member means, amongst other things, being compliant with the SCSL. The key question revolves around what constitutes compliant behaviour? In the case of the SCSL, this is not an easy question to answer as it is somewhat open to interpretation.
Getting a good balance between the rights of SUN and those of the community member will potentially contribute significantly to the success of JINI as a product. Getting that balance wrong will, obviously, have a negative effect. Ideally, the SCSL would legislate something like the following:
An initial reading of the SCSL would appear to satisfy all the above but, unfortunately, there are several pieces of the license which introduce a critical ambiguity:
"Covered Code" means any and all code (including Modifications) implementing all or any portion of the Technology Specifications.
Under Research rights:a) reproduce, prepare derivative works of, display and perform the Reference Code, in whole or in part, alone or as part of Covered Code;
b) reproduce, prepare derivative works of and display the Technology Specifications;
c) distribute source or object code copies of Reference Code, in whole or in part, alone or as part Covered Code, to other Community Members or to students; and
d) distribute object code copies of Reference Code, in whole or in part, alone or as part of object code copies of Covered Code, to third parties.
And under commercial rights:e) use the Compliance Materials to determine whether Covered Code constitutes a Compliant Implementation;
f) use, reproduce, display, perform and distribute internally source and object code copies of Compliant Implementations for Commercial Use;
g) reproduce and distribute to third parties and Community Members through multiple tiers of distribution object code copies of Compliant Implementations for Commercial Use;
h) reproduce and distribute the source code of Compliant Implementations to Community Members licensed for Commercial Use of the same Technology; and
i) reproduce and distribute a copy of the Technology Specifications (which may be reformatted, but must remain substantively unchanged) with Compliant Implementations for Commercial Use.
Essentially, anything that qualifies as "Covered code" must be compliant and the source code can only be released to other community members.
In cases where one wishes to re-implement the JINI core and release it commercially, this may be sensible. However, the phrasing used in the SCSL could be interpreted to mean that, if your code, for example, implements net.jini.core.event.RemoteEventListener, you must obey all the restrictions of the SCSL, including the above mentioned rights. Thus, if you implement a new service or anything else that uses any of JINI's myriad of interfaces (app. servers, IDE's etc.), you are restricted.
It should, hopefully, now be clear to the reader why the JBoss Group have had so much trouble with the SCSL recently and are having something of a public disagreement with SUN. Further, the JBoss Group has publicly stated that it is making a financial settlement with SUN in order to resolve the issues (see Sun, JBoss Inch Towards 'SCSL' Settlement).
JINI is at a critical point in it's life and needs wider adoption from a community of developers and companies. The SCSL, in it's current form, will likely act as a significant throttle to that adoption.
I believe:
Most of these issues originate from the potential interpretations of "Covered code". I strongly urge SUN to re-examine this area and adjust it, to redress the balance I mentioned at the beginning of this article.
With permission from the authors:
From: Sebastian Hauer To: jini_javaspaces@yahoogroups.com Sent: Wednesday, March 10, 2004 11:19 PM Subject: [jini_javaspaces] Jini and the SCSL Hi, I have been a silent member of this group for a while and this is my first posting on the list. So far I was more curious about what JINI is all about but never found much time to take a closer look. Recently I started reading a few JINI articles on artima.com so I decided to give it a try and spend some more time on JINI. The only thing holding me back right now is the license agreement of JINI the Sun Community Source License (SCSL). I am not a lawyer and not a native English speaker so I am not exactly sure about the legal implications of this license for me as developer. I found this article on the web that is quite negative about it http://www.dancres.org/cottage/scsl_probs.html and that scared me of. I therefore did not yet download the JINI starter kit from Sun. Does the license only apply to the redistribution of the JINI reference implementation itself of alternative JINI implementations from third-party vendors or does it apply to any code making use of extending the JINI/JS API ? What do you think of this license in general ? Regards, Sebastian
From: Dan Creswell <dan@dancres.org> To: Sebastian Hauer <sebastian.hauer@sknt.com> Sent: 03/11/2004 04:09 PM Subject: Re: JINI/SCSL Hi, A colleague forwarded a copy of a recent posting you sent to jini_javaspaces@yahoo concerning JINI and the SCSL? First thing to say is that you shouldn't be put off from downloading the starter kit or trying out JavaSpaces because of what I've written. Essentially, my article is about the fact that the SCSL is difficult to work with because it's not very good and differentiating between end-customer code (e.g. code written for your own services), JINI re-implementations and core code written by SUN. If SUN decide to push the SCSL to it's maximum limit, many people would be talking to their legal department :) In reality, SUN don't appear to have any inclination to use the SCSL this way but, the fact that they could, puts people off using JINI. This is a serious adoption issue! More recently, I've had a discussion with various people at SUN on this subject (and so have others) and this is now a recognised problem. We will be addressing it further at the community meeting later this month (March). In addition, my discussions with people at SUN lead me to believe that the intention behind the license is somewhat different from the way in which the actual license restrictions are interpreted. Hopefully we can fix this so that everybody is comfortable. If you have anymore questions, feel free to ask me directly. Best wishes, Dan. P.S. Would you mind if I put a copy of this correspondence on my website? It's simply so I can make it clear what's been happening recently and prevent people from getting too discouraged whilst at the same time ensuring we're aware of the problem.
From: Sebastian Hauer <sebastian.hauer@sknt.com> To: Dan Creswell <dan@dancres.org> Sent: 03/11/2004 03:23 AM Subject: Re: JINI/SCSL Hi Dan, Thanks for your reply. I will start looking into JINI further after I received your and many other encouraging replies to my question. As a friend of open source software I wonder what kind of implications this license has for OS JINI extensions or even OS JINI/JS implementations. With such a license guarding JINI is it even possible to write an OS JINI implementation ? P.S. Would you mind if I put a copy of this correspondence on my >> website? It's simply so I can make it clear what's been happening >> recently and prevent people from getting too discouraged >> whilst at the same time ensuring we're aware of the problem. Sure go ahead. Regards, Sebastian
From: Dan Creswell <dan@dancres.org> To: Sebastian Hauer <sebastian.hauer@sknt.com> Sent: 03/12/2004 10:18 AM Subject: Re: JINI/SCSL Sebastian Hauer wrote: > Hi Dan, > > Thanks for your reply. I will start looking into JINI further after I > received your and many other encouraging replies to my question. As a Great! If you get to like it, consider lobbying SUN for license changes (I have talked to them at length about this so I have contacts if you want them). To get you started - checkout http://v2getsmart.jini.org and the mailing lists. You can, of course, email me direct with questions, I'll be happy to help. > friend of open source software I wonder what kind of implications this > license has for OS JINI extensions or even OS JINI/JS implementations. > With such a license guarding JINI is it even possible to write an OS > JINI implementation ? > Ah, and that's the point of the article I wrote. As for the JDK, right now, it would be impossible to write an OS version of JINI because you wouldn't be permitted to release the source code to anyone other than a JINI licensee. You might be able to write an extension but if it uses any of the existing JINI infrastructure you'd still be bound by the SCSL hence you couldn't OS it. In addition, the SCSL encourages you to contribute the interfaces of your extension back to the community. Now, I'm not sure on this bit but if your interfaces became part of JINI, I suspect the source code distribution rules apply all the strongly. Strictly speaking, you can't even release source code of your own services as OS because they likely implement a JINI interface or two. This is a major problem and a major inhibitor to adoption, IMHO. > >> P.S. Would you mind if I put a copy of this correspondence on my > >> website? It's simply so I can make it clear what's been happening recently >> and prevent people from getting too discouraged whilst at the same time ensuring >> we're aware of the problem. > > > > Sure go ahead. > Thank you! > Regards, > Sebastian
It appears I'm not the only party who sees problems with the SCSL, Cheiron License Page
For a definition of open source see OpenSource.org
Update on JBoss vs SCSL/Certification issue
29/08/2003