harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Bringing License arguments to Sun
Date Sun, 20 Aug 2006 12:47:36 GMT
The only problem I see with the MIT license is the lack of modern patent
language.   I'd like to see a license with that in place.  I know the
GPL is incompatible with such things, but the GPL-ers recognize it as a
problem and are fixing it in GPLv3.

By the time Sun gets everything done in open sourcing their
implementation, maybe the GPLv3 will be complete.

Maybe this will push the GPL community to get v3 done :)


Stefano Mazzocchi wrote:
> 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.

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message