Re: Bringing License arguments to Sun

[Stefano Mazzocchi]

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

Re: Bringing License arguments to Sun

[Chris Gray]

+1 to Stefano Mazzocchi: a Reference Implementation should have an MIT- or 
BSD-style licence. It worked for TCP/IP, it worked for X11, or JPEG and for 
countless other things. It's good for interoperability, becuase it encourages 
people to use the RI as a base and only tinker with those things that they 
need to. Even if a project decides to re-implement everything from scratch 
(e.g. lwip) it's still good do be able to grovel through the RI to see what 
it does, without worrying that you may be contaminating your code with the 
XYZL.

Of course the RI is only part of Java, but it's a big part. TCKs are special 
in that a particular version of the code is normative, so modified versions 
need to be clearly marked as such (Apache licence?). And then there are the 
specifications - too many of these are currently marked "it's OK to read this 
just as long as you don't intend to implement it". The specs should be 
licensed in a way that is compatible with the requirements of standards 
bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head that way 
just yet.

Copyright (C) Chris Gray 2006. The views expressed are not necessarily those 
of Harmony, Classpath, my company, or my cat.

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369

Re: Bringing License arguments to Sun

[Simon Phipps]

On Aug 20, 2006, at 09:54, Chris Gray wrote:


+1 to Stefano Mazzocchi:


Noted, thanks.  (and edited so I am making fair use of your  
copyrighted material - I don't want to get sued...)



 The specs should be
licensed in a way that is compatible with the requirements of  
standards
bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head  
that way

just yet.


Keep in mind that Sun doesn't get to decide this any more, it's up to  
the JCP, and there are plenty of voices other than Sun who would  
likely oppose this. While I sympathise, open sourcing Sun's Java  
implementations has nothing to do with the JCP and is made possible  
by the JCPA 2.5 and later.


S.

Re: Bringing License arguments to Sun

[Simon Phipps]

On Aug 20, 2006, at 03:38, Stefano Mazzocchi wrote:


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.


Thanks, Stefano, I appreciate the rationale and the time and thought  
that's gone into writing it. I'll make sure this outlook is represented.


S.

Re: Bringing License arguments to Sun

[Chris Gray]

On Sunday 20 August 2006 12:27, Simon Phipps wrote:
> On Aug 20, 2006, at 09:54, Chris Gray wrote:
> > +1 to Stefano Mazzocchi:
>
> Noted, thanks.  (and edited so I am making fair use of your
> copyrighted material - I don't want to get sued...)

My cat can be vicious. :-)

> >  The specs should be
> > licensed in a way that is compatible with the requirements of
> > standards
> > bodies such as ISO, ANSI, ECMA, even if Sun doesn't intend to head
> > that way
> > just yet.
>
> Keep in mind that Sun doesn't get to decide this any more, it's up to
> the JCP, and there are plenty of voices other than Sun who would
> likely oppose this. While I sympathise, open sourcing Sun's Java
> implementations has nothing to do with the JCP and is made possible
> by the JCPA 2.5 and later.

True, but quite often the spec lead is from Sun, e.g. for 218/219 (JavaME CDC/
FP). In such cases, if the Exec Comittee agrees Sun can set an example by 
licensing the specs in a way which would not preclude them being adopted as a 
standard by ISO & co.

BTW the comments made by EC members wrt JSR 218 seem to indicate that there is 
quite widespread support for a more open approach[1].

Best regards,

Chris

[1] .

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369

Re: Bringing License arguments to Sun

[Stefano Mazzocchi]

Simon Phipps wrote:
> 
> On Aug 20, 2006, at 03:38, Stefano Mazzocchi wrote:
> 
>> 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.
> 
> Thanks, Stefano, I appreciate the rationale and the time and thought
> that's gone into writing it. I'll make sure this outlook is represented.

Simon,

Thank you.

-- 
Stefano.

Re: Bringing License arguments to Sun

[Stefano Mazzocchi]

Geir Magnusson Jr wrote:

>> CDDL is an example of clever lawyer work to modernize best licensing
>> practices, but those are best practices in protection not in social
>> empowerment!
> 
> I don't understand that.  Do you see the CDDL as somehow restricting
> communities? 

No, I see CDDL something that will significantly slow or hinter the
licensing compatibility assessment from both the ASF and the FSF.

I fully recognize the lack of IP protection in older licenses (which
might look like a naive "if we ignore it maybe it will go away" policy )
but I think that licensing the code, the trademarks and the IP
separately is another fully viable strategy.

I would use an MIT license for the code and a different license for the
IP. The "injected IP" problem can be dealt with a contribution agreement
which does *not* need to be part of the license (like apache did, for
example).

As far as IP protection is concerned, Sun owns (or has acquired the
rights to relicense) the existing IP, they will only need to be
concerned about new ones coming in from contributions and for that they
can have contributors sign IP agreements (like we do for Harmony, for
example, even if the license, in theory, already covers that).

So, in theory, one could take an MIT-licensed RI, add some code with
special IP (say a new garbage collector), pass the tests and then decide
to charge people for the license of that IP.

Sun could decide that they consider this "free riding" and that they
want everybody to have a piece of that cake, so they can use a license
that is not violently reciprocal on code donations but it is on IP (and
 CDDL falls under this category).

The problem with this, it's that it makes it incompatible with the GPL,
ending up alienating some of the very people they are counting on
pleasing (and you can expect all sort of internal and external
frustration would that happen).

So, the choice is, in my eyes, whether to 'enforce' the reciprocity of
IP licensing of not.

Here, there is a lesson to be learned from the reciprocity on code: the
BSD license does *not* force you to contribute back but many do anyway,
and the freedom of being allowed *not to* is what makes the BSD license
more palatable than, say, the GPL to many (unless you use a mysql-like
unlock-the-gpl business model, which is another story).

People contribute back even if they are not forced to because it's
convenient for them to do so, or they are left with the burden of
maintaining a branch. The same exact argument applies to IP.

So, if the RI license does *not* force people to donate the IP to the
modifications that are made and redistributed (after passing the tests
and obtaining certification), they are actually forking, just like OSI
licenses are designed to allow. But they are now on their own, against
the rest of the world. The FOSS ecology has shown that branches are very
hard to maintain anyway, especially against very active and healthy
communities (which has become the ASF motto, community is more important
than code, and, I would add, a license has to protect the community more
than the code).

And if the fork is killed or goes unfeasible and people try to inject
known or submerged IP with contributions to the RI, the community
watching and a solid contribution agreement will prevent that.

In case of contributions that are covered by unknown IP, there is very
little one can do to prevent in the license that covers the "usage" of
the code.

My reasoning for going simple and non-reciprocal for both code and IP is
*not* that I'm ignoring the issue, it's that there is no need for a
reciprocal licensing of the IP, as I claim that it will be
socio-economically inconvenient for anybody to do so. They will try,
they will fail, as much as there is no apache# or tomcat++.

Just like the BSD, giving people the "freedom of choice" on whether to
donate code back or keep it for themselves, has been proved to be
*extremely* effective in creating healthy, innovative and open
contribution ecosystems. I believe the same freedom on IP contribution
is a valid and not more risky strategy that will make the java RI code
maximally used and, just like other examples, foster compatibility by
becoming, de-facto, the only socio-economically maintainable/feasible
implementation over time.

And the choice of maximum freedom (given OSI/free-software parameters)
and maximum compatibility is, IMHO, a necessary condition for a social
ecosystem and dynamics that will guard the RI way more effectively (and
at lower costs!) than any license or army of lawyers can do.

> I think that CDDL is a reasonable license, and if I wasn't
> allowed to use a BSD-style license for whatever reason, I'd go that way...

I never said it's a bad license. I'm saying it's not the one I would
choose and I gave a socio-economical analysis on why I think this is so.

CDDL will lower the perceived fear of "free riding" using IP protection
strategies in Sun executives, but at the price of alienating a 

Re: Bringing License arguments to Sun

[Wes Felter]

Chris Gray wrote:

TCKs are special 
in that a particular version of the code is normative, so modified versions 
need to be clearly marked as such (Apache licence?).


If One TCK is so important, let me propose a semi-heretical idea: don't 
open it. Certainly the 400 JVM developers should be able to run the TCK, 
but it's not clear that they need to distribute modified versions. (Of 
course, they could still submit bug fixes and such to the TCK 
maintainers.) I don't think the Linux distros need to distribute the TCK 
either, so their "OSI or die" policy doesn't appear to affect the TCK.


Wes Felter - [EMAIL PROTECTED]

Re: Bringing License arguments to Sun

[Mark Wielaard]

Hi Wes,

On Mon, 2006-08-21 at 13:53 -0500, Wes Felter wrote:
> If One TCK is so important, let me propose a semi-heretical idea: don't 
> open it. Certainly the 400 JVM developers should be able to run the TCK, 
> but it's not clear that they need to distribute modified versions. (Of 
> course, they could still submit bug fixes and such to the TCK 
> maintainers.) I don't think the Linux distros need to distribute the TCK 
> either, so their "OSI or die" policy doesn't appear to affect the TCK.

Of course the Linux distros need it! One of the great strenghts of
distributions is their ability to run the testsuite for all packages
they build. And to give their users the power to repeat the build
process and do their own checking of the results. It is a critical part
of quality control. So when you build your deb/rpm/etc (possibly with
distro specific patches) you run the testsuite and fail if some tests
don't give clean results. That is how GCC for example works. There are
even distros that only ship (easily buildable) source code so as to
optimize any binary for your personal system. Then it is even more
important that the user also gets the testsuites to make sure their
special customized build on their own hardware is perfect. And it might
very well be that to do that you have to adapt, modify and hack the
testsuite to run and build in your particular packaging environment (and
run it non-interactively). Don't forget that free software breaks down
the artificial barrier between users and developers. Everybody is a core
library, runtime, compiler, package, etc hacker now. So everybody should
also take the responsibility and run any testsuites. Your users will
demand it from you.

Cheers,

Mark

Re: Bringing License arguments to Sun

[Leo Simons]

(I looked at http://community.java.net/jdk/opensource/ for a
feedback button or something but can't find it. Thanks for listening
anyway!)

Licensing
-
On Sat, Aug 19, 2006 at 07:38:36PM -0700, Stefano Mazzocchi wrote:
[what license should Sun use to open source java]
> I'll bite: the MIT license.

+1, for all the reasons Stefano described. Along with the neccessary,
explicit, relevant patent grants, preferably with GPL-compatible terms
(eg non-reciprocical; would probably automatically meet requirements
off standards bodies and open source orgs worldwide).

The most important concern as I see it in terms of open source java
license choice is to de-fragment the ecosystem as much as possible.
If sun makes haste, I can still see java becoming the #1 language for
desktop applications 'n stuff, and I can still see us all surviving
the longhorn assault that's coming. Dalibor's written a lot of good
stuff on his blog:

  http://www.advogato.org/person/robilad/diary.html?start=103

(I would paint a little different history lesson and I don't like
dual licensing as a long-term strategy, but other than that its spot
on.)

Now, to dwell on alternatives. My personal opinions.

If MIT license is not possible, next up is ASLv2 since it will
still mean (after GPLv3 finalizes) that code can be incorporated
downstream in both apache (harmony and other projects, think
jakarta commons, xml commons, yoko) and GNU (classpath and other
projects like gcj).

If ASLv2 is not possible the next preference up is probably a
custom license that still allows pieces to be mixed and matched
with both the "Free Software" and "Open Source" parts of the
ecosystem. I imagine any such license would still come somewhat
close to ASLv2, and I'll highlight how painful introducing new
licenses is for the entire ecosystem. Please don't do it again :)

If that is not possible, I'll go and be an "ASF heretic" and say
it should be GPLv3. That way, at least healthy co-operation
between the GNU communities and "jonathan java" will still be
possible. In a way it'd be tough luck for harmony, since we've pretty
much determined already we wouldn't be able to depend on GPLv3
pieces, but it would still allow a fruitful "downstream merge"
with "jonathan java" and classpath incorporating the best harmony
bits. The bigger ecosystem still wins. And most "apache java" people
will have no problem making use of GPLed stuff - we're all GCC
users already for example ;).

If that is not possible, I guess the last realistic alternative is
the CDDL. I like the CDDL and I use it for some of my hobby
projects. Its "category B" in the ASF 3rd party license policy
draft [1], so it would still allow some kind of co-operation between
"jonathan java" and harmony. **But** IIUC its still undecided whether
the GPLv3 will be compatible with the CDDL, which potentially means
closing off -- rather permanently -- a really big part of the FLOSS
java community. In this picture, I see all java being ripped out of
OpenOffice (or OO.o suffering from forks and communit dissent),
Java-GNOME and the like not being used, in favor of mono, and java
permanently losing a position on the desktop of anyone but java
developers themselves. Sure, it'll still thrive on the server and
open source java will still be loads of fun, but I'd be removing the
"swing" keyword off my resume.

Last legal point -- I'm guessing all license choices are somehow ok to
the opensolaris community -- GPL is by virtue of having GCC and gnome
and stuff around, CDDL is obviously, and ASL is too by virtue of having
the web server on there.

Governance
--
You know, I'm just not too fussed. You guys will get it right "enough".
Java.net seems to be "working as intended" these days, opensolaris.org
is shaping up nicely, even OO.o is seeing more and more of an actual
community. Listen to all the stuff Geir has to say about the JCP and
opening that up further and then we'll be fine. The jini stuff coming to
apache is a further nice exercise.

Cool!
-
Its not just about those 400-or-so open source developers who will be
working on java. Its about all the weird stuff you're not planning or
expecting that will rock the industry; providing rocket fuel to the
crazy rocket scientists. The proper port to BSD might unearth a 10 year
old bug than when fixed means a 15% performance improvement on linux.
Who knows.

The network is the computer, and the community is the real network.

I know I know, preaching to the choir, but somehow this is all being
de-emphasized. Open source is cool, and open source java will be, too!

My main personal interest is that I'll somehow be able to bootstrap a
system all the way from bootstrapping GCC up to big J2EE-based systems
while doing all sorts of interesting measurements (Re: gump) and thus
improve the stability/maintainability of the whole stack. But I'm a
little weird like that. All I need now is open source oracle...

LSD

[1] -- http://www.apache.org/legal/3party.html

Re: Bringing License arguments to Sun

[Chris Gray]

On Wednesday 23 August 2006 13:22, Leo Simons wrote:

> Licensing
> -
> On Sat, Aug 19, 2006 at 07:38:36PM -0700, Stefano Mazzocchi wrote:
> [what license should Sun use to open source java]
>
> > I'll bite: the MIT license.
>
> +1, for all the reasons Stefano described. Along with the neccessary,
> explicit, relevant patent grants, preferably with GPL-compatible terms
> (eg non-reciprocical; would probably automatically meet requirements
> off standards bodies and open source orgs worldwide).

Typically standards orgs have a patent policy already in place, see e.g. [1], 
[2]. These are probably the result of quite a lot of thought and discussion, 
so they should be read not just as something with which a proposed patent 
grant needs to be compatible but also as prior art in this field.

[1] 
[2] 

-- 
Chris Gray/k/ Embedded Java Solutions  BE0503765045
Embedded & Mobile Java, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369