[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sun's JRL and source: taints or not?
From: |
Dalibor Topic |
Subject: |
Re: Sun's JRL and source: taints or not? |
Date: |
Thu, 05 May 2005 10:03:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 |
David Holmes wrote:
Dalibor,
Thanks for the very detailed response. You raise some very interesting
points. Sun seems to be pushing this "no taint" aspect of the JRL to
encourage more people to contribute to Mustang development:
Hi David,
thanks for your kind reply.
During my recent stay in Brasilia for the CafeBrasil conference, I had
the chance to meet some Sun employees, among them Gosling, Phipps and a
bunch of Sun evangelists whose names I unfortunately do not recall.
I recall that one of the evangelists asked me whether I heard about
Project Peabody, which I confirmed. The Sun evangelists had some hard
time understanding why someone would want to write their own freely
useable, modifiable and distributable code instead of working on their
non-free software. The idea of striving for better and free software,
and radically writing it from scratch, if necessary, seemed not
plausible for them.
Eventually, I had managed to explain how things work, to a certain
degree, and the Peabody evangelist asked me whether GNU Classpath or
Kaffe were competing with Sun's Peabody effort. And I think the answer
is a clear "No":
a) GNU Classpath is already there
The project has been developing the core class libraries in an open,
collaborative fashion since 1998. It has a huge, vibrant and growing
community of developers, users, packagers, deployers, runtimes, and
friends. It steadily attracted new, engaged contributors. It forms the
backbone for some of the most innovative runtime projects in the
bytecode platform space. And it keeps attracting new projects to join
the the pool of those who use it, thanks to the well thought out design
of things at the core level.
Beside having a growing pool of developers producing lots of good code
rapidly, GNU Classpath has one major thing going for it: it is fun to
work on, and the community is a friendly one to work with, without
communication barriers, NDAs and similar problems.
b) GNU Classpath attracts a different group of people
In my experience, the people who care about both FOSS software, and the
Java platform, will naturally strive to work together with the Free
Software runtime community around GNU Classpath.
People that don't really care about Free Software, but care about
commercial use of class library code and their liberty to do so as they
need, will also quite naturally chose GNU Classpath as the project to
contribute to.
People who care about publishing repeatable scientific research, will
also continue chosing the projects that allow them to do so with the
least amount of hassle, and the greatest amount of support.
Nevertheless, I believe Project Peabody has a great value for Sun in
terms of generating some good PR for them.
There is also a non-obvious, probably unintended benefit for Free
Software runtime projects: a fraction of proprietary software
developers, seem to be currently afraid of the prospect of compatible,
Free Software runtimes becoming prevalent and marginalizing their
investement in Sun's implementation. Project Peabody gives those
developers an outlet to deal with their insecurity in a creative way, by
fixing compiler warnings in Sun's implementation, for example.
http://java.sun.com/developer/technicalArticles/J2SE/peabody/
"And for developers that ask, "Does looking at source code under the JRL
taint me?", the answer is "No!" See the JRL FAQ #18 for more details."
Of course that author may be relying on the FAQ being correct.
Probably, yeah. I didn't have an opportunity to talk with Graham
Hamilton yet, and he does not seem to be the talkative type in general,
judging by his sparingly seeded comments on blogs.
As far as I can tell by his excited comments on the "Read-only" TCK
license [1], or the somewhat bizarre 'army of lawyers' defense of the
SCSL[2], his job does not involve critically dissecting non-free
software licenses for legal minefields, and practical deployment and
development problems.
Given that he has his own army of lawyers, though, that may not be
necessary for him anyway. :)
cheers,
dalibor topic
[1] http://weblogs.java.net/blog/kgh/archive/2004/12/j2se_compatibil.html
[2] http://www.internetnews.com/dev-news/article.php/3490711