You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by theUser BL <th...@hotmail.com> on 2006/08/19 20:57:22 UTC
Bringing License arguments to Sun
At
http://forums.java.net/jive/thread.jspa?threadID=17634&tstart=0
Sun's Chief Open Source Officer Simon Phipps alias webmink
http://forums.java.net/jive/profile.jspa?userID=70
wrotes, that he have still not decided, which OpenSource license will be
used for Suns Java.
He wrote:
" To be clear, I've not expressed a preference for any particular license
yet. In fact, I think it's still unclear which of my license categories most
applies to the Java platform. I'm reading everything that's being written by
commentators from the various Java communities, however, and I'm keen for
Sun to make license choices that create the best future for us all. I've
discussed this further in my blog at
http://blogs.sun.com/roller/page/webmink?entry=why_bother_open_sourcing_java
"
So to all of the OpenSource-Java folks:
If you prefer a special license or a special license form and you have
reasons, why you think, that your prefered license would be the best for
Java, then write it at Suns OpenSource JDK forum at
http://forums.java.net/jive/forum.jspa?forumID=97
Actually is still the time, where you can influence, which license Suns Java
will have.
Greatings
theuserbl
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Vladimir Gorr <vv...@gmail.com>.
Perhaps it would be interesting to you to know about this voting:
http://www.java.net/pub/pq/116
Thanks,
Vladimir.
On 8/24/06, Chris Gray <ch...@kiffer.be> wrote:
>
> 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] <http://www.ecma-international.org/memento/codeofconduct.htm>
> [2] <http://www.niso.org/committees/OpenURL/PATPOL.pdf>
>
> --
> Chris Gray /k/ Embedded Java Solutions BE0503765045
> Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
> chris.gray@kiffer.be +32 3 216 0369
>
>
> ---------------------------------------------------------------------
> 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
>
>
Re: Bringing License arguments to Sun
Posted by Chris Gray <ch...@kiffer.be>.
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] <http://www.ecma-international.org/memento/codeofconduct.htm>
[2] <http://www.niso.org/committees/OpenURL/PATPOL.pdf>
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Simon Phipps <we...@sun.com>.
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.
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Gregory Shimansky <gs...@gmail.com>.
On Tuesday 22 August 2006 23:37 Dalibor Topic wrote:
> Geir Magnusson Jr. wrote:
> > Maybe - or just declaring a patent peace or patent commons. I think
> > that there's nothing wrong with proprietary software, so if they want
> > to keep competing using it, great.
>
> I don't see a point in proprietary JVMs, and class libraries for major
> operating systems, in today's situation.
>
> The only purpose I could see them used for is as a tool for attacks on
> the integrity of the platform through locking in users into proprietary
> extensions.
> I don't think the market would be able to sort out a distributor with a
> strong channel, like IBM, that went that route, as our experience in
> Apache Harmony
> with code using unspecified sun.* classes shows.
I am not sure this is the case for big corporation's own Java implemetations.
It is likely Sun cares about its own priorities and in case of IBM for
example it doesn't care how well Java runs on Power. It could be a reason
enough to write a proprietary Java VM. And since all of corporations license
classlib from Sun they all have to implement sun.* classes to an extent to
make classlib functional.
> 'Never again' should be the motto for IBM & BEA, imho. They should let
> deeds follow the open letters, and open up their
> proprietary implementations.
No one knows which license agreements they've signed to get classlib. It could
be impossible to them to open the implementation too tightly tied with Sun's
classlib.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Chris Gray wrote:
> On Tuesday 22 August 2006 23:35, Geir Magnusson Jr. wrote:
>
>> How about real-time GC? Clearly an extension - the spec says nothing
>> about doing GC in real-time - but I bet the aeronautical and military
>> industry would pay for something like that...
>
> Indeed they do, and not infrequently they become Classpath users as a result.
> But perhaps we should get on with "Bringing License arguments to Sun", rather
> than just having "License arguments"?
I never think there's anything wrong with discussion :)
(especially since the thread is marked and ignorable...)
geir
>
> Chris
>
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Chris Gray <ch...@kiffer.be>.
On Tuesday 22 August 2006 23:35, Geir Magnusson Jr. wrote:
> How about real-time GC? Clearly an extension - the spec says nothing
> about doing GC in real-time - but I bet the aeronautical and military
> industry would pay for something like that...
Indeed they do, and not infrequently they become Classpath users as a result.
But perhaps we should get on with "Bringing License arguments to Sun", rather
than just having "License arguments"?
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Dalibor Topic wrote:
> On Tue, Aug 22, 2006 at 04:18:48PM -0400, Geir Magnusson Jr. wrote:
>> Dalibor Topic wrote:
>>> Geir Magnusson Jr. wrote:
>>>
>>>> Maybe - or just declaring a patent peace or patent commons. I think
>>>> that there's nothing wrong with proprietary software, so if they want
>>>> to keep competing using it, great.
>>> I don't see a point in proprietary JVMs, and class libraries for major
>>> operating systems, in today's situation.
>>>
>>> The only purpose I could see them used for is as a tool for attacks on
>>> the integrity of the platform through locking in users into proprietary
>>> extensions.
>> How about performance, either in speed, real-time predictability, memory
>> usage/footprint, reliability, serviceability, manageabliity?
>>
>
> I am talking about proprietary extensions, you're talking about memory
> footprint. One has nothing to do with the other. Could we stay on topic,
> please?
I wasn't only talking about "memory footprint". How about native
integration with Tivoli? Proprietary and an extension, and something
that people will and probably do pay for.
How about real-time GC? Clearly an extension - the spec says nothing
about doing GC in real-time - but I bet the aeronautical and military
industry would pay for something like that...
>
>> I can see all of these, and none of these are an attack on the Java
>> compatiblity promise.
>>
>> Sure, they are features that are beyond the scope of the specs, and
>> sure, you may be "locked in" in the sense you depend on some feature
>> (integration with your favorite management system), but your programs
>> are portable...
>>
>>> I don't think the market would be able to sort out a distributor with a
>>> strong channel, like IBM, that went that route, as our experience in
>>> Apache Harmony
>>> with code using unspecified sun.* classes shows.
>> LOL. What experience is that? What we're doing this is just supporting
>> what has become the 'de facto' spec from Sun. :)
>
> No. What we're doing is clapping our hands with forte because Sun has been
> kind enough to announce that they'll open up all of their code base,
> including the unspecified bits, which would allow us, in theory, to
> integrate them, without having to reverse engineer them.
>
> Do you want to take a bet that the next 'de facto' standard extensions
> will be opened up within 10 years by their owners, or less?
>
> I don't want proprietary Java vendors to waste our time in the future with
> undocumented de-facto standards around proprietary extensions.
I think there's a big difference with someone choosing to use a base64
encoder that just happens to be in the sun package namespace because
they saw someones example doing that, and extensions that are intended,
designed and marketed to cause some kind of lock in.
geir
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Dalibor Topic <ro...@kaffe.org>.
On Tue, Aug 22, 2006 at 04:18:48PM -0400, Geir Magnusson Jr. wrote:
> Dalibor Topic wrote:
> >Geir Magnusson Jr. wrote:
> >
> >>Maybe - or just declaring a patent peace or patent commons. I think
> >>that there's nothing wrong with proprietary software, so if they want
> >>to keep competing using it, great.
> >
> >I don't see a point in proprietary JVMs, and class libraries for major
> >operating systems, in today's situation.
> >
> >The only purpose I could see them used for is as a tool for attacks on
> >the integrity of the platform through locking in users into proprietary
> >extensions.
>
> How about performance, either in speed, real-time predictability, memory
> usage/footprint, reliability, serviceability, manageabliity?
>
I am talking about proprietary extensions, you're talking about memory
footprint. One has nothing to do with the other. Could we stay on topic,
please?
> I can see all of these, and none of these are an attack on the Java
> compatiblity promise.
>
> Sure, they are features that are beyond the scope of the specs, and
> sure, you may be "locked in" in the sense you depend on some feature
> (integration with your favorite management system), but your programs
> are portable...
>
> >I don't think the market would be able to sort out a distributor with a
> >strong channel, like IBM, that went that route, as our experience in
> >Apache Harmony
> >with code using unspecified sun.* classes shows.
>
> LOL. What experience is that? What we're doing this is just supporting
> what has become the 'de facto' spec from Sun. :)
No. What we're doing is clapping our hands with forte because Sun has been
kind enough to announce that they'll open up all of their code base,
including the unspecified bits, which would allow us, in theory, to
integrate them, without having to reverse engineer them.
Do you want to take a bet that the next 'de facto' standard extensions
will be opened up within 10 years by their owners, or less?
I don't want proprietary Java vendors to waste our time in the future with
undocumented de-facto standards around proprietary extensions.
cheeers,
dalibor topic
> >
> >'Never again' should be the motto for IBM & BEA, imho. They should let
> >deeds follow the open letters, and open up their
> >proprietary implementations.
>
> I don't disagree - I'd love it if they offered the source for J9 or
> JRocket to Harmony :)
>
> geir
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Dalibor Topic wrote:
> Geir Magnusson Jr. wrote:
>
>> Maybe - or just declaring a patent peace or patent commons. I think
>> that there's nothing wrong with proprietary software, so if they want
>> to keep competing using it, great.
>
> I don't see a point in proprietary JVMs, and class libraries for major
> operating systems, in today's situation.
>
> The only purpose I could see them used for is as a tool for attacks on
> the integrity of the platform through locking in users into proprietary
> extensions.
How about performance, either in speed, real-time predictability, memory
usage/footprint, reliability, serviceability, manageabliity?
I can see all of these, and none of these are an attack on the Java
compatiblity promise.
Sure, they are features that are beyond the scope of the specs, and
sure, you may be "locked in" in the sense you depend on some feature
(integration with your favorite management system), but your programs
are portable...
> I don't think the market would be able to sort out a distributor with a
> strong channel, like IBM, that went that route, as our experience in
> Apache Harmony
> with code using unspecified sun.* classes shows.
LOL. What experience is that? What we're doing this is just supporting
what has become the 'de facto' spec from Sun. :)
>
> 'Never again' should be the motto for IBM & BEA, imho. They should let
> deeds follow the open letters, and open up their
> proprietary implementations.
I don't disagree - I'd love it if they offered the source for J9 or
JRocket to Harmony :)
geir
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Dalibor Topic <ro...@kaffe.org>.
Geir Magnusson Jr. wrote:
> Maybe - or just declaring a patent peace or patent commons. I think
> that there's nothing wrong with proprietary software, so if they want
> to keep competing using it, great.
I don't see a point in proprietary JVMs, and class libraries for major
operating systems, in today's situation.
The only purpose I could see them used for is as a tool for attacks on
the integrity of the platform through locking in users into proprietary
extensions.
I don't think the market would be able to sort out a distributor with a
strong channel, like IBM, that went that route, as our experience in
Apache Harmony
with code using unspecified sun.* classes shows.
'Never again' should be the motto for IBM & BEA, imho. They should let
deeds follow the open letters, and open up their
proprietary implementations.
cheers,
dalibor topic
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Dalibor Topic wrote:
> Stefano Mazzocchi wrote:
>
>> I understand you are concerned about the SCO-like patent attacks of
>> somebody coming in and telling you that you can't run your own code
>> because they own the rights to the concept... but if that is the case
>> against the RI, we have a way bigger problem and that's nothing a
>> license can fix.
>>
>>
> I think a good part of the nightmare scenarious surrouding licensees
> going mad and trying to
> fracture the platform for fun and profit could be fixed quite easily by
> IBM and BEA dropping
> their cards on the table, and going open source with their proprietary
> implementations of
> Java as well.
Maybe - or just declaring a patent peace or patent commons. I think
that there's nothing wrong with proprietary software, so if they want to
keep competing using it, great.
>
> The platform will be much stronger against external attacks if the large
> vendors are in the
> same boat with Sun, rather than if strong stakeholders have an incentive
> to innovate on
> proprietary branches, and perpetuate the current lock-in-based licensing
> schemes.
Well, I think there's a balance to be had... that you want people to
have an investment in the codebase held "in common", as well as the
ability to invest in innovation.
>
> I don't think the market could sort a proprietary fork from IBM out
> easily, for example.
I don't understand what that means.
> And I don't think it should have to, given IBM's and BEA's open letter
> campaign for open
> source Java a little while ago.
>
> It's time to put up, and invest into the future of the platform, rather
> than future of lock-in.
One way would be for everyone to work on a common codebase for things
that are shared, in a symmetrical, equal fashion, with the ability to do
whatever proprietary work they want too...
geir
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Dalibor Topic <ro...@kaffe.org>.
Stefano Mazzocchi wrote:
>I understand you are concerned about the SCO-like patent attacks of
>somebody coming in and telling you that you can't run your own code
>because they own the rights to the concept... but if that is the case
>against the RI, we have a way bigger problem and that's nothing a
>license can fix.
>
>
I think a good part of the nightmare scenarious surrouding licensees
going mad and trying to
fracture the platform for fun and profit could be fixed quite easily by
IBM and BEA dropping
their cards on the table, and going open source with their proprietary
implementations of
Java as well.
The platform will be much stronger against external attacks if the large
vendors are in the
same boat with Sun, rather than if strong stakeholders have an incentive
to innovate on
proprietary branches, and perpetuate the current lock-in-based licensing
schemes.
I don't think the market could sort a proprietary fork from IBM out
easily, for example.
And I don't think it should have to, given IBM's and BEA's open letter
campaign for open
source Java a little while ago.
It's time to put up, and invest into the future of the platform, rather
than future of lock-in.
cheers,
dalibor topic
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
>> Stefano Mazzocchi wrote:
>>> 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'm going to assume that from here forward, when you say "IP" you mean
>> 'patent'?
>
> For IP I mean, "anything besides the code that you need to have licensed
> in order for you to run a piece of code that you legally obtained a copy
> of".
>
> For example, the code might be open source but written in a language
> where the compiler is closed source and for pay. That makes it possible
> to run it and the license might even allow you to modify the source
> code, but without the compiler that freedom is useless.
>
> The anti-DRM provision planned in the GPL3 is another form of IP
> reciprocity, where "IP" in this case is a cryptographic key that is
> needed to sign the code that will be run by the machine executing it.
> Again, having the source code licensed under a very free license is
> useless if the environment that runs it limits you in other ways.
>
> Of course, patents follow under the same category as well.
>
>>> 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).
>> But our license is very explicit about patents as well.
>
> Sure and, if you ask me, it calms your irrational fears more than it
> provides you with instruments to fight a patent-driven litigation.
>
>>> 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).
>> Yes....
>>
>>> 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.
>> Yes - I'm all for that. And you can achieve that w/ CDDL also. (I'm
>> not pushing CDDL here - my choice would be Apache License knowing that
>> all will be well w/ GPLv3, which I thought was scheduled to arrive at
>> about the same time as the code from Sun anyway...
>
> That is my second best solution. If MIT/X is too weak and too old, the
> Apache License is the most modern license of the BSD branch but its
> GPLv2 incompatible.
>
> It is true that the GPLv3 is specifically tasked to be compatible with
> patent reciprocity clauses (which are appreciated by the free software
> community, just were not taken into consideration at the time of the
> GPLv2) but it is also true that Sun will take a considerable amount of
> time as well to make a licensing decision.
>
> So, let me put it this way: if the GPLv3 was out today, my suggestion
> would be Apache License: protecting on trademarks, non-reciprocal on
> code, reciprocal on patents and ignoring other IP issues (such as DRM).
> With this choice, both sides would be able to use the software.
>
> But since GPLv3 is still vaporware until I see RMS clapping, I think
> that MIT/X is a better choice right now.
Sure, but Sun has the luxury of time themselves. They have announced
javac and hotspot this year, and then the rest by June.
Maybe they could work out something interesting because of that.
>
>>> 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).
>> But GPLv3 is coming.
>>
>>> 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 [legal]story).
>> Few things in this paragraph :
>>
>> 1) I prefer to think of BSD as not restricting your freedom, rather than
>> allowing you to something, but as it is a license, it is in a sense
>> allowing the freedom.
>
> freedom is a highly abused term. Both "open source" and "free software"
> are based on basic principles (the same, actually, just worded
> differently and with different ethical/moral attachments) but at the end
> they "restrict" somebody to "free" somebody else. So, it's not true that
> BSD is really free and GPL is not because forces code reciprocity: it
> just depends on what you value most and who you want to protect/empower,
> the user or the developer.
>
> I like to categorize licenses by their restrictions rather than their
> freedoms, since this has much simpler moral complexities to deal with.
Sure. That makes the GPL/BSD difference even easier to describe :)
>
>> 2) MySQL - No comment, other than I'd not be too keen in participating
>> in a MySQL-like ecosystem around a Java implementation.
>
> Agreed.
>
>>> 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.
>> I don't see that. There's no burden to not contributing patent licenses
>> to a codebase, compared to maintaining an "internal fork" if you choose
>> not to give modifications back to the community.
>
> That is a good point, but misses mine.
>
> Let me rephrase: the starting point is that all existing IP that covers
> the RI is owned or licensed by Sun. The current state of affairs is that
> you get a license for that IP once you pass the certification tests and
> either, you pay or you are a non-profit.
>
> If it is not true that Sun doesn't own all the IP on the RI and there is
> somebody else sitting out there with a submerged patent on it, the Java
> ecosystem has much bigger issues than what license to use for the RI
> codebase, so let's use that as a working starting point.
I think that it's not unreasonable to believe that there are patents out
there on Java not held or licensed by Sun, but I'm not really worried
about them.
>
> So, this means there is nobody out there sitting on the existing
> codebase with a patent that the user community cannot get a license to
> (if their code passes certification).
I don't believe that, but I don't believe that for any software, so my
position isn't special to Java. And again, I don't worry about that
because, well, it's not really pragmatic to go hunting down trouble when
I think that such a thing is really impossible :)
>
> Now, there are three cases:
>
> 1) BigCoWithPatent forks the RI, adds some code that implements one of
> their patents.
>
> 2) BigCoWithPatent donates some code to the RI that is covered by a
> patent they own but they don't say so.
>
> 3) Joe Committer donates some code to the RI that is covered by a
> patent that BigCoWithPatent owns and nobody (yet) knows.
>
> For #1, my claim is that if they have a patent and it's not already
> covering RI code, there will have to be some other code to implement
> such patent. Since such patent would not be trivial matter (or at least
> one would hope) and it is not already covered by the RI (or it would be
> easy to fight it as prior art), therefore it's implemented by a code fork.
Right - I don't think we care about #1. People are free do to what they
want.
>
> the ASF has experienced "private branches" but no fork in the
> Emacs/XEmacs or Free/Open/NetBSD sense where the codebases diverge in
> both community and functionality. BigCoWithPatent might decide that it's
> economically feasible for them to keep investing on a private branch,
> just like say IBM does with WebSphere for HTTPD. For HTTPD, that is a
> small price to pay for "owning" the HTTP serving market. As much as we
> consider non-reciprocity of code a small price to pay for the social
> comfort it generates, I don't understand why you feel that patents are
> different.
Because there's work required in maintaining the private internal branch
- in not giving back - because you will probably want to harvest cool
things from the public project.
As for not offering a patent license? it's painless. You just don't do
it. No followup is needed.
>
> I understand you are concerned about the SCO-like patent attacks of
> somebody coming in and telling you that you can't run your own code
> because they own the rights to the concept... but if that is the case
> against the RI, we have a way bigger problem and that's nothing a
> license can fix.
It doesn't solve every problem, but it would induce patent harmony among
the participants, at least. Of course, my vision is that everyone is
participating on the core of this - so that we have a core VM and
complete classlibrary that all can use, and then do private innovation
on performance and ports and such.
>
> So you are complicating the protections for no rational reason.
>
I don't think so, because we want a situation where the IP grants are
clear, explicit and forever, and not dependent upon the current goodwill
of any participating entity to continue.
> For #2, a CLA (contribution licensing agreement) protects you.
Protects whom and how?
>
> For #3, it's pain but it's pain no matter what license you choose since
> the guy donating the code doesn't own the rights anyway, so reciprocity
> doesn't work anyway.
Agreed - there's nothing that one can do here. It's like my view on
patents outside of the contributors - no reason to go looking.
>
>>> 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).
>> I'm still not seeing it if my assumption about you meaning "patent" when
>> you say "IP" is valid - what it could do is create a situation where no
>> one would want to do anything out of fear of patent action. Modern OSS
>> licenses solve this partway by having contributors explicitly license
>> patents they own that are covered by their contributions.
>
> I have explicitly mentions that there is no need for a CLA (the "input"
> license) to be embedded in the "output" one. It is a decision that the
> ASF made but, if you ask me, it didn't really help us since, just to
> sure, we get CLAs for committers anyway.
But we get CLAs for different reasons, I thought - we get CLAs to
demonstrate that the ASF is doing due diligence to ensure that
contributions it gets are valid, and that the poeple making the
contributions understand the terms under which they are contributing.
IOW, BadActorBob could contribute someone elses code with or without the
CLA in place - but with the CLA in place, the ASF has a better chance of
showing that it didn't participate in contributory infringement as that
BadActorBob stated he understood by signing the CLA.
>
> It helps on those little patches that people don't sign a CLA for, but I
> strongly doubt that Sun would allow even a single line of code to enter
> the code repository without some sort of licensing agreement between the
> parties involved, including individuals.
That's fine - I'm all for agreements. What I want to avoid there (and
this is tangential to the patent protection in license discussion) is
assymmetry in freedom to relicense - because I think that will limit
participation, and we want everyone involved in open source java.
>
> So, here's my detailed proposal:
>
> - MIT/X on the way out
>
> - ASF-like CLA on the way in for *any* contribution (you can make that
> click-thru when you apply a patch on jira)
I don't think the CLA does any more than the license wrt IP... does it?
how?
>
> - trademark and patent licenses separate, free for non-profits that
> pass the TCK.
>
> - The TCK freely available to download and run with no NDA or
> restriction on result publication on your own certification status. The
> "open source" status of the TCK is non really that important.
Agreed on last sentence - the only thing that open source does is remove
all sorts of fear that people have in touching the code.
I put it another way to someone else earlier today :
The TCK is a combination of stuff - not just tests. So make the test
code open source, and distinguish that from the TCK, which is an item
you still have to license from the spec lead. IOW,
TCK == 'other stuff' + 'test code'
and if test code is in oss, then the limits to participation in the code
aspects are greatly reduced. People might not want to sign up for
whatever the TCK license has in it, but if they can work with the code
in the project, find and fix bugs, then things should go better.
>
>>> 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.
>> I don't understand that sentence.
>
> Case #3 above.
Got it - thanks
>
>>> 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.
>> I think that there actually is a problem because of the asymmetry in the
>> ecosystem.
>>
>> Big Co and Bigger Co have loads of patents on this technology, I
>> assume. Stefano Co. has zero.
>
> Correct, and this is true for every MIT/BSD/GPL/LGPL project out there
> but it has not stopped FOSS to exist or even stride, hasn't it?
Well, if you like that argument, why not have us all use GPL? :) GPL
hasn't stopped FOSS or broken it's stride :)
My point is that the OSS ecosystem is evolving, and the participants
entering it, the value of things being OSS licensed, and the stakes at
stake are much different than years ago.
Sure, Linux is incredibly economically valuable, but it was built
gradually starting from some guy in his shorts in Finland, to eventually
something where Fortune 50 companies are contributing and using.
But seeing Sun take Java, which represents a significant commercial
investment, and push that out 'suddenly', and having the other "big
players" decide to engage is a different thing.
Maybe it's best described as slowly boiling the frog, versus throwing
the frog into a roiling pot :)
At the end of the day, I think you can say the results are pretty much
the same, but i do believe that there is 'path dependence' to how one
arrives at those results.
>
>> Big Co and Bigger Co can cross license
>> to keep the peace between them. Stefano Co can't. Stefano Co is
>> subject to whatever whims Big Co and Bigger Co have unless mechanisms
>> like the patent languages in modern licenses are in force. True, by not
>> contributing, they stay clear of the patent license obligation, but a
>> counterstrategy to that is to try and form as big a 'commons' as
>> possible, leaving non-participants as outliers. IOW, create a community
>> of "patent peace", be it via a common codebase that all have contributed
>> to, or something more explicit - a patent pool or such.
>
> *yes* but this is performed by an *input* license (a patent-strong CLA)
> which does *NOT* need to be part of the *output* license.
>
> This is *my entire* point.
Ah. I still don't understand though. Who are the parties to the input
license? BigCo and Sun? (lets put some names here so it's clear) What
does StefanoCo do then?
>
>>> 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.
>> I guess I didn't understand the analysis, as I see that significant
>> threats remain within the resulting ecosystem, threats that if we don't
>> already know how to deal with, we're working hard on finding solutions.
>
> I'm sorry, but this is FUD.
How is it "FUD"? Clearly, I'm not the only one concerned about patent
protection, as you see it in every modern OSS license...
>
> I've outlined all the possible scenarios and I've shown that the
> licensing strategy that I proposed achieves the same protection level
> and increased compatibility *now*.
>
> If you disagree, please outline scenarios where my strategy fails and
> the reasons why.
I can't understand the strategy as I don't understand what the "input
license" is and who it's between.
In the case of the ASF CLA, that's a restatement of the terms of the
Apache license wrt copyright and patent, and some other additional
things like a statement of originality and ability to contribute.
>
> "I see significant threads within the resulting ecosystem" without
> detailed explanation and rationalization sound way too George W. for my
> taste.
The threat of patents, and how to create a system in which there's a
"patent peace" among all participants. I'll re-read what you wrote in
both messages, but I still don't grok it.
I think that the only reason why Sun would consider MIT is because of
the problem w/ the GPL. CDDL would be fine with us, but it's been
deemed not compatible with the GPL by the FSF.
>
>>> CDDL will lower the perceived fear of "free riding" using IP protection
>>> strategies in Sun executives, but at the price of alienating a huge part
>>> of the java FOSS ecosystem.
>> I dunno. Assume you have the GPLv3 now. Isn't that statement
>> non-operational?
>
> We *DO NOT* have GPLv3 now. My strategy is based on that.
>
> If we had GPLv3 now, and Apache License compatibility written all over
> it, the choice of the Apache License would be a no brainer.
>
Ok.
>> And since that's just a matter of months, isn't this really about having
>> a "brand approved" license that successfully interoperates, rather than
>> any real philosophical incompatibility?
>
> "matter of months"? please, don't insult our intelligence.
Sun claims that they will have things done by June 2007. The FSF is on
track to have GPLv3 done by May 2007. Which bit of your intelligence
was insulted there?
>
> But besides, license compatibility is a much less beneficial goal than
> social cooperation... and philosophical neutrality is a necessary
> precondition for any social cooperation.
>
> Sun could use the Apache License and bet on the GPLv3 social
> harmonization process to succeed, could choose CDDL and then dissipate a
> great deal of social friction or use the strategy I outlined and achieve
> the same results now, without bets, without delays and without social
> friction and without increasing risks.
Maybe. I need to grok the input license.
>
>>> Just like I'm sure Sun is willing to think about lack of reciprocity for
>>> code donations, I'm suggesting that they evaluate the same exact
>>> strategy for IP, trusting that the socio-economical dynamics that this
>>> will create will be a much more effective as a protection mechanism
>>> *and* will provide them with a solution that will win for them and will
>>> win for all the FOSS communities involved, no matter what current or
>>> past licensing beliefs.
>> I think you have to be really careful about how you think about that
>> "lack of reciprocity", because comparing it to how patents are treated
>> is very different. The "lack of reciprocity" in Sun's projects to date
>> is a copyright grant of joint ownership, not a license to use under terms.
>>
>> By asking for joint copyright, Sun is getting free and unfettered
>> licensing rights to do whatever they want with the code. A CDDL-style
>> or Apache License-style patent structure isn't the same thing.
>>
>> Very simply speaking, the Apache patent license boils down to this :
>>
>> "Each Contributor hereby grants to You a patent license to use (et al)
>> the Work"
>>
>> That doesn't mean "You" can do anything you want with that patent
>> license, which is what Sun is able to do with the joint copyright
>> assignment.
>>
>> Of course, Sun is free to continue with that if they choose. I just
>> hope that what they create is a level playing field, so there are no
>> needless barriers to participation.
>
> I've outlined both the "inbound" licensing strategy and the "outbound"
> one. Clearly, a good "inbound" one and a bad "outbound" one would ruin
> the dynamics just as bad.
>
> so, yes, I know very well that both needs to be defined and I understand
> why you like a license that defines both (so that you don't have to hope
> for the other one to be done right).
>
>>> I perfectly realize that I'm suggesting a bold move that might feel too
>>> risky, especially for somebody that has not experienced as much as we
>>> did in the ASF the power of social dynamics in respect to protection and
>>> stability.
>>>
>>> That said, it's hard to deny that the ASF has never experienced, in 10
>>> years of operation, a single fork, despite the complete lack of
>>> reciprocity provisions in its licensing strategy, showing that, although
>>> counterintuitive, healthy communities are even more effective than
>>> licensing restrictions in protecting the evolution of a codebase.
>> I agree with you, but there have been several forks over the years. IBM
>> forked httpd, IBM, JBoss, ObjectWeb others forked WS... I'd even argue
>> that Sun is technically forking Derby in their "JavaDB" product, and IBM
>> "pre-forked" Derby with the Cloudscape product that was the source of
>> Derby ... :)
>
> Those are 'vendor branches', they forked the code but the community is
> one. The ASF has never experienced a forked community, this is what I meant.
>
That is 100% true.
geir
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr wrote:
>
> Stefano Mazzocchi wrote:
>> 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'm going to assume that from here forward, when you say "IP" you mean
> 'patent'?
For IP I mean, "anything besides the code that you need to have licensed
in order for you to run a piece of code that you legally obtained a copy
of".
For example, the code might be open source but written in a language
where the compiler is closed source and for pay. That makes it possible
to run it and the license might even allow you to modify the source
code, but without the compiler that freedom is useless.
The anti-DRM provision planned in the GPL3 is another form of IP
reciprocity, where "IP" in this case is a cryptographic key that is
needed to sign the code that will be run by the machine executing it.
Again, having the source code licensed under a very free license is
useless if the environment that runs it limits you in other ways.
Of course, patents follow under the same category as well.
>> 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).
>
> But our license is very explicit about patents as well.
Sure and, if you ask me, it calms your irrational fears more than it
provides you with instruments to fight a patent-driven litigation.
>> 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).
>
> Yes....
>
>> 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.
>
> Yes - I'm all for that. And you can achieve that w/ CDDL also. (I'm
> not pushing CDDL here - my choice would be Apache License knowing that
> all will be well w/ GPLv3, which I thought was scheduled to arrive at
> about the same time as the code from Sun anyway...
That is my second best solution. If MIT/X is too weak and too old, the
Apache License is the most modern license of the BSD branch but its
GPLv2 incompatible.
It is true that the GPLv3 is specifically tasked to be compatible with
patent reciprocity clauses (which are appreciated by the free software
community, just were not taken into consideration at the time of the
GPLv2) but it is also true that Sun will take a considerable amount of
time as well to make a licensing decision.
So, let me put it this way: if the GPLv3 was out today, my suggestion
would be Apache License: protecting on trademarks, non-reciprocal on
code, reciprocal on patents and ignoring other IP issues (such as DRM).
With this choice, both sides would be able to use the software.
But since GPLv3 is still vaporware until I see RMS clapping, I think
that MIT/X is a better choice right now.
>> 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).
>
> But GPLv3 is coming.
>
>> 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 [legal]story).
>
> Few things in this paragraph :
>
> 1) I prefer to think of BSD as not restricting your freedom, rather than
> allowing you to something, but as it is a license, it is in a sense
> allowing the freedom.
freedom is a highly abused term. Both "open source" and "free software"
are based on basic principles (the same, actually, just worded
differently and with different ethical/moral attachments) but at the end
they "restrict" somebody to "free" somebody else. So, it's not true that
BSD is really free and GPL is not because forces code reciprocity: it
just depends on what you value most and who you want to protect/empower,
the user or the developer.
I like to categorize licenses by their restrictions rather than their
freedoms, since this has much simpler moral complexities to deal with.
> 2) MySQL - No comment, other than I'd not be too keen in participating
> in a MySQL-like ecosystem around a Java implementation.
Agreed.
>> 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.
>
> I don't see that. There's no burden to not contributing patent licenses
> to a codebase, compared to maintaining an "internal fork" if you choose
> not to give modifications back to the community.
That is a good point, but misses mine.
Let me rephrase: the starting point is that all existing IP that covers
the RI is owned or licensed by Sun. The current state of affairs is that
you get a license for that IP once you pass the certification tests and
either, you pay or you are a non-profit.
If it is not true that Sun doesn't own all the IP on the RI and there is
somebody else sitting out there with a submerged patent on it, the Java
ecosystem has much bigger issues than what license to use for the RI
codebase, so let's use that as a working starting point.
So, this means there is nobody out there sitting on the existing
codebase with a patent that the user community cannot get a license to
(if their code passes certification).
Now, there are three cases:
1) BigCoWithPatent forks the RI, adds some code that implements one of
their patents.
2) BigCoWithPatent donates some code to the RI that is covered by a
patent they own but they don't say so.
3) Joe Committer donates some code to the RI that is covered by a
patent that BigCoWithPatent owns and nobody (yet) knows.
For #1, my claim is that if they have a patent and it's not already
covering RI code, there will have to be some other code to implement
such patent. Since such patent would not be trivial matter (or at least
one would hope) and it is not already covered by the RI (or it would be
easy to fight it as prior art), therefore it's implemented by a code fork.
the ASF has experienced "private branches" but no fork in the
Emacs/XEmacs or Free/Open/NetBSD sense where the codebases diverge in
both community and functionality. BigCoWithPatent might decide that it's
economically feasible for them to keep investing on a private branch,
just like say IBM does with WebSphere for HTTPD. For HTTPD, that is a
small price to pay for "owning" the HTTP serving market. As much as we
consider non-reciprocity of code a small price to pay for the social
comfort it generates, I don't understand why you feel that patents are
different.
I understand you are concerned about the SCO-like patent attacks of
somebody coming in and telling you that you can't run your own code
because they own the rights to the concept... but if that is the case
against the RI, we have a way bigger problem and that's nothing a
license can fix.
So you are complicating the protections for no rational reason.
For #2, a CLA (contribution licensing agreement) protects you.
For #3, it's pain but it's pain no matter what license you choose since
the guy donating the code doesn't own the rights anyway, so reciprocity
doesn't work anyway.
>> 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).
>
> I'm still not seeing it if my assumption about you meaning "patent" when
> you say "IP" is valid - what it could do is create a situation where no
> one would want to do anything out of fear of patent action. Modern OSS
> licenses solve this partway by having contributors explicitly license
> patents they own that are covered by their contributions.
I have explicitly mentions that there is no need for a CLA (the "input"
license) to be embedded in the "output" one. It is a decision that the
ASF made but, if you ask me, it didn't really help us since, just to
sure, we get CLAs for committers anyway.
It helps on those little patches that people don't sign a CLA for, but I
strongly doubt that Sun would allow even a single line of code to enter
the code repository without some sort of licensing agreement between the
parties involved, including individuals.
So, here's my detailed proposal:
- MIT/X on the way out
- ASF-like CLA on the way in for *any* contribution (you can make that
click-thru when you apply a patch on jira)
- trademark and patent licenses separate, free for non-profits that
pass the TCK.
- The TCK freely available to download and run with no NDA or
restriction on result publication on your own certification status. The
"open source" status of the TCK is non really that important.
>> 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.
>
> I don't understand that sentence.
Case #3 above.
>> 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.
>
> I think that there actually is a problem because of the asymmetry in the
> ecosystem.
>
> Big Co and Bigger Co have loads of patents on this technology, I
> assume. Stefano Co. has zero.
Correct, and this is true for every MIT/BSD/GPL/LGPL project out there
but it has not stopped FOSS to exist or even stride, hasn't it?
> Big Co and Bigger Co can cross license
> to keep the peace between them. Stefano Co can't. Stefano Co is
> subject to whatever whims Big Co and Bigger Co have unless mechanisms
> like the patent languages in modern licenses are in force. True, by not
> contributing, they stay clear of the patent license obligation, but a
> counterstrategy to that is to try and form as big a 'commons' as
> possible, leaving non-participants as outliers. IOW, create a community
> of "patent peace", be it via a common codebase that all have contributed
> to, or something more explicit - a patent pool or such.
*yes* but this is performed by an *input* license (a patent-strong CLA)
which does *NOT* need to be part of the *output* license.
This is *my entire* point.
>> 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.
>
> I guess I didn't understand the analysis, as I see that significant
> threats remain within the resulting ecosystem, threats that if we don't
> already know how to deal with, we're working hard on finding solutions.
I'm sorry, but this is FUD.
I've outlined all the possible scenarios and I've shown that the
licensing strategy that I proposed achieves the same protection level
and increased compatibility *now*.
If you disagree, please outline scenarios where my strategy fails and
the reasons why.
"I see significant threads within the resulting ecosystem" without
detailed explanation and rationalization sound way too George W. for my
taste.
>> CDDL will lower the perceived fear of "free riding" using IP protection
>> strategies in Sun executives, but at the price of alienating a huge part
>> of the java FOSS ecosystem.
>
> I dunno. Assume you have the GPLv3 now. Isn't that statement
> non-operational?
We *DO NOT* have GPLv3 now. My strategy is based on that.
If we had GPLv3 now, and Apache License compatibility written all over
it, the choice of the Apache License would be a no brainer.
> And since that's just a matter of months, isn't this really about having
> a "brand approved" license that successfully interoperates, rather than
> any real philosophical incompatibility?
"matter of months"? please, don't insult our intelligence.
But besides, license compatibility is a much less beneficial goal than
social cooperation... and philosophical neutrality is a necessary
precondition for any social cooperation.
Sun could use the Apache License and bet on the GPLv3 social
harmonization process to succeed, could choose CDDL and then dissipate a
great deal of social friction or use the strategy I outlined and achieve
the same results now, without bets, without delays and without social
friction and without increasing risks.
>> Just like I'm sure Sun is willing to think about lack of reciprocity for
>> code donations, I'm suggesting that they evaluate the same exact
>> strategy for IP, trusting that the socio-economical dynamics that this
>> will create will be a much more effective as a protection mechanism
>> *and* will provide them with a solution that will win for them and will
>> win for all the FOSS communities involved, no matter what current or
>> past licensing beliefs.
>
> I think you have to be really careful about how you think about that
> "lack of reciprocity", because comparing it to how patents are treated
> is very different. The "lack of reciprocity" in Sun's projects to date
> is a copyright grant of joint ownership, not a license to use under terms.
>
> By asking for joint copyright, Sun is getting free and unfettered
> licensing rights to do whatever they want with the code. A CDDL-style
> or Apache License-style patent structure isn't the same thing.
>
> Very simply speaking, the Apache patent license boils down to this :
>
> "Each Contributor hereby grants to You a patent license to use (et al)
> the Work"
>
> That doesn't mean "You" can do anything you want with that patent
> license, which is what Sun is able to do with the joint copyright
> assignment.
>
> Of course, Sun is free to continue with that if they choose. I just
> hope that what they create is a level playing field, so there are no
> needless barriers to participation.
I've outlined both the "inbound" licensing strategy and the "outbound"
one. Clearly, a good "inbound" one and a bad "outbound" one would ruin
the dynamics just as bad.
so, yes, I know very well that both needs to be defined and I understand
why you like a license that defines both (so that you don't have to hope
for the other one to be done right).
>> I perfectly realize that I'm suggesting a bold move that might feel too
>> risky, especially for somebody that has not experienced as much as we
>> did in the ASF the power of social dynamics in respect to protection and
>> stability.
>>
>> That said, it's hard to deny that the ASF has never experienced, in 10
>> years of operation, a single fork, despite the complete lack of
>> reciprocity provisions in its licensing strategy, showing that, although
>> counterintuitive, healthy communities are even more effective than
>> licensing restrictions in protecting the evolution of a codebase.
>
> I agree with you, but there have been several forks over the years. IBM
> forked httpd, IBM, JBoss, ObjectWeb others forked WS... I'd even argue
> that Sun is technically forking Derby in their "JavaDB" product, and IBM
> "pre-forked" Derby with the Cloudscape product that was the source of
> Derby ... :)
Those are 'vendor branches', they forked the code but the community is
one. The ASF has never experienced a forked community, this is what I meant.
--
Stefano.
---------------------------------------------------------------------
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
Re: [legal] Re: Bringing License arguments to Sun
Posted by Dalibor Topic <ro...@kaffe.org>.
On Mon, Aug 21, 2006 at 10:12:30AM -0400, Geir Magnusson Jr wrote:
>
>
> Stefano Mazzocchi wrote:
> > That said, it's hard to deny that the ASF has never experienced, in 10
> > years of operation, a single fork, despite the complete lack of
> > reciprocity provisions in its licensing strategy, showing that, although
> > counterintuitive, healthy communities are even more effective than
> > licensing restrictions in protecting the evolution of a codebase.
>
> I agree with you, but there have been several forks over the years. IBM
> forked httpd, IBM, JBoss, ObjectWeb others forked WS... I'd even argue
> that Sun is technically forking Derby in their "JavaDB" product, and IBM
> "pre-forked" Derby with the Cloudscape product that was the source of
> Derby ... :)
I'd add OpenBSD's fork of httpd to that pile. It was created since
Apache License 2.0 was unacceptable for a core component of the OpenBSD
distribution, and accordingly, the last acceptable version of httpd was
forked, cleaned up from no longer necessary code, and is being
maintained by OpenBSD developers separately.
I also recall ASF's Director Roy Fielding posting on the debian-legal
mailing list on November 14th, 2003, accusing Debian of maliciously
forking httpd ... I assume he was whistled back by whoever holds the
reigns on that project, as Apache didn't take legal action for all
those alleged license violations, afaik, and Debian continues to
distribute patched httpd packages, of course.
cheers,
dalibor topic
>
> There's nothing wrong with that, and it really never hurt our
> communities (as evidenced by the strength of httpd and WS as
> examples...), and in some cases, they came back or gave back. We have
> no problems with people forking if they choose, as they tend to come
> back anyway.
>
> And I'm expecting that people will fork Harmony code, and I don't think
> that's bad.
>
> But that's orthogonal to the notion of patent freedom - I want to make
> sure we don't wind up in a situation where no one wants to do anything
> because of patent fears.
>
> Maybe the thing to do of patent-silent license is necessary is for Sun
> to work with the rest of the industry (IBM, BEA, Apple, MSFT, Intel etc)
> and create a "patent commons" of all patents each company owns related
> to Java, managed runtimes, etc, with a clear covenant not to sue...
>
> geir
>
> (Given that I mentioned my employer, Intel, I want to make it clear
> that this is my personal opinion and should not be taken to represent
> the position of Intel Corporation....)
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
[legal] Re: Bringing License arguments to Sun
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> 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'm going to assume that from here forward, when you say "IP" you mean
'patent'?
>
> 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).
But our license is very explicit about patents as well.
>
> 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).
Yes....
>
> 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.
Yes - I'm all for that. And you can achieve that w/ CDDL also. (I'm
not pushing CDDL here - my choice would be Apache License knowing that
all will be well w/ GPLv3, which I thought was scheduled to arrive at
about the same time as the code from Sun anyway...
>
> 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).
But GPLv3 is coming.
>
> 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 [legal]story).
Few things in this paragraph :
1) I prefer to think of BSD as not restricting your freedom, rather than
allowing you to something, but as it is a license, it is in a sense
allowing the freedom.
2) MySQL - No comment, other than I'd not be too keen in participating
in a MySQL-like ecosystem around a Java implementation.
>
> 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.
I don't see that. There's no burden to not contributing patent licenses
to a codebase, compared to maintaining an "internal fork" if you choose
not to give modifications back to the community.
>
> 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).
I'm still not seeing it if my assumption about you meaning "patent" when
you say "IP" is valid - what it could do is create a situation where no
one would want to do anything out of fear of patent action. Modern OSS
licenses solve this partway by having contributors explicitly license
patents they own that are covered by their contributions.
>
> 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.
I don't understand that sentence.
>
> 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.
I think that there actually is a problem because of the asymmetry in the
ecosystem.
Big Co and Bigger Co have loads of patents on this technology, I
assume. Stefano Co. has zero. Big Co and Bigger Co can cross license
to keep the peace between them. Stefano Co can't. Stefano Co is
subject to whatever whims Big Co and Bigger Co have unless mechanisms
like the patent languages in modern licenses are in force. True, by not
contributing, they stay clear of the patent license obligation, but a
counterstrategy to that is to try and form as big a 'commons' as
possible, leaving non-participants as outliers. IOW, create a community
of "patent peace", be it via a common codebase that all have contributed
to, or something more explicit - a patent pool or such.
>
> 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.
I guess I didn't understand the analysis, as I see that significant
threats remain within the resulting ecosystem, threats that if we don't
already know how to deal with, we're working hard on finding solutions.
>
> CDDL will lower the perceived fear of "free riding" using IP protection
> strategies in Sun executives, but at the price of alienating a huge part
> of the java FOSS ecosystem.
I dunno. Assume you have the GPLv3 now. Isn't that statement
non-operational?
And since that's just a matter of months, isn't this really about having
a "brand approved" license that successfully interoperates, rather than
any real philosophical incompatibility?
>
> Just like I'm sure Sun is willing to think about lack of reciprocity for
> code donations, I'm suggesting that they evaluate the same exact
> strategy for IP, trusting that the socio-economical dynamics that this
> will create will be a much more effective as a protection mechanism
> *and* will provide them with a solution that will win for them and will
> win for all the FOSS communities involved, no matter what current or
> past licensing beliefs.
I think you have to be really careful about how you think about that
"lack of reciprocity", because comparing it to how patents are treated
is very different. The "lack of reciprocity" in Sun's projects to date
is a copyright grant of joint ownership, not a license to use under terms.
By asking for joint copyright, Sun is getting free and unfettered
licensing rights to do whatever they want with the code. A CDDL-style
or Apache License-style patent structure isn't the same thing.
Very simply speaking, the Apache patent license boils down to this :
"Each Contributor hereby grants to You a patent license to use (et al)
the Work"
That doesn't mean "You" can do anything you want with that patent
license, which is what Sun is able to do with the joint copyright
assignment.
Of course, Sun is free to continue with that if they choose. I just
hope that what they create is a level playing field, so there are no
needless barriers to participation.
>
> I perfectly realize that I'm suggesting a bold move that might feel too
> risky, especially for somebody that has not experienced as much as we
> did in the ASF the power of social dynamics in respect to protection and
> stability.
>
> That said, it's hard to deny that the ASF has never experienced, in 10
> years of operation, a single fork, despite the complete lack of
> reciprocity provisions in its licensing strategy, showing that, although
> counterintuitive, healthy communities are even more effective than
> licensing restrictions in protecting the evolution of a codebase.
I agree with you, but there have been several forks over the years. IBM
forked httpd, IBM, JBoss, ObjectWeb others forked WS... I'd even argue
that Sun is technically forking Derby in their "JavaDB" product, and IBM
"pre-forked" Derby with the Cloudscape product that was the source of
Derby ... :)
There's nothing wrong with that, and it really never hurt our
communities (as evidenced by the strength of httpd and WS as
examples...), and in some cases, they came back or gave back. We have
no problems with people forking if they choose, as they tend to come
back anyway.
And I'm expecting that people will fork Harmony code, and I don't think
that's bad.
But that's orthogonal to the notion of patent freedom - I want to make
sure we don't wind up in a situation where no one wants to do anything
because of patent fears.
Maybe the thing to do of patent-silent license is necessary is for Sun
to work with the rest of the industry (IBM, BEA, Apple, MSFT, Intel etc)
and create a "patent commons" of all patents each company owns related
to Java, managed runtimes, etc, with a clear covenant not to sue...
geir
(Given that I mentioned my employer, Intel, I want to make it clear
that this is my personal opinion and should not be taken to represent
the position of Intel Corporation....)
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Stefano Mazzocchi <st...@apache.org>.
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 huge part
of the java FOSS ecosystem.
Just like I'm sure Sun is willing to think about lack of reciprocity for
code donations, I'm suggesting that they evaluate the same exact
strategy for IP, trusting that the socio-economical dynamics that this
will create will be a much more effective as a protection mechanism
*and* will provide them with a solution that will win for them and will
win for all the FOSS communities involved, no matter what current or
past licensing beliefs.
I perfectly realize that I'm suggesting a bold move that might feel too
risky, especially for somebody that has not experienced as much as we
did in the ASF the power of social dynamics in respect to protection and
stability.
That said, it's hard to deny that the ASF has never experienced, in 10
years of operation, a single fork, despite the complete lack of
reciprocity provisions in its licensing strategy, showing that, although
counterintuitive, healthy communities are even more effective than
licensing restrictions in protecting the evolution of a codebase.
--
Stefano.
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
>
> 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.
That's the important thing to get across to Sun - that there are other
things that will ensure compatibility like 'the market' (no one wants a
broken java... people have too much invested in their Java deployments),
the power of the Java brand (you can't call your software 'Java' unless
you pass the TCK), etc.
[snip]
> 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? 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...
geir
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Simons wrote:
> The network is the computer, and the community is the real network.
I want a t-shirt with that on! :-)
--
Stefano.
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Leo Simons <ma...@leosimons.com>.
(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
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Geir Magnusson Jr <ge...@pobox.com>.
robert burrell donkin wrote:
> On 8/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>> 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.
>
> there is no reason why patent and copyrights need to be covered
> together by a single license. the MIT license could be used for the
> copyright with a separate license to cover the patents.
>
How much would you pay for that license? ;)
geir
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by robert burrell donkin <ro...@gmail.com>.
On 8/20/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> 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.
there is no reason why patent and copyrights need to be covered
together by a single license. the MIT license could be used for the
copyright with a separate license to cover the patents.
- robert
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 :)
geir
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
Re: Bringing License arguments to Sun
Posted by Chris Gray <ch...@kiffer.be>.
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] <http://jcp.org/en/jsr/results?id=1991>.
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Wes Felter wrote:
> 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.
No one needs to redistribute the TCK, but I can't see any problem in it
happening. Any derivative work isn't the TCK anyway, so there's no risk
to the ecosystem there.
But having it in open source is a good thing - it means that more people
can have access to it. I can see no reason to keep it closed.
geir
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Wes Felter <we...@felter.org>.
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 - wesley@felter.org
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Simon Phipps <we...@sun.com>.
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.
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Chris Gray <ch...@kiffer.be>.
+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, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
---------------------------------------------------------------------
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
Re: Bringing License arguments to Sun
Posted by Simon Phipps <we...@sun.com>.
On Aug 19, 2006, at 19:57, theUser BL wrote:
> At
> http://forums.java.net/jive/thread.jspa?threadID=17634&tstart=0
> Sun's Chief Open Source Officer Simon Phipps alias webmink
> http://forums.java.net/jive/profile.jspa?userID=70
> wrotes, that he have still not decided, which OpenSource license
> will be used for Suns Java.
>
> He wrote:
>
> " To be clear, I've not expressed a preference for any particular
> license yet. In fact, I think it's still unclear which of my
> license categories most applies to the Java platform. I'm reading
> everything that's being written by commentators from the various
> Java communities, however, and I'm keen for Sun to make license
> choices that create the best future for us all. I've discussed this
> further in my blog at http://blogs.sun.com/roller/page/webmink?
> entry=why_bother_open_sourcing_java "
>
>
> So to all of the OpenSource-Java folks:
> If you prefer a special license or a special license form and you
> have reasons, why you think, that your prefered license would be
> the best for Java, then write it at Suns OpenSource JDK forum at
> http://forums.java.net/jive/forum.jspa?forumID=97
>
> Actually is still the time, where you can influence, which license
> Suns Java will have.
Yes indeed. I am all ears.
S.
---------------------------------------------------------------------
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