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

1. 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?
2. More generally, what if some Jini client software written under unknown licensing terms conflicted with the terms of the downloaded proxy?
3. What if the developer or user of the Jini client software didn't agree with the licensing terms of the downloaded proxy?
4. 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.

Talk Back!

Have an opinion? Readers have already posted 2 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Dale Asberry adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

R. Dale Asberry been hacking since 1978, professionally since 1990. He's certified in Java 1.1 and has a four digit MCP number. He discovered Jini at the 2000 JavaOne and has been building incredibly cool, dynamic, distributed architectures ever since! Over time, he's discovered several principles that have contributed to his success - they are the Princples of: Enabling Others, Simplicity, No Complaining, Least Work, Least Surprise, Least Damage, and "It Just Works".