Summary
The ability to abstract "the network" away from clients is one of Jini's most powerful features. A discussion at JCM7 has led me to realize that this power potentially has significant consequences when it comes to licensing - completely external to the issues surrounding the SCSL.
Advertisement
Background
Please bear with me as I backtrack a bit...
Jini's "Relevance"
Being a big fan of Jini and wanting to see it move more into the mainstream, Jini's relevance can be improved by creating interconnections with mainstream technologies. With that in mind, (in addition to having a way to improve my skills) I envisioned the Judy Project as a way to bridge the web services and Jini worlds. Both technologies are based on service oriented architecture concepts and each technology's strengths seemed to have answers to the other technology's weaknesses. Due to my Principle of Least Work (more on that later), I decided to use Axis generated stubs wrapped in smart dynamic proxies so that Jini clients would have absolutely no distinction for the type of service it needed to access.
Viralness of the SCSL
Another Jini community member, Dan Creswell has written a well-considered article on the Problems with the SCSL. Particular points to note:
"..."Covered code" must be compliant and the source code can only be released to other community members."
"...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..." to releasing YOUR source code under the SCSL.
"...there are several pieces of the license which introduce a critical ambiguity..."
"Whilst SUN might like to claim that the SCSL takes the best bits of open source - it clearly does not..."
To recap, YOUR source code is subject to the SCSL (even if you want it Open SourceĀ) and the SCSL is incompatible with OS licenses such as the GPL.
Licensing Discussion at JCM7
The discussion was rather lively (and well behaved) not seeming to really be well addressed by Sun. On the other hand, the Jini team did appear to be listening to the objections in good faith. Anyway, the more interesting discussions started coming out later that evening at an event put on by Majitek. In particular, one of the Jini visionaries wondered aloud if the code mobility pieces themselves violated terms of the SCSL.
Conclusions
This all got me to thinking...
Tying it all Together
Specifically, even though Judy's WebServiceProxy wraps the Axis stub it does nothing more than forward the client call to the Axis stub. Is the Apache license being violated by the SCSLs viralness?
More generally, what if some Jini client software written under unknown licensing terms conflicted with the terms of the downloaded proxy?
What if the developer or user of the Jini client software didn't agree with the licensing terms of the downloaded proxy?
What if the developer or user of the Jini client software didn't know what the licensing terms of the downloaded proxy even were?
My Take
From my perspective, these questions result in indeterminate heuristics ;-). They are tough problems that I think licensing can in no way address. Mobile code just doesn't fit into "licensing" as a way to control access to software.
Anyway, I'd like to hear what others think about this.
My initial thoughts on the SCSL, tend to be that it's a little bit over the top. If I distribute my source you can't compile it, unless you have Jini starter kit, which requires you to sign the SCSL. If you download a binary, you can't run it, unless you have the starter kit which again requires that you sign the SCSL.
My issues, are roughly the same as yours, why should my code be affected by the Jini license, when it really doesn't matter. The only possible reasons are a) inference of API's by crawling through the source code and inferring interface definitions from the code, and b)Extending or implementing Jini classes and interfaces - which seems to be the crux of the matter.
The best solution would be to allow sanctioned dual-licensing models - your code is under whatever license you wish, but Sun's code is stil protected by the SCSL, and the granting of this is passed when you sign the SCSL to download the Starter Kit OR in the case of companies buying Jini-based products from companies, a request to log in to Sun and sign some form of SCSL-esque license
I really think that sanctioned dual-licensing is about the only way we'll make progress on this issue.
> ... and the SCSL is incompatible with OS licenses such as the GPL
I think the opposite is true, which means that GPL is incompatible with (all) other licenses. It's viral too (as SCSL) and doesn't allow you to invoke methods on your GPL'ed classes from non-GPL'ed ones (says <a href="http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins"> gnu.org</a>). For these cases you will have to choose the LGPL, I think. Otherwise not only SCSL'ed code but also code under an Apache license and others wouldn't be allowed to use the classes.
BTW cheiron.org has an interesting dual-license <a href="http://www.cheiron.org/misc/license/index.html#dual">model</a>.
Previous Topic
