You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by Ralph Goers <Ra...@dslextreme.com> on 2007/07/04 18:45:05 UTC
Re: jcp-open Digest of: get.703_703
>
> ------------------------------------------------------------------------
> Subject:
> Inaction on Java SE JSR? (was: [Draft] New ASF/JCP Policies)
> From:
> "William A. Rowe, Jr." <wr...@apache.org>
> Date:
> Fri, 29 Jun 2007 15:24:54 -0500
> To:
> jcp-open@apache.org
>
> To:
> jcp-open@apache.org
>
>
> Isn't it time to formally withdraw from that JSR, if we still sit on it?
> Initially the contested Java SE JSR, and later any related/later JSR's of
> the same technology by the same spec lead, and finally - every JSR who's
> spec lead is in persistent violation of the mutually agreed-upon terms
> of the JSPA. This seems only rational, no?
>
>
I think I might take a different approach to this problem. I would
suggest that the only way to really solve this is to modify the Apache
license in a manner similar to the GPL. I would do something like add a
new termination section such as below. This license would terminate
Sun's right to use any Apache software.
10. Termination - Your rights under this license will automatically
terminate should you own or control any specification, process or other
kind of work which is made publicly available under any public license,
but which the Apache Software Foundation is prohibited from implementing
due to license, patent, or other restrictions that are incompatible with
this license and are directly under your control.
Ralph
Re: jcp-open Digest of: get.703_703
Posted by robert burrell donkin <ro...@gmail.com>.
On 7/4/07, Rory Winston <rw...@eircom.net> wrote:
> William
>
> Thanks for the clarification. It does seem like a pretty restrictive
> covenant.
<snip>
> > So, the Apache name is right up there on JSR 176 as a supporter. Why?
> > We appear to endorse Sun's choice of licensing by association.
this gives the appearance that apache has conspired with sun to act
against it's charter (apache is dedicated to open source for the
public good). apache and it's membership risk litigation. NDAs make
matters difficult for non-profits by forcing information that needs to
be a matter of public record to be remain private.
- robert
Re: jcp-open Digest of: get.703_703
Posted by Rory Winston <rw...@eircom.net>.
William
Thanks for the clarification. It does seem like a pretty restrictive
covenant.
Thanks
Rory
William A. Rowe, Jr. wrote:
> Rory Winston wrote:
>
>> "Staying in the wrong sandbox leaves us open to 'guilt
>> by association' when specific JSR's use our good name to undermine open
>> source implementations of that standard." - William
>>
>> Just curious - how would this ever happen? What would be a reasonably
>> plausible scenario here?
>>
>
> The Field of Use restrictions limiting J2SE 5 implementations to "General
> Purpose Computing Devices" and excluding special-case appliances, kiosks,
> mobile computing devices and other interesting applications constitutes
> an "additional restriction" that would be unacceptable to us (the ASF),
> and equally to the FSF (by the GPL's no-additional-restrictions policy).
>
> The offer of a TCK under these additional restrictions is the entire cause
> for the Open Letter to Sun, and pretty much the fuel behind this entire
> dialog. The wording appears to put the onus on us (the ASF) to enforce
> this FOU (not the user) and restrict the use of the source code.
>
> So, the Apache name is right up there on JSR 176 as a supporter. Why?
> We appear to endorse Sun's choice of licensing by association.
>
> Bill
>
>
>
>
Re: jcp-open Digest of: get.703_703
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 4, 2007, at 6:03 PM, William A. Rowe, Jr. wrote:
> Rory Winston wrote:
>> "Staying in the wrong sandbox leaves us open to 'guilt
>> by association' when specific JSR's use our good name to undermine
>> open
>> source implementations of that standard." - William
>>
>> Just curious - how would this ever happen? What would be a reasonably
>> plausible scenario here?
>
> The Field of Use restrictions limiting J2SE 5 implementations to
> "General
> Purpose Computing Devices" and excluding special-case appliances,
> kiosks,
> mobile computing devices and other interesting applications
> constitutes
> an "additional restriction" that would be unacceptable to us (the
> ASF),
> and equally to the FSF (by the GPL's no-additional-restrictions
> policy).
>
> The offer of a TCK under these additional restrictions is the
> entire cause
> for the Open Letter to Sun, and pretty much the fuel behind this
> entire
> dialog.
Misplaced, IMO.
> The wording appears to put the onus on us (the ASF) to enforce
> this FOU (not the user) and restrict the use of the source code.
No. The wording simply puts a user in theoretical jeopardy if they
use the software in certain legitimate ways. That's what we have the
problem with.
>
> So, the Apache name is right up there on JSR 176 as a supporter. Why?
> We appear to endorse Sun's choice of licensing by association.
I think this is an extreme position. That's like saying IBM is also
endorsing Sun's move. Sam, quit your job!
Seriously, you can probably guess that IBM isn't a supporter. People
will probably deduce that we aren't a supporter of something we're
openly feuding with Sun about...
geir
Re: jcp-open Digest of: get.703_703
Posted by Martin van den Bemt <ml...@mvdb.net>.
William A. Rowe, Jr. wrote:
> Rory Winston wrote:
>> "Staying in the wrong sandbox leaves us open to 'guilt
>> by association' when specific JSR's use our good name to undermine open
>> source implementations of that standard." - William
>>
>> Just curious - how would this ever happen? What would be a reasonably
>> plausible scenario here?
>
> The Field of Use restrictions limiting J2SE 5 implementations to "General
> Purpose Computing Devices" and excluding special-case appliances, kiosks,
> mobile computing devices and other interesting applications constitutes
> an "additional restriction" that would be unacceptable to us (the ASF),
> and equally to the FSF (by the GPL's no-additional-restrictions policy).
>
Even worse : The field of use restriction means automatically that it cannot be open source at all
according to the Open Source Definition.
(specifically point 6 : No Discrimination Against Fields of Endeavor.
Mvgr,
Martin
Re: jcp-open Digest of: get.703_703
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Rory Winston wrote:
> "Staying in the wrong sandbox leaves us open to 'guilt
> by association' when specific JSR's use our good name to undermine open
> source implementations of that standard." - William
>
> Just curious - how would this ever happen? What would be a reasonably
> plausible scenario here?
The Field of Use restrictions limiting J2SE 5 implementations to "General
Purpose Computing Devices" and excluding special-case appliances, kiosks,
mobile computing devices and other interesting applications constitutes
an "additional restriction" that would be unacceptable to us (the ASF),
and equally to the FSF (by the GPL's no-additional-restrictions policy).
The offer of a TCK under these additional restrictions is the entire cause
for the Open Letter to Sun, and pretty much the fuel behind this entire
dialog. The wording appears to put the onus on us (the ASF) to enforce
this FOU (not the user) and restrict the use of the source code.
So, the Apache name is right up there on JSR 176 as a supporter. Why?
We appear to endorse Sun's choice of licensing by association.
Bill
Re: jcp-open Digest of: get.703_703
Posted by Rory Winston <rw...@eircom.net>.
"Staying in the wrong sandbox leaves us open to 'guilt
by association' when specific JSR's use our good name to undermine open
source implementations of that standard."
William
Just curious - how would this ever happen? What would be a reasonably plausible scenario here?
Re: jcp-open Digest of: get.703_703
Posted by Ralph Goers <Ra...@dslextreme.com>.
William A. Rowe, Jr. wrote:
>
> How does that help the developer who happens to be one of 10k employees
> of Microsoft Corp, who happens to want to contribute to an ASF project?
>
> This is the definition of cutting off our nose to spite our face.
>
Maybe I'm naive, but I thought committers at ASF do so on their own. The
CLA I signed was on my own behalf, not my employers. Whether I am
allowed to contribute on my employer's time is up to them. However, I am
always free to do so on my own time. If my employer asks me to make
specific contributions to the Apache projects where I have that right
(and they have in the past), then I would expect them to fulfill any
obligations necessary for me to do so.
Out of curiosity, do you know of any Apache committers who Microsoft
employees and are able to author and contribute code on Microsoft's dime?
>
> Ok, so only companies who make an attempt to offer open standards will be
> screwed? The employees of companies who offer only closed standards are
> unaffected? This is good how, exactly?
>
No, only companies that attempt to be perceived as supporting or
providing open standards but don't really do so would be impacted.
>
>> What do you think Sun's response to such a clause would be. They only
>> have 2 choices a) stop the nonsense with the NDAs and TCKs, or b) stop
>> using Apache software. Frankly, because of your previous argument -
>> regarding the leverage of the Apache code base, I can't imagine that Sun
>> would find it more profitable to find alternatives to Xerces and Xalan,
>> etc.
>>
>
> Or neither. They have a useful license to our code already (even if they
> forked from today forward) and could continue the nonsense, while those
> who particpate from dozens of academic institutions are concerned if their
> colleges at the college have semi-open standards that interfere with their
> developing ASF software. Who wins?
>
>
Good question. How long did Microsoft's Java on Windows last under
similar circumstances. Software decays over time. It would become more
and more costly for Sun to try to keep up. Of course, Sun helped that
along by suing Microsoft.
Remember, this is all about a more forceful and tangible approach to
deal with the problem. If it is actually necessary to do I'm sure there
would be quite a bit of debate over wording, such as excluding academic
institutions or whatever. The real point is, that when it comes to
"real" leverage the ASF has is the support it has with some very large
corporations and their willingness to provide their clout, and the
Apache license itself.
>> Actually, I don't agree with any of these. I would stay in all the JCRs
>> and simply vote No on every ballot for a JSR that doesn't explicitly
>> meet Apache standards.
>>
>
> Well, that happens to be the FIRST option, stay put and try to effect change
> from within. How do you figure your position is different?
>
To use a very crude analogy I view the first option as diplomacy. It is
always the preferable solution. However, if it doesn't work then you
need something with clout behind it. I guess I see this as "Speak softly
and carry a big stick". I equate speaking softly to carrying on,
voicing our concerns and voting down JSRs (or any other specification we
can) with inappropriate licensing terms. The big stick is how Apache
code is licensed for use. Shoot, if we wanted to we could just add
"This license applies to everyone but Sun". That wouldn't have any of
the language problems you have brought up ;-) Of course, I think that
would be a horrible way to solve this.
Again, my point here is not any specific language change, but the
realization that we should not be afraid of modifying the license if
doing so will achieve the desired purpose. At the same time I recognize
that this would have to be done very carefully to avoid unintended
consequences.
Ralph
Re: jcp-open Digest of: get.703_703
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
> Actually, what I am suggesting is to try to put even more power in the
> developer's hands by making sure that standards that are "open" can
> actually be implemented and distributed. Yes, developers who
> participate in a "standard" should understand whether it will be a truly
> open standard or proprietary. For example, no one really expects that
> anyone other than Microsoft will ever be able to implement an
> application that is compliant with Open XML. Yet it is being "sold" as
> an open standard that allows for application interoperability. If it is
> truly open then Microsoft should have no problem with a clause such as
> what I am proposing. If it isn't, and Apache can't implement it, then
> why should Microsoft be able to benefit from Apache developed software?
How does that help the developer who happens to be one of 10k employees
of Microsoft Corp, who happens to want to contribute to an ASF project?
This is the definition of cutting off our nose to spite our face.
> The clause can only be applied to any code that is licensed under the AL
> that is used by a company. The license would not be viral in that sense
> (like it is asserted that GPL2 is). But yes, it could touch everything a
> company does, if that company chooses to use Apache licensed software.
> However, it should be possible to write this clause in such a way that
> it has no affect on most companies (as they don't sponsor or own "open"
> specifications) and has the desired effect on those that are impacted by
> it.
Ok, so only companies who make an attempt to offer open standards will be
screwed? The employees of companies who offer only closed standards are
unaffected? This is good how, exactly?
> What do you think Sun's response to such a clause would be. They only
> have 2 choices a) stop the nonsense with the NDAs and TCKs, or b) stop
> using Apache software. Frankly, because of your previous argument -
> regarding the leverage of the Apache code base, I can't imagine that Sun
> would find it more profitable to find alternatives to Xerces and Xalan,
> etc.
Or neither. They have a useful license to our code already (even if they
forked from today forward) and could continue the nonsense, while those
who particpate from dozens of academic institutions are concerned if their
colleges at the college have semi-open standards that interfere with their
developing ASF software. Who wins?
> Actually, I don't agree with any of these. I would stay in all the JCRs
> and simply vote No on every ballot for a JSR that doesn't explicitly
> meet Apache standards.
Well, that happens to be the FIRST option, stay put and try to effect change
from within. How do you figure your position is different?
Bill
Re: jcp-open Digest of: get.703_703
Posted by Ralph Goers <Ra...@dslextreme.com>.
William A. Rowe, Jr. wrote:
> I think you entirely missed my points. First...
>
> I was referring to the many changes in GPLv3 that meet with resistance for
> the users of GPLv2. We already watch many discussions of why some widely
> distributed projects have no plans to move from GPLv2 to GPLv3. That was
> the allegory of adding more terms and conditions to the AL.
>
> Secondly, we've seen many 'non-ASF' projects pick up the AL 2.0 because
> it does exactly what it was ment to do :) It is ment to put the 'power',
> so to speak, in developer's hands. The idea you expressed would add
> restrictions to the developer who personally participates in standards
> activities, or worse - whose employer or coworkers do. This isn't even
> to mention the 'end user'. (This is in contract to the GPL, which
> actually focuses the power in the user's hands).
>
Actually, what I am suggesting is to try to put even more power in the
developer's hands by making sure that standards that are "open" can
actually be implemented and distributed. Yes, developers who
participate in a "standard" should understand whether it will be a truly
open standard or proprietary. For example, no one really expects that
anyone other than Microsoft will ever be able to implement an
application that is compliant with Open XML. Yet it is being "sold" as
an open standard that allows for application interoperability. If it is
truly open then Microsoft should have no problem with a clause such as
what I am proposing. If it isn't, and Apache can't implement it, then
why should Microsoft be able to benefit from Apache developed software?
>
>> My feeling is that if the ASF wants to have any leverage than the only
>> effective way it can do that is through the license. I am not saying it
>> needs to be as "heavy" as the GPL, but just something that keeps people
>> honest. Something that says if you are going to call it open than it has
>> to be open enough that the ASF can implement it. If you don't want to do
>> that then don't make the spec public and don't call it open, and then
>> you won't be violating our license.
>>
>
> But your clause doesn't apply to the licensed code. It touches everything
> the individual/company does, which makes it unjustifiably viral.
>
The clause can only be applied to any code that is licensed under the AL
that is used by a company. The license would not be viral in that sense
(like it is asserted that GPL2 is). But yes, it could touch everything a
company does, if that company chooses to use Apache licensed software.
However, it should be possible to write this clause in such a way that
it has no affect on most companies (as they don't sponsor or own "open"
specifications) and has the desired effect on those that are impacted by it.
What do you think Sun's response to such a clause would be. They only
have 2 choices a) stop the nonsense with the NDAs and TCKs, or b) stop
using Apache software. Frankly, because of your previous argument -
regarding the leverage of the Apache code base, I can't imagine that Sun
would find it more profitable to find alternatives to Xerces and Xalan, etc.
>
>> The idea of abandoning the JCP seems a lot like saying "we are taking
>> our toys and going home". If that means the other kids won't have toys
>> to play with it might mean something, but if they already have a pretty
>> full toy box and some other friends to play with they aren't going to
>> care much.
>>
>
> Well, there are three schools of thought right now. Stay in each JSR and
> attempt to effect change-from-within (which has worked to some degree for
> the past several years.) Withdraw support and EG participation from JSR's
> which present unacceptable restrictions or opaque standards development
> processes. Or withdraw from the JCP entirely.
>
> Until Sun unjustifiably wields its Veto pen, I don't believe leaving the
> JCP altogether does either organization any good. Leaving specific,
> closed/restricted JSR's says "the ASF can't participate on this specific
> proposal in good conscious", and leaves us free to develop competing and
> open standards. Staying in the wrong sandbox leaves us open to 'guilt
> by association' when specific JSR's use our good name to undermine open
> source implementations of that standard.
>
Actually, I don't agree with any of these. I would stay in all the JCRs
and simply vote No on every ballot for a JSR that doesn't explicitly
meet Apache standards. It will never be mistaken what Apache's stance is
as the ballot is there for all the world to see, so I don't believe
"guilt by association" will be a problem. Furthermore, the negative
comments are often mentioned in news articles. Finally, I think the ASF
is far more likely to get RedHat, IBM, etc to force the issue if we are
still participating.
Ralph
Re: jcp-open Digest of: get.703_703
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
>
> Hey, it is just wording that lawyer's can fix. It was meant to spawn
Understood.
> Actually, I disagree with your observations about the GPL. I think many
> folks are comfortable using it in many situations, and many GPL projects
> are doing quite well. Secondly, while I agree with your observations
> that the amount of code available at Apache, and its quality, I don't
> agree that the current license makes it "powerful", although it is what
> makes it popular and highly used. In fact, by design the current
> license effectively gives away any power the licensor may have.
I think you entirely missed my points. First...
I was referring to the many changes in GPLv3 that meet with resistance for
the users of GPLv2. We already watch many discussions of why some widely
distributed projects have no plans to move from GPLv2 to GPLv3. That was
the allegory of adding more terms and conditions to the AL.
Secondly, we've seen many 'non-ASF' projects pick up the AL 2.0 because
it does exactly what it was ment to do :) It is ment to put the 'power',
so to speak, in developer's hands. The idea you expressed would add
restrictions to the developer who personally participates in standards
activities, or worse - whose employer or coworkers do. This isn't even
to mention the 'end user'. (This is in contract to the GPL, which
actually focuses the power in the user's hands).
> My feeling is that if the ASF wants to have any leverage than the only
> effective way it can do that is through the license. I am not saying it
> needs to be as "heavy" as the GPL, but just something that keeps people
> honest. Something that says if you are going to call it open than it has
> to be open enough that the ASF can implement it. If you don't want to do
> that then don't make the spec public and don't call it open, and then
> you won't be violating our license.
But your clause doesn't apply to the licensed code. It touches everything
the individual/company does, which makes it unjustifiably viral.
> The idea of abandoning the JCP seems a lot like saying "we are taking
> our toys and going home". If that means the other kids won't have toys
> to play with it might mean something, but if they already have a pretty
> full toy box and some other friends to play with they aren't going to
> care much.
Well, there are three schools of thought right now. Stay in each JSR and
attempt to effect change-from-within (which has worked to some degree for
the past several years.) Withdraw support and EG participation from JSR's
which present unacceptable restrictions or opaque standards development
processes. Or withdraw from the JCP entirely.
Until Sun unjustifiably wields its Veto pen, I don't believe leaving the
JCP altogether does either organization any good. Leaving specific,
closed/restricted JSR's says "the ASF can't participate on this specific
proposal in good conscious", and leaves us free to develop competing and
open standards. Staying in the wrong sandbox leaves us open to 'guilt
by association' when specific JSR's use our good name to undermine open
source implementations of that standard.
Re: jcp-open Digest of: get.703_703
Posted by Henning Schmiedehausen <he...@apache.org>.
Ralph Goers schrieb:
>
>
> William A. Rowe, Jr. wrote:
[...]
>> The AL is powerful because of 1. the amount of code available for people
>> (especially developers) to use, and 2. minimal restrictions necessary to
>> protect the developers of that code. If it's watered down with
>> additional
>> cruft, it loses it's validity. This is one of the major obstacles for
>> the
>> GPLv3 itself, to overcome the simplicity of the GPLv2 in the minds of
>> users of the GPL.
>>
> Actually, I disagree with your observations about the GPL. I think many
> folks are comfortable using it in many situations, and many GPL projects
> are doing quite well. Secondly, while I agree with your observations
Until proven otherwise, I am a firm believer, that 90+% of all projects
on sf.net or anywhere else that choose GPL as their "free license" do so
without ever having read or even understood the lawyerspeak inside it.
They mainly do so because "everyone else is doing it" and "it is cool".
I observed multiple times that once you talk to a developer and
*explain* him what GPL exactly means in a legalese sense, they start to
wonder whether they did the right choice. And GPLv2 was a boring but
manageable read. GPLv3 is not.
Best regards
Henning
Re: jcp-open Digest of: get.703_703
Posted by Ralph Goers <Ra...@dslextreme.com>.
William A. Rowe, Jr. wrote:
> Ralph Goers wrote:
>
>>>
>>>
>> I think I might take a different approach to this problem. I would
>> suggest that the only way to really solve this is to modify the Apache
>> license in a manner similar to the GPL. I would do something like add a
>> new termination section such as below. This license would terminate
>> Sun's right to use any Apache software.
>>
>> 10. Termination - Your rights under this license will automatically
>> terminate should you own or control any specification, process or other
>> kind of work which is made publicly available under any public license,
>> but which the Apache Software Foundation is prohibited from implementing
>> due to license, patent, or other restrictions that are incompatible with
>> this license and are directly under your control.
>>
>
> Unfortunately, this is a clause better left to the likes of the FSF. We are
> not fanatics, and don't care to be cast as such.
>
> This clause is so broad as to make most education institutions walk straight
> away from such an AL agreement. We are already walking a fine line with the
> exisitng patent reciprocity clauses of AL that is hard for them to reparse
> in the distributed-IP environment of a university.
>
> What is to 'own or control' .. v. .. 'directly under your control', and
> even v. 'public license' - these are all fuzzy areas that would make it
> painful for many users/developers, yet fairly trivial to sidestep :-/
>
Hey, it is just wording that lawyer's can fix. It was meant to spawn
ideas, not as a final draft.
> The AL is powerful because of 1. the amount of code available for people
> (especially developers) to use, and 2. minimal restrictions necessary to
> protect the developers of that code. If it's watered down with additional
> cruft, it loses it's validity. This is one of the major obstacles for the
> GPLv3 itself, to overcome the simplicity of the GPLv2 in the minds of
> users of the GPL.
>
Actually, I disagree with your observations about the GPL. I think many
folks are comfortable using it in many situations, and many GPL projects
are doing quite well. Secondly, while I agree with your observations
that the amount of code available at Apache, and its quality, I don't
agree that the current license makes it "powerful", although it is what
makes it popular and highly used. In fact, by design the current
license effectively gives away any power the licensor may have.
My feeling is that if the ASF wants to have any leverage than the only
effective way it can do that is through the license. I am not saying it
needs to be as "heavy" as the GPL, but just something that keeps people
honest. Something that says if you are going to call it open than it has
to be open enough that the ASF can implement it. If you don't want to do
that then don't make the spec public and don't call it open, and then
you won't be violating our license.
The idea of abandoning the JCP seems a lot like saying "we are taking
our toys and going home". If that means the other kids won't have toys
to play with it might mean something, but if they already have a pretty
full toy box and some other friends to play with they aren't going to
care much.
Ralph
Re: jcp-open Digest of: get.703_703
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ralph Goers wrote:
>>
> I think I might take a different approach to this problem. I would
> suggest that the only way to really solve this is to modify the Apache
> license in a manner similar to the GPL. I would do something like add a
> new termination section such as below. This license would terminate
> Sun's right to use any Apache software.
>
> 10. Termination - Your rights under this license will automatically
> terminate should you own or control any specification, process or other
> kind of work which is made publicly available under any public license,
> but which the Apache Software Foundation is prohibited from implementing
> due to license, patent, or other restrictions that are incompatible with
> this license and are directly under your control.
Unfortunately, this is a clause better left to the likes of the FSF. We are
not fanatics, and don't care to be cast as such.
This clause is so broad as to make most education institutions walk straight
away from such an AL agreement. We are already walking a fine line with the
exisitng patent reciprocity clauses of AL that is hard for them to reparse
in the distributed-IP environment of a university.
What is to 'own or control' .. v. .. 'directly under your control', and
even v. 'public license' - these are all fuzzy areas that would make it
painful for many users/developers, yet fairly trivial to sidestep :-/
The AL is powerful because of 1. the amount of code available for people
(especially developers) to use, and 2. minimal restrictions necessary to
protect the developers of that code. If it's watered down with additional
cruft, it loses it's validity. This is one of the major obstacles for the
GPLv3 itself, to overcome the simplicity of the GPLv2 in the minds of
users of the GPL.
Bill
Re: jcp-open Digest of: get.703_703
Posted by Henning Schmiedehausen <he...@apache.org>.
We are not a corporation that "competes". We offer open source software
for everyone to use and a place to build communities that believe in
"the Apache way" (ah, and we offer one of the most respected brands in
the open source world as a whole and specifically the Java world... ;-) )
We are IMHO not in the field to use our code base as a weapon to push
forward an agenda. We are not the FSF.
This whole claim is plain dumb to me. Why would we want to do that? We
have accepted a long time ago, that there are fields of software where
we as a foundation can not and do not want to go. We chose to go to the
J2SE implementation because we felt that it is necessary to have an open
implementation and we believed that our contract with Sun gave us the
tools to build one. The FOU cropped up and we hit a contractual breach.
It is our intent to improve and better the JCP from within. Make it more
open source friendly and less controlled by a single bully.
We do not walk around trying to educate "the community" about the "right
ways of free software". That is the agenda of another foundation. We
care about communities that adhere to our rules, we do not try to
convert all communities to our rules.
Best regards
Henning
Ralph Goers schrieb:
>
>
> Craig McClanahan wrote:
>> In other words "because we don't like FOU restrictions, we're going to
>> impose some of our own."
>>
>> Yah, THAT makes a lot of sense :-).
>>
> Interesting perspective. But even put that way it still makes sense to
> me. Primarily because the objective is the same as a "poison pill" that
> corporations often use. In this case it is "OK, since you like FOU
> restrictions we know how to play that game too. Now stop it and play nice".
>
> Ralph
Re: jcp-open Digest of: get.703_703
Posted by Henning Schmiedehausen <he...@apache.org>.
We are not a corporation that "competes". We offer open source software
for everyone to use and a place to build communities that believe in
"the Apache
We are IMHO not in the field to use our code base as a weapon to push
forward an agenda. We are not the FSF.
This whole claim is plain dumb to me. Why would we want to do that. We
have accepted a long time ago, that there are fields of software where
we as a foundation can not and do not want to go. We chose to go to the
J2SE implementation because we feel that it is necessary to have an open
implementation and we believed that our contract with Sun gave us the
tools to build one. The FOU cropped up and we hit a contractual breach.
It is our intent to improve and better the JCP from within. Make it more
open source friendly and less controlled by a single bully.
We do not walk around trying to educate "the community" about the "right
ways of free software". That is the agenda of another foundation. We
care about communities that adhere to our rules, we do not try to
convert all communities to our rules.
Best regards
Henning
Ralph Goers schrieb:
>
>
> Craig McClanahan wrote:
>> In other words "because we don't like FOU restrictions, we're going to
>> impose some of our own."
>>
>> Yah, THAT makes a lot of sense :-).
>>
> Interesting perspective. But even put that way it still makes sense to
> me. Primarily because the objective is the same as a "poison pill" that
> corporations often use. In this case it is "OK, since you like FOU
> restrictions we know how to play that game too. Now stop it and play nice".
>
> Ralph
Re: jcp-open Digest of: get.703_703
Posted by Ralph Goers <Ra...@dslextreme.com>.
Craig McClanahan wrote:
> In other words "because we don't like FOU restrictions, we're going to
> impose some of our own."
>
> Yah, THAT makes a lot of sense :-).
>
Interesting perspective. But even put that way it still makes sense to
me. Primarily because the objective is the same as a "poison pill" that
corporations often use. In this case it is "OK, since you like FOU
restrictions we know how to play that game too. Now stop it and play nice".
Ralph
Re: jcp-open Digest of: get.703_703
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 5, 2007, at 1:58 AM, Craig McClanahan wrote:
> On 7/4/07, Ralph Goers <Ra...@dslextreme.com> wrote:
>> I think I might take a different approach to this problem. I would
>> suggest that the only way to really solve this is to modify the
>> Apache
>> license in a manner similar to the GPL. I would do something like
>> add a
>> new termination section such as below. This license would terminate
>> Sun's right to use any Apache software.
>>
>> 10. Termination - Your rights under this license will automatically
>> terminate should you own or control any specification, process or
>> other
>> kind of work which is made publicly available under any public
>> license,
>> but which the Apache Software Foundation is prohibited from
>> implementing
>> due to license, patent, or other restrictions that are
>> incompatible with
>> this license and are directly under your control.
>
> In other words "because we don't like FOU restrictions, we're going to
> impose some of our own."
>
> Yah, THAT makes a lot of sense :-).
And we could license the use of the term "Freedom" from the FSF to
describe it, since their definition seems to apply.
geir
Re: jcp-open Digest of: get.703_703
Posted by Ralph Goers <Ra...@dslextreme.com>.
Martin van den Bemt wrote:
> Besides that I don't think the Apache License will pass the Open Source Definition criteria with
> this Termination clause and also feels like to contradict the goal of our Apache License.
>
>
I took a look at http://www.opensource.org/docs/definition.php and none
of the clauses seems to apply to such a termination policy.
Yes, it would certainly conflict with the current goal of the Apache
license. I guess that is kind of the point.
Ralph
Re: jcp-open Digest of: get.703_703
Posted by Martin van den Bemt <ml...@mvdb.net>.
Besides that I don't think the Apache License will pass the Open Source Definition criteria with
this Termination clause and also feels like to contradict the goal of our Apache License.
Mvgr,
Martin
Craig McClanahan wrote:
> On 7/4/07, Ralph Goers <Ra...@dslextreme.com> wrote:
>> I think I might take a different approach to this problem. I would
>> suggest that the only way to really solve this is to modify the Apache
>> license in a manner similar to the GPL. I would do something like add a
>> new termination section such as below. This license would terminate
>> Sun's right to use any Apache software.
>>
>> 10. Termination - Your rights under this license will automatically
>> terminate should you own or control any specification, process or other
>> kind of work which is made publicly available under any public license,
>> but which the Apache Software Foundation is prohibited from implementing
>> due to license, patent, or other restrictions that are incompatible with
>> this license and are directly under your control.
>
> In other words "because we don't like FOU restrictions, we're going to
> impose some of our own."
>
> Yah, THAT makes a lot of sense :-).
>
>>
>> Ralph
>>
>
> Craig
>
>
Re: jcp-open Digest of: get.703_703
Posted by Craig McClanahan <cr...@apache.org>.
On 7/4/07, Ralph Goers <Ra...@dslextreme.com> wrote:
> I think I might take a different approach to this problem. I would
> suggest that the only way to really solve this is to modify the Apache
> license in a manner similar to the GPL. I would do something like add a
> new termination section such as below. This license would terminate
> Sun's right to use any Apache software.
>
> 10. Termination - Your rights under this license will automatically
> terminate should you own or control any specification, process or other
> kind of work which is made publicly available under any public license,
> but which the Apache Software Foundation is prohibited from implementing
> due to license, patent, or other restrictions that are incompatible with
> this license and are directly under your control.
In other words "because we don't like FOU restrictions, we're going to
impose some of our own."
Yah, THAT makes a lot of sense :-).
>
> Ralph
>
Craig