Simon Phipps wrote:
>
> On Aug 19, 2006, at 19:57, theUser BL wrote:
>
>> Actually is still the time, where you can influence, which license
>> Suns Java will have.
>
> Yes indeed. I am all ears.
As somebody that has been pushing for Sun to open source pieces of the
Java platform from that now famous meeting in the "jakarta" conference
room that gave birth to jakarta.apache.org, I can only voice my
gratitude and happiness in seeing Sun finally committing to this.
And I'm thankful to Simon for his openness and will to listen.
- o -
Now, which license to use on it? and why?
Let's step back for a second.
A license protects but also channels the social dynamics around a
particular codebase. It is because of licenses that social dynamics
around an open development community are different.
As a protection mechanism, I think that IP law and trademark law are
already very effective, so I think that Sun should be using a license as
a social dynamic shaper and/or catalyzer more than as a protection
mechanism.
So, if we assume for a second that Sun can use the license as a carrot
rather than a stick, my suggestion would be to use the simplest and more
compatible license possible.
I'll bite: the MIT license.
The MIT license is the only truly socially neutral license, because it's
the simplest thing that can be OSI-compatible, it's well accepted by the
FSF and it's well accepted by the ASF.
Sun is not using a license to stop people to add changes to the JVM that
they are afraid that they won't get donated back. Sun is looking for
ways to help spread Java, but without affective compatibility negatively.
Sun owns IP on Java and the Java trademark. You can get the code and
compile it but you can't use it without a license for the IP and you
can't call it java without a license for the trademark. But we are not
talking about those licenses, we are talking about the license on the
code and *that* only.
That code that used to be very valuable because unique (Sun spent
millions of dollars buying it, building it and maintain it), but that
value if reducing with every new line of code that gets added to
Classpath or Harmony (and if you look at the commit logs, it's going
down pretty fast!).
So, why restricting the code in any way past the basic OSI principles?
Let it be used by Classpath, let it be used by Harmony. Become the
source of the stream, not yet another player in a already-too-fragmented
ecosystem.
To be the "core" you need to play ball... either you wait for the slow
social tectonic plates between the FSF and the ASF to align under the
GPL3 stars (and remember, that is a one way bridge, even in the most
fortunate circumstances!) or you bypass the entire thing and go simple,
let the code be used by anybody that wants to and go after those who
don't play by the rules (and that the community doesn't burn down in
flames first!) with the other protection tools you have.
CDDL is an example of clever lawyer work to modernize best licensing
practices, but those are best practices in protection not in social
empowerment!
There are many players in the FOSS java space... we tried so hard, with
Harmony, to make it one (and that, at least, helped putting a little
fuel back into the GPL3 vehicle), but we completely underestimated the
amount of work and social energy that was required to stop those
tectonic plates to collide and create social earthquakes.
The leaders of pretty much all FOSS java projects know and respect each
other. They all cheer for each other's projects. They compete in a
healthy way yet there is no way to erase the licensing status quo and go
back to a square one where everybody plays together without borders and
without biases (even if, believe me, so many of us would love to see
that happening, on both sides).
If Sun thinks that they can do something about that, they will fail, as
much as Harmony failed in that sense.
If Sun thinks that their code is so valuable that requires all sort of
protections, that will make their code unusable by existing projects and
they will be run over because there is no way they can pull off the
social momentum that Classpath or Harmony already have before a
clean-room implementation gets certified.
And if Sun pulls one side of the licensing pond, it will alienate the other.
So, what can Sun do in this rather difficult situation? how can it help
Java reach places that were impossible to reach before? and without
alienating the same people they are trying to please?
I've been promoting java in open source since 1997 (therefore I care)
I've been a director of the ASF and one of the founder of the Harmony
project (therefore I'm biased), and I'm no Sun CEO (therefore my
visibility of the risks is limited), but my humble suggestion is to
remove *all* the restrictions that they can, use the simplest possible
and most compatible OSI license (which is the MIT license) for both the
JDK code and the TCK code, trust the value of a loyal community to work
with you because it's in *THEIR* best interest if their code works
tomorrow as it works today, let everybody play in your courtyard and
sure, keep control on the specs and on the testing outcomes so that
nobody (users or stock holders) freaks out, but be as open as you can:
don't use a license to restrict but to empower.
That would not only reduce social friction between the various FOSS java
communities, but might also help people build those bridges that we have
always wanted to build that failed because the two sides of the
licensing pond were so far apart.
By building an island in the middle, that both can reach, building a
bridge will be way easier.
Thanks for listening.
FULL DISCLOSURE: MIT is my employer but this had *no* influence in my
licensing suggestion.
--
Stefano.
