Problems with the SCSL

Update: 31/03/2005

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

Update: 19/01/2005

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.

Update: 09/12/2004

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....

Update: 11/03/2004

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.

Dan Creswell


Introduction

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:

  1. The JINI core library source code belongs to SUN.
  2. Source code for services written by others belongs to those others.
  3. In cases of point (2), where the service is a re-implementation of a "standard" (part of the JSTK) service it should pass the relevant TCK tests.
  4. Bugfixes to the core code should be made available to the community for inclusion.
  5. Extensions should be shared with the community by releasing the public interfaces to the community - the originator (and others) have the right to keep their implementations of those interfaces private. Potentially, as well as releasing a set of interfaces, the originator should release some compliance tests.

The problem

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).

In Conclusion

  1. The "Covered code" definition is too wide covering anything that uses JINI in any way whether it be a complete JINI re-implementation, a service, IDE, application server or something else.
  2. Whilst SUN might like to claim that the SCSL takes the best bits of open source - it clearly does not - one cannot ship ones own source code openly.
  3. If the JBoss experience is anything to judge by, the only way to overcome these source code (and other) restrictions appears to be via significant cash sums which only successful/large companies can afford.
  4. JINI is still in the early adopter phase. Early adopters are often startup or small companies looking for a techological edge to boost them into "the bit time". The SCSL, as it is now, will prevent such companies from becoming involved with JINI owing to the commercial costs involved. For example, the SCSL, blocks the use of many opensource components. This forces companies to either re-invent the wheel or pay significant license fees for commercial equivalents.
  5. The potentially powerful force of open source development is being prevented from becoming involved with JINI because of the overly wide source code restrictions.
  6. Commercial use could be inhibited due to the overly wide compliance restrictions.

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:

  1. It is appropriate for SUN to ensure that JINI re-implementations are compliant.
  2. It is appropriate for SUN to derive profit from JINI in some way - perhaps through the sale of more servers as has been the case for many other a software offering from SUN in the past.
  3. It may be appropriate for SUN to ensure that re-implementations of core services are compliant. However, the best enforcement of compliance is often the market where customers will typically use compliant implementations and shy away from those that deviate in order to protect their own software investment.
  4. It is not appropriate for SUN to restrict the releasing of third party source code as it does.

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.


Correspondence

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 

Notes

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


Dan Creswell

29/08/2003