You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2007/07/30 16:12:01 UTC
JSR-317 and JSR-318 Vote Today
There are two new JSRs for Java EE -
http://www.jcp.org/en/jsr/detail?id=317
http://www.jcp.org/en/jsr/detail?id=318
I plan to vote "no" as Sun is the spec lead.
Comments?
geir
Re: JSR-317 and JSR-318 Vote Today
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
On 7/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
>
> Comments?
>
> geir
>
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: JSR-317 and JSR-318 Vote Today
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 31, 2007, at 1:18 AM, Stephen Colebourne wrote:
> I haven't really had the time to follow the whole of the
> discussion, but I believe that the vote 'no to Sun-led JSRs'
> strategy is the correct one for the foreseeable future. Sun have
> broken their JSPA agreement, knowing we can't sue.
Correction: we can sue, and would probably win such a suit, but we
choose
not to for a variety of reasons (one of the main ones being that it is
difficult to have a dialog once a lawsuit is engaged). Personally,
I'd rather burn the JCP to the ground than bother the legal system with
something so inane as Sun's spineless decisions -- we have better things
to do.
....Roy
Re: JSR-317 and JSR-318 Vote Today
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Aug 1, 2007, at 10:59 AM, Andrus Adamchik wrote:
>
> On Aug 1, 2007, at 5:17 PM, Sam Ruby wrote:
>
>> Paraphrased, the ASF position is that we have no problem with
>> communities forming around commercial implementations, or around
>> non-open source licenses, or around open or free licenses other than
>> our own, or around the Apache License, Version 2.0 at places other
>> than the ASF.
>
> This is not as much a position, but rather common sense. Why would
> we have a problem with whatever other people are doing? The
> question here is whether it is beneficial for the Foundation to
> participate in a given community (JCP in this case).
I think that our participation in the JCP is beneficial, assuming we
get this problem w/ Sun squared away. Our years of engagement have
shown that, IMO.
Our FOU problem is a big test for the JCP - will it be able to govern
itself to the degree that it can?
>
>> But, and this is a key but, at the ASF we only nurture communities
>> that release software under the Apache License. From time to time,
>> I've seen that position labeled as 'ideological', coupled with calls
>> for us to 'be pragmatic'.
>
> I thought of Andrew's "subfree" email as a provocation (maybe with
> the goal to point to the futility of the current JCP fight, and
> turn it towards JCP withdrawal route? I don't know). I am really
> hoping that "subfree" is not up for serious discussion, otherwise
> it will be a very sad turn of events at the Foundation.
I didn't take it seriously.
geir
Re: JSR-317 and JSR-318 Vote Today
Posted by Andrus Adamchik <aa...@apache.org>.
On Aug 1, 2007, at 5:17 PM, Sam Ruby wrote:
> Paraphrased, the ASF position is that we have no problem with
> communities forming around commercial implementations, or around
> non-open source licenses, or around open or free licenses other than
> our own, or around the Apache License, Version 2.0 at places other
> than the ASF.
This is not as much a position, but rather common sense. Why would we
have a problem with whatever other people are doing? The question
here is whether it is beneficial for the Foundation to participate in
a given community (JCP in this case).
> But, and this is a key but, at the ASF we only nurture communities
> that release software under the Apache License. From time to time,
> I've seen that position labeled as 'ideological', coupled with calls
> for us to 'be pragmatic'.
I thought of Andrew's "subfree" email as a provocation (maybe with
the goal to point to the futility of the current JCP fight, and turn
it towards JCP withdrawal route? I don't know). I am really hoping
that "subfree" is not up for serious discussion, otherwise it will be
a very sad turn of events at the Foundation.
Andrus
Re: JSR-317 and JSR-318 Vote Today
Posted by Sam Ruby <ru...@intertwingly.net>.
On 8/1/07, Andrew C. Oliver <ac...@buni.org> wrote:
> unlabeled, but roughly the same is better?
I will note that we haven't done that. Every code base from the ASF
has been released under an Apache License. Harmony was created in
good faith with the belief that it, too, could be released under the
Apache License, Version 2.0. This good faith was based on the fact
that we have a signed contract that states that we could do exactly
that.
In the past, we have had issues with Sun over T's and C's. Each time
in the past these issues had been resolved to our satisfaction. We
had no expectation that this time would be any different.
> Henning Schmiedehausen wrote:
> > On Wed, 2007-08-01 at 00:40 -0400, Andrew C. Oliver wrote:
> >
> >> pretend it is open source? I just don't see it. The compromise road
> >> of just creating an admitted project of notquiteopensource.apache.org
> >> seems a lot more pragmatic than playing "let's make lawyers rich and
> >
> > You can repeat this over and over again until you are blue in your face,
> > but this is not going to happen. Ever.
We do have a dilemma that we need to face head on, and I think Andy
has been doing a good job of pointing it out.
Paraphrased, the ASF position is that we have no problem with
communities forming around commercial implementations, or around
non-open source licenses, or around open or free licenses other than
our own, or around the Apache License, Version 2.0 at places other
than the ASF.
But, and this is a key but, at the ASF we only nurture communities
that release software under the Apache License. From time to time,
I've seen that position labeled as 'ideological', coupled with calls
for us to 'be pragmatic'.
We can't have it both ways.
Sun is busy on OpenJDK. Those that are waiting on Sun to provide us
what the contract that they signed said that they would are also "blue
in the face". This month, the conflict will enter into its second
year. We are in a war without an exit strategy. As unpopular as it
might be, we need to establish a timetable for withdrawal.
> > Best regards
> > Henning
- Sam Ruby
Re: JSR-317 and JSR-318 Vote Today
Posted by "Andrew C. Oliver" <ac...@buni.org>.
unlabeled, but roughly the same is better?
Henning Schmiedehausen wrote:
> On Wed, 2007-08-01 at 00:40 -0400, Andrew C. Oliver wrote:
>
>> pretend it is open source? I just don't see it. The compromise road
>> of just creating an admitted project of notquiteopensource.apache.org
>> seems a lot more pragmatic than playing "let's make lawyers rich and
>>
>
> You can repeat this over and over again until you are blue in your face,
> but this is not going to happen. Ever.
>
> Best regards
> Henning
>
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: JSR-317 and JSR-318 Vote Today
Posted by Andrus Adamchik <aa...@apache.org>.
On Aug 1, 2007, at 10:39 AM, Henning Schmiedehausen wrote:
> On Wed, 2007-08-01 at 00:40 -0400, Andrew C. Oliver wrote:
>> pretend it is open source? I just don't see it. The compromise
>> road
>> of just creating an admitted project of notquiteopensource.apache.org
>> seems a lot more pragmatic than playing "let's make lawyers rich and
>
> You can repeat this over and over again until you are blue in your
> face,
> but this is not going to happen. Ever.
>
> Best regards
> Henning
Exactly.
Andrus
Re: JSR-317 and JSR-318 Vote Today
Posted by Henning Schmiedehausen <he...@apache.org>.
On Wed, 2007-08-01 at 00:40 -0400, Andrew C. Oliver wrote:
> pretend it is open source? I just don't see it. The compromise road
> of just creating an admitted project of notquiteopensource.apache.org
> seems a lot more pragmatic than playing "let's make lawyers rich and
You can repeat this over and over again until you are blue in your face,
but this is not going to happen. Ever.
Best regards
Henning
Re: JSR-317 and JSR-318 Vote Today
Posted by "Andrew C. Oliver" <ac...@buni.org>.
So the wealth and wellbeing of all of apache, all of the other projects,
etc should be put at risk to fund a lawsuit (you do realize these cost a
lot of money), so that you can continue to play in sun's backyard and
pretend it is open source? I just don't see it. The compromise road
of just creating an admitted project of notquiteopensource.apache.org
seems a lot more pragmatic than playing "let's make lawyers rich and
loose lots of income in the process".. I just don't think the
implementation of Sunstards (not an actual standard but a sun's special
standards board "standard") is more important than HTTPD or Ant or
everything else to put Apache in the financial risk that a lawsuit would
put it in. That's just me.
Ideally Apache will outlive the JCP and Java by a number of years.
-andy
Wade Chandler wrote:
> Well, the point is, if you sign a legally binding
> agreement and you have no intentions of expecting it
> to be legally binding, then you shouldn't worry about
> what happens at all nor expect it to actually be
> binding. Trying to change the system without ever
> supporting legal action doesn't make sense because
> part of the system, when dealing with a legal
> document, is that the law is the deciding factor as to
> who is right or wrong in a given situation if the two
> entities can not resolve the issue among themselves or
> some form of arbitration as it relates to the agreed
> terms. It is what makes the agreement concrete and
> meaningful.
>
> A lawsuit doesn't have to ask for monetary damages
> other than court costs and a final interpretation of
> the agreement, and it shouldn't have to mean that the
> two entities involved in such a suit can not continue
> to work together. This is the issue with the law these
> days. People look at everything related to laws and
> enforcing them as something bad, yet they keep signing
> NDAs, agreements, wills, etc. What other role do laws
> and the systems which enforce them actually play other
> than to make sure those involved adhere to the rules?
>
> If after a number of days, a gentleman's agreement can
> not be reached between two parties or some non-legal
> arbiter, when dealing with a legal agreement, the
> agreement needs to be interpreted by the power in
> which it was intended. I don't think this is too much
> to ask of any organization doing business.
>
> I for one have a great relationship with many Sun
> employees, and the company itself, per the software I
> use and projects I am a member, has been very good to
> me. However, if they were to breach a legal agreement
> with me, for which we could not reach a settlement, if
> I felt they were definitely in breach of our
> agreement, I wouldn't think it unreasonable for the
> courts to make that determination.
>
> I assume Apache has invested a lot of time, energy,
> and resources into supporting different JSRs. Thus, it
> is in Apaches interest to protect those investments
> and the processes which they have agreed to be bound,
> and if they are not willing to do so, then no party
> they are involved will feel they have any need to fear
> breaching agreements. It is the law which makes us
> equal and gives teeth to these agreements.
>
> That said, an agreement where Sun and Apache sit down
> and work this out is in the best interest of not just
> the two entities but all those who contribute to their
> projects. That includes myself and many others. We
> should hope for the best, and do what is necessary
> when we have to. Sometimes that means getting involved
> with a lawsuit, but it should be the last step, but it
> should definitely precede an exit strategy or not
> insisting Sun to adhere to their end of an agreement
> if they are breaching it just for fear of going to
> court.
>
> Wade
>
> --- "Andrew C. Oliver" <ac...@buni.org> wrote:
>
>
>> While a lawsuit should always be on the table I
>> can't say that I'd
>> donate to such a cause. I like coding, law plainly
>> disturbs me and I
>> act defensively (one way is to get away...far away).
>> I know that I
>> would certainly have a lack of passion to
>> participate, but some of you
>> have way more passion for the law than I do. In the
>> end some of the
>> very people and organizations that Apache relies on
>> for support would
>> see a legally contentious Apache as a bad thing and
>> would probably
>> withdraw their support. Organizations such as Sun
>> whose backyard Apache
>> chose to play in would engage Apache less in the
>> future. This might
>> even include organizations whose support Apache
>> enjoys now.
>>
>> The more viable options are to:
>>
>> A. Adapt
>> B. Change the environment
>>
>> For option A -- create a separate subdivision of
>> Apache:
>> subfree.apache.org or sharedsource.apache.org where
>> not-so-free stuff
>> can be developed. Members serving in the JCP can be
>> VPs and
>> representatives of Apache Software Foundation:
>> SharedSource Division.
>> The charter of the foundation can be amended to make
>> this possible. I
>> am serious about this. Putting this stuff in its
>> own box would give
>> fair warning to people, avoid tarnishing Apache
>> generally, etc. It
>> would also make a stronger statement than being the
>> vote from the kiddy
>> table.
>>
>> For option B -- withdraw from the JCP. This means
>> you're serious.
>> Create a new organization dedicated to actual open
>> standards. Openly
>> question the legitimacy of the JCP.
>>
>> Anything else (other than some mutation of A, B or
>> actually suing) means
>> that frankly you're just jerking around at this
>> point really. If you
>> have lots of time to jerk around for months on end,
>> I have things for
>> you to do. Today I discovered a nasty lil bug in an
>> evolution plugin,
>> I'd love to see a more persistent store for the
>> Lightning plugin for
>> Thunderbird...and I've always got things that Java
>> peeps or GUI peeps
>> could do...
>>
>> -Andy
>>
>>> Seems to me, if one thinks this should all be
>>>
>> open,
>>
>>> then leaving a lawsuit on the table and being
>>>
>> willing
>>
>>> to use it is a better strategy than an exit
>>>
>> strategy.
>>
>>> The corporations, such as IBM or BEA or Oracle or
>>> whoever are probably not going to get into this
>>>
>> more
>>
>>> than likely because they want to be able to do
>>>
>> what
>>
>>> ever they like when it comes their turn and still
>>>
>> get
>>
>>> to share IP.
>>>
>>> Sort of like IBM suing Amazon over things they
>>>
>> should
>>
>>> never have been able to patent. This is what large
>>>
>> out
>>
>>> of touch corporations do. Damage the integrity of
>>>
>> the
>>
>>> system and work to make it harder on the little
>>>
>> guy.
>>
>>> To me the best thing Apache can do is stand up for
>>>
>> the
>>
>>> little guys whenever they get the chance. This
>>>
>> seems
>>
>>> like one of them.
>>>
>>> Wade
>>>
>>>
>> --
>> Buni Meldware Communication Suite
>> http://buni.org
>> Multi-platform and extensible Email,
>> Calendaring (including freebusy),
>> Rich Webmail, Web-calendaring, ease
>> of installation/administration.
>>
>>
>>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: JSR-317 and JSR-318 Vote Today
Posted by Wade Chandler <hw...@yahoo.com>.
Well, the point is, if you sign a legally binding
agreement and you have no intentions of expecting it
to be legally binding, then you shouldn't worry about
what happens at all nor expect it to actually be
binding. Trying to change the system without ever
supporting legal action doesn't make sense because
part of the system, when dealing with a legal
document, is that the law is the deciding factor as to
who is right or wrong in a given situation if the two
entities can not resolve the issue among themselves or
some form of arbitration as it relates to the agreed
terms. It is what makes the agreement concrete and
meaningful.
A lawsuit doesn't have to ask for monetary damages
other than court costs and a final interpretation of
the agreement, and it shouldn't have to mean that the
two entities involved in such a suit can not continue
to work together. This is the issue with the law these
days. People look at everything related to laws and
enforcing them as something bad, yet they keep signing
NDAs, agreements, wills, etc. What other role do laws
and the systems which enforce them actually play other
than to make sure those involved adhere to the rules?
If after a number of days, a gentleman's agreement can
not be reached between two parties or some non-legal
arbiter, when dealing with a legal agreement, the
agreement needs to be interpreted by the power in
which it was intended. I don't think this is too much
to ask of any organization doing business.
I for one have a great relationship with many Sun
employees, and the company itself, per the software I
use and projects I am a member, has been very good to
me. However, if they were to breach a legal agreement
with me, for which we could not reach a settlement, if
I felt they were definitely in breach of our
agreement, I wouldn't think it unreasonable for the
courts to make that determination.
I assume Apache has invested a lot of time, energy,
and resources into supporting different JSRs. Thus, it
is in Apaches interest to protect those investments
and the processes which they have agreed to be bound,
and if they are not willing to do so, then no party
they are involved will feel they have any need to fear
breaching agreements. It is the law which makes us
equal and gives teeth to these agreements.
That said, an agreement where Sun and Apache sit down
and work this out is in the best interest of not just
the two entities but all those who contribute to their
projects. That includes myself and many others. We
should hope for the best, and do what is necessary
when we have to. Sometimes that means getting involved
with a lawsuit, but it should be the last step, but it
should definitely precede an exit strategy or not
insisting Sun to adhere to their end of an agreement
if they are breaching it just for fear of going to
court.
Wade
--- "Andrew C. Oliver" <ac...@buni.org> wrote:
> While a lawsuit should always be on the table I
> can't say that I'd
> donate to such a cause. I like coding, law plainly
> disturbs me and I
> act defensively (one way is to get away...far away).
> I know that I
> would certainly have a lack of passion to
> participate, but some of you
> have way more passion for the law than I do. In the
> end some of the
> very people and organizations that Apache relies on
> for support would
> see a legally contentious Apache as a bad thing and
> would probably
> withdraw their support. Organizations such as Sun
> whose backyard Apache
> chose to play in would engage Apache less in the
> future. This might
> even include organizations whose support Apache
> enjoys now.
>
> The more viable options are to:
>
> A. Adapt
> B. Change the environment
>
> For option A -- create a separate subdivision of
> Apache:
> subfree.apache.org or sharedsource.apache.org where
> not-so-free stuff
> can be developed. Members serving in the JCP can be
> VPs and
> representatives of Apache Software Foundation:
> SharedSource Division.
> The charter of the foundation can be amended to make
> this possible. I
> am serious about this. Putting this stuff in its
> own box would give
> fair warning to people, avoid tarnishing Apache
> generally, etc. It
> would also make a stronger statement than being the
> vote from the kiddy
> table.
>
> For option B -- withdraw from the JCP. This means
> you're serious.
> Create a new organization dedicated to actual open
> standards. Openly
> question the legitimacy of the JCP.
>
> Anything else (other than some mutation of A, B or
> actually suing) means
> that frankly you're just jerking around at this
> point really. If you
> have lots of time to jerk around for months on end,
> I have things for
> you to do. Today I discovered a nasty lil bug in an
> evolution plugin,
> I'd love to see a more persistent store for the
> Lightning plugin for
> Thunderbird...and I've always got things that Java
> peeps or GUI peeps
> could do...
>
> -Andy
> > Seems to me, if one thinks this should all be
> open,
> > then leaving a lawsuit on the table and being
> willing
> > to use it is a better strategy than an exit
> strategy.
> > The corporations, such as IBM or BEA or Oracle or
> > whoever are probably not going to get into this
> more
> > than likely because they want to be able to do
> what
> > ever they like when it comes their turn and still
> get
> > to share IP.
> >
> > Sort of like IBM suing Amazon over things they
> should
> > never have been able to patent. This is what large
> out
> > of touch corporations do. Damage the integrity of
> the
> > system and work to make it harder on the little
> guy.
> > To me the best thing Apache can do is stand up for
> the
> > little guys whenever they get the chance. This
> seems
> > like one of them.
> >
> > Wade
> >
>
>
> --
> Buni Meldware Communication Suite
> http://buni.org
> Multi-platform and extensible Email,
> Calendaring (including freebusy),
> Rich Webmail, Web-calendaring, ease
> of installation/administration.
>
>
Re: JSR-317 and JSR-318 Vote Today
Posted by "Andrew C. Oliver" <ac...@buni.org>.
While a lawsuit should always be on the table I can't say that I'd
donate to such a cause. I like coding, law plainly disturbs me and I
act defensively (one way is to get away...far away). I know that I
would certainly have a lack of passion to participate, but some of you
have way more passion for the law than I do. In the end some of the
very people and organizations that Apache relies on for support would
see a legally contentious Apache as a bad thing and would probably
withdraw their support. Organizations such as Sun whose backyard Apache
chose to play in would engage Apache less in the future. This might
even include organizations whose support Apache enjoys now.
The more viable options are to:
A. Adapt
B. Change the environment
For option A -- create a separate subdivision of Apache:
subfree.apache.org or sharedsource.apache.org where not-so-free stuff
can be developed. Members serving in the JCP can be VPs and
representatives of Apache Software Foundation: SharedSource Division.
The charter of the foundation can be amended to make this possible. I
am serious about this. Putting this stuff in its own box would give
fair warning to people, avoid tarnishing Apache generally, etc. It
would also make a stronger statement than being the vote from the kiddy
table.
For option B -- withdraw from the JCP. This means you're serious.
Create a new organization dedicated to actual open standards. Openly
question the legitimacy of the JCP.
Anything else (other than some mutation of A, B or actually suing) means
that frankly you're just jerking around at this point really. If you
have lots of time to jerk around for months on end, I have things for
you to do. Today I discovered a nasty lil bug in an evolution plugin,
I'd love to see a more persistent store for the Lightning plugin for
Thunderbird...and I've always got things that Java peeps or GUI peeps
could do...
-Andy
> Seems to me, if one thinks this should all be open,
> then leaving a lawsuit on the table and being willing
> to use it is a better strategy than an exit strategy.
> The corporations, such as IBM or BEA or Oracle or
> whoever are probably not going to get into this more
> than likely because they want to be able to do what
> ever they like when it comes their turn and still get
> to share IP.
>
> Sort of like IBM suing Amazon over things they should
> never have been able to patent. This is what large out
> of touch corporations do. Damage the integrity of the
> system and work to make it harder on the little guy.
> To me the best thing Apache can do is stand up for the
> little guys whenever they get the chance. This seems
> like one of them.
>
> Wade
>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: JSR-317 and JSR-318 Vote Today
Posted by Wade Chandler <hw...@yahoo.com>.
--- Roland Weber <ro...@apache.org> wrote:
> Stephen Colebourne wrote:
> > I believe that the vote 'no to Sun-led JSRs'
> strategy is the correct one
> > for the foreseeable future. Sun have broken their
> JSPA agreement,
> > knowing we can't sue. This is currently our best
> course of action,
> > however we do need to determine what our next
> strategy is if this one
> > fails to succeed.
>
> I believe the technical term is "exit strategy". I
> agree with you
> that the VNTS-JSRs strategy is the best for now, but
> also with Andy's
> assessment that this strategy is basically
> ineffective. Either other
> participants of the JCP put pressure on Sun, or this
> situation will
> not be resolved at all.
> It's taken two months of discussion to get to this
> temporary strategy,
> it will take even longer to get to the next one. Sun
> will have ample
> time to reconsider, or not. If they do, everything's
> peachy. So the
> discussion should focus on the other case.
>
Seems to me, if one thinks this should all be open,
then leaving a lawsuit on the table and being willing
to use it is a better strategy than an exit strategy.
The corporations, such as IBM or BEA or Oracle or
whoever are probably not going to get into this more
than likely because they want to be able to do what
ever they like when it comes their turn and still get
to share IP.
Sort of like IBM suing Amazon over things they should
never have been able to patent. This is what large out
of touch corporations do. Damage the integrity of the
system and work to make it harder on the little guy.
To me the best thing Apache can do is stand up for the
little guys whenever they get the chance. This seems
like one of them.
Wade
Re: JSR-317 and JSR-318 Vote Today
Posted by Roland Weber <ro...@apache.org>.
Stephen Colebourne wrote:
> I believe that the vote 'no to Sun-led JSRs' strategy is the correct one
> for the foreseeable future. Sun have broken their JSPA agreement,
> knowing we can't sue. This is currently our best course of action,
> however we do need to determine what our next strategy is if this one
> fails to succeed.
I believe the technical term is "exit strategy". I agree with you
that the VNTS-JSRs strategy is the best for now, but also with Andy's
assessment that this strategy is basically ineffective. Either other
participants of the JCP put pressure on Sun, or this situation will
not be resolved at all.
It's taken two months of discussion to get to this temporary strategy,
it will take even longer to get to the next one. Sun will have ample
time to reconsider, or not. If they do, everything's peachy. So the
discussion should focus on the other case.
cheers,
Roland
Re: JSR-317 and JSR-318 Vote Today
Posted by Stephen Colebourne <sc...@joda.org>.
Geir Magnusson Jr. wrote:
>
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
+1
I haven't really had the time to follow the whole of the discussion, but
I believe that the vote 'no to Sun-led JSRs' strategy is the correct one
for the foreseeable future. Sun have broken their JSPA agreement,
knowing we can't sue. This is currently our best course of action,
however we do need to determine what our next strategy is if this one
fails to succeed.
In addition, for any JSR we vote no on, it would be unreasonable for
Apache to lend its name to the EG. Doing so would be a form of accepting
the validity of the process. Unfortunately, this will harm some
individuals at Apache - hopefully they can join as JCP individual
members if they wish to be on the new JSR.
Finally, none of this should affect existing JSRs.
Stephen
Re: JSR-317 and JSR-318 Vote Today
Posted by Roland Weber <ro...@apache.org>.
+1
Geir Magnusson Jr. wrote:
>
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
>
> Comments?
>
> geir
>
>
Re: JSR-317 and JSR-318 Vote Today
Posted by Davanum Srinivas <da...@gmail.com>.
Craig,
Could we get Sun folks to state this publicly as a response to our
Open Letter? If this is indeed the case, then why the silence, they
should be shouting this from the rooftops...no? what am i missing?
thanks,
dims
On 7/30/07, Craig L Russell <Cr...@sun.com> wrote:
> Hi Geir,
>
> Apache believes Sun is in violation of the JSPA. Sun does not.
>
> What we are looking for is to get Sun to change their behavior wrt
> licensing TCK's. I think that asking them to develop this TCK in the
> open under an open license would be a step in the direction we want
> them to take.
>
> Craig
>
> On Jul 30, 2007, at 10:02 AM, Geir Magnusson Jr. wrote:
>
> >
> > On Jul 30, 2007, at 12:42 PM, Craig L Russell wrote:
> >
> >> I'd like to see a Yes vote on 317 if the spec lead develops the
> >> TCK in open. The TCK seems to be the major issue that Apache has
> >> with the spec lead, and this would suggest that Apache's position
> >> is open to discussion.
> >
> > The spec lead is in violation of the JSPA, IMO. Why should they be
> > able to lead any JSR?
> >
> > geir
> >
> >>
> >> Craig
> >>
> >> On Jul 30, 2007, at 7:12 AM, Geir Magnusson Jr. wrote:
> >>
> >>>
> >>> There are two new JSRs for Java EE -
> >>>
> >>> http://www.jcp.org/en/jsr/detail?id=317
> >>>
> >>> http://www.jcp.org/en/jsr/detail?id=318
> >>>
> >>> I plan to vote "no" as Sun is the spec lead.
> >>>
> >>> Comments?
> >>>
> >>> geir
> >>>
> >>>
> >>
>
>
>
> Craig Russell
> DB PMC, OpenJPA PMC
> clr@apache.org http://db.apache.org/jdo
>
>
>
>
--
Davanum Srinivas :: http://davanum.wordpress.com
Re: JSR-317 and JSR-318 Vote Today
Posted by Roland Weber <ro...@apache.org>.
Andrew C. Oliver wrote:
> why not just go
> ahead and do that. . Change the Apache license so that it is
> incompatible with open source but compatible with Sun's terms and the
> REAL JCP? It is a legitimate option.
Yes it is. Anyone is free to do exactly that, as long as
the result is not called an Apache license. The ASF should
not lend it's name for that.
> The majority of the people on
> those projects care more about being part of the JCP and such than
> actually being open source.
Sourceforge is their friend.
Apache stands for communities that build open source software
which is licensed under the Apache License. Not GPL, MPL, CC,
BSD, or something that is not quite open and not quite Apache.
cheers,
Roland
Re: JSR-317 and JSR-318 Vote Today
Posted by Bill Barker <wb...@wilshire.com>.
"Andrew C. Oliver" <ac...@buni.org> wrote in message
news:46AEB5D7.7020103@buni.org...
>
> Huh? I'm proposing a new ASL+FOU and say semifree.apache.org for non-open
> source JCP stuff. In the interim the non-open source software at Apache
> can be marked as such. Why the long dance? This ineffective voting
> strategy can't be for Sun's benefit (bad advocacy "attack the audience")
> so it must be for an internal audience. I'm just suggesting what if the
> ASF goes ahead and creates a special devision for not-so-open source
> stuff. Then those that want to participate in the ASF and the JCP can do
> so without worrying about stickly things.
+1
> -Andy
>
> Geir Magnusson Jr. wrote:
>> I'm having trouble reconciling your point of view about open source
>> standards and development of same (e.g. NDAs for TCK) and your other
>> point of view about open source standards and development of same (e.g.
>> licenses for TCK)
>>
>> geir
>>
>> On Jul 30, 2007, at 10:07 PM, Andrew C. Oliver wrote:
>>
>>>
>>>>
>>>> We don't need to ask. It is a requirement of the JSPA, which Sun has
>>>> signed with every participant in the JCP, that the Spec Lead must
>>>> provide the TCK under terms that do not prevent an open source
>>>> implementation. The terms that Sun provided to us would have required
>>>> a change to our license that is incompatible with open source.
>>>>
>>> Rather than taking more basically ineffective actions...why not just go
>>> ahead and do that. . Change the Apache license so that it is
>>> incompatible with open source but compatible with Sun's terms and the
>>> REAL JCP? It is a legitimate option. The majority of the people on
>>> those projects care more about being part of the JCP and such than
>>> actually being open source.
>>>
>>> -Andy
>>>
>>>> ....Roy
>>>
>>>
>>> --Buni Meldware Communication Suite
>>> http://buni.org
>>> Multi-platform and extensible Email, Calendaring (including freebusy),
>>> Rich Webmail, Web-calendaring, ease of installation/administration.
>>>
>
>
> --
> Buni Meldware Communication Suite
> http://buni.org
> Multi-platform and extensible Email, Calendaring (including freebusy),
> Rich Webmail, Web-calendaring, ease of installation/administration.
>
>
Re: JSR-317 and JSR-318 Vote Today
Posted by "Andrew C. Oliver" <ac...@buni.org>.
Huh? I'm proposing a new ASL+FOU and say semifree.apache.org for
non-open source JCP stuff. In the interim the non-open source software
at Apache can be marked as such. Why the long dance? This ineffective
voting strategy can't be for Sun's benefit (bad advocacy "attack the
audience") so it must be for an internal audience. I'm just suggesting
what if the ASF goes ahead and creates a special devision for
not-so-open source stuff. Then those that want to participate in the
ASF and the JCP can do so without worrying about stickly things.
-Andy
Geir Magnusson Jr. wrote:
> I'm having trouble reconciling your point of view about open source
> standards and development of same (e.g. NDAs for TCK) and your other
> point of view about open source standards and development of same
> (e.g. licenses for TCK)
>
> geir
>
> On Jul 30, 2007, at 10:07 PM, Andrew C. Oliver wrote:
>
>>
>>>
>>> We don't need to ask. It is a requirement of the JSPA, which Sun has
>>> signed with every participant in the JCP, that the Spec Lead must
>>> provide the TCK under terms that do not prevent an open source
>>> implementation. The terms that Sun provided to us would have required
>>> a change to our license that is incompatible with open source.
>>>
>> Rather than taking more basically ineffective actions...why not just
>> go ahead and do that. . Change the Apache license so that it is
>> incompatible with open source but compatible with Sun's terms and the
>> REAL JCP? It is a legitimate option. The majority of the people on
>> those projects care more about being part of the JCP and such than
>> actually being open source.
>>
>> -Andy
>>
>>> ....Roy
>>
>>
>> --Buni Meldware Communication Suite
>> http://buni.org
>> Multi-platform and extensible Email, Calendaring (including
>> freebusy), Rich Webmail, Web-calendaring, ease of
>> installation/administration.
>>
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: JSR-317 and JSR-318 Vote Today
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I'm having trouble reconciling your point of view about open source
standards and development of same (e.g. NDAs for TCK) and your other
point of view about open source standards and development of same
(e.g. licenses for TCK)
geir
On Jul 30, 2007, at 10:07 PM, Andrew C. Oliver wrote:
>
>>
>> We don't need to ask. It is a requirement of the JSPA, which Sun has
>> signed with every participant in the JCP, that the Spec Lead must
>> provide the TCK under terms that do not prevent an open source
>> implementation. The terms that Sun provided to us would have
>> required
>> a change to our license that is incompatible with open source.
>>
> Rather than taking more basically ineffective actions...why not
> just go ahead and do that. . Change the Apache license so that it
> is incompatible with open source but compatible with Sun's terms
> and the REAL JCP? It is a legitimate option. The majority of the
> people on those projects care more about being part of the JCP and
> such than actually being open source.
>
> -Andy
>
>> ....Roy
>
>
> --
> Buni Meldware Communication Suite
> http://buni.org
> Multi-platform and extensible Email, Calendaring (including
> freebusy), Rich Webmail, Web-calendaring, ease of installation/
> administration.
>
Re: JSR-317 and JSR-318 Vote Today
Posted by Ralph Goers <Ra...@dslextreme.com>.
Andrew C. Oliver wrote:
>
> Rather than taking more basically ineffective actions...why not just
> go ahead and do that. . Change the Apache license so that it is
> incompatible with open source but compatible with Sun's terms and the
> REAL JCP? It is a legitimate option. The majority of the people on
> those projects care more about being part of the JCP and such than
> actually being open source.
I assume you are kidding, right? If they really feel that way then why
are the projects even at Apache?
Ralph
Re: JSR-317 and JSR-318 Vote Today
Posted by "Andrew C. Oliver" <ac...@buni.org>.
>
> We don't need to ask. It is a requirement of the JSPA, which Sun has
> signed with every participant in the JCP, that the Spec Lead must
> provide the TCK under terms that do not prevent an open source
> implementation. The terms that Sun provided to us would have required
> a change to our license that is incompatible with open source.
>
Rather than taking more basically ineffective actions...why not just go
ahead and do that. . Change the Apache license so that it is
incompatible with open source but compatible with Sun's terms and the
REAL JCP? It is a legitimate option. The majority of the people on
those projects care more about being part of the JCP and such than
actually being open source.
-Andy
> ....Roy
--
Buni Meldware Communication Suite
http://buni.org
Multi-platform and extensible Email,
Calendaring (including freebusy),
Rich Webmail, Web-calendaring, ease
of installation/administration.
Re: JSR-317 and JSR-318 Vote Today
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 30, 2007, at 2:57 PM, Craig L Russell wrote:
> Apache believes Sun is in violation of the JSPA. Sun does not.
Sun's opinion on that matter is irrelevant. Until we have a TCK in
hand under the terms required by the JSPA, the spec lead is violating
the JSPA (because providing that TCK is a requirement of the JSPA).
> What we are looking for is to get Sun to change their behavior wrt
> licensing TCK's. I think that asking them to develop this TCK in
> the open under an open license would be a step in the direction we
> want them to take.
What good would that do? Sun promised to do that for all JSRs they
lead. We have that in writing. If Sun isn't willing to adhere to
its existing commitments, then whatever additional commitments they
make are irrelevant -- habitual liars do not make good custodians.
We don't need to ask. It is a requirement of the JSPA, which Sun has
signed with every participant in the JCP, that the Spec Lead must
provide the TCK under terms that do not prevent an open source
implementation. The terms that Sun provided to us would have required
a change to our license that is incompatible with open source.
....Roy
Re: JSR-317 and JSR-318 Vote Today
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Geir,
Apache believes Sun is in violation of the JSPA. Sun does not.
What we are looking for is to get Sun to change their behavior wrt
licensing TCK's. I think that asking them to develop this TCK in the
open under an open license would be a step in the direction we want
them to take.
Craig
On Jul 30, 2007, at 10:02 AM, Geir Magnusson Jr. wrote:
>
> On Jul 30, 2007, at 12:42 PM, Craig L Russell wrote:
>
>> I'd like to see a Yes vote on 317 if the spec lead develops the
>> TCK in open. The TCK seems to be the major issue that Apache has
>> with the spec lead, and this would suggest that Apache's position
>> is open to discussion.
>
> The spec lead is in violation of the JSPA, IMO. Why should they be
> able to lead any JSR?
>
> geir
>
>>
>> Craig
>>
>> On Jul 30, 2007, at 7:12 AM, Geir Magnusson Jr. wrote:
>>
>>>
>>> There are two new JSRs for Java EE -
>>>
>>> http://www.jcp.org/en/jsr/detail?id=317
>>>
>>> http://www.jcp.org/en/jsr/detail?id=318
>>>
>>> I plan to vote "no" as Sun is the spec lead.
>>>
>>> Comments?
>>>
>>> geir
>>>
>>>
>>
Craig Russell
DB PMC, OpenJPA PMC
clr@apache.org http://db.apache.org/jdo
Re: JSR-317 and JSR-318 Vote Today
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 30, 2007, at 12:42 PM, Craig L Russell wrote:
> I'd like to see a Yes vote on 317 if the spec lead develops the TCK
> in open. The TCK seems to be the major issue that Apache has with
> the spec lead, and this would suggest that Apache's position is
> open to discussion.
The spec lead is in violation of the JSPA, IMO. Why should they be
able to lead any JSR?
geir
>
> Craig
>
> On Jul 30, 2007, at 7:12 AM, Geir Magnusson Jr. wrote:
>
>>
>> There are two new JSRs for Java EE -
>>
>> http://www.jcp.org/en/jsr/detail?id=317
>>
>> http://www.jcp.org/en/jsr/detail?id=318
>>
>> I plan to vote "no" as Sun is the spec lead.
>>
>> Comments?
>>
>> geir
>>
>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: JSR-317 and JSR-318 Vote Today
Posted by Roland Weber <ro...@apache.org>.
Craig L Russell wrote:
> I'd like to see a Yes vote on 317 if the spec lead develops the TCK in
> open. The TCK seems to be the major issue that Apache has with the spec
> lead, and this would suggest that Apache's position is open to discussion.
The problem is that we'd need a _binding_ statement that
the license for the TCK is and will continue to be open.
We won't get that until the vote has to be cast, right?
cheers,
Roland
Re: JSR-317 and JSR-318 Vote Today
Posted by Craig L Russell <Cr...@Sun.COM>.
I'd like to see a Yes vote on 317 if the spec lead develops the TCK
in open. The TCK seems to be the major issue that Apache has with the
spec lead, and this would suggest that Apache's position is open to
discussion.
Craig
On Jul 30, 2007, at 7:12 AM, Geir Magnusson Jr. wrote:
>
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
>
> Comments?
>
> geir
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JSR-317 and JSR-318 Vote Today
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 30, 2007, at 10:33 AM, Matthias Wessendorf wrote:
> just a question.
>
> how would a NO on:
> 317
>
> effect open_jpa / cayenne ?
Dunno :)
We're not objecting for technical reasons, but simply governance/
appropriateness of spec lead.
geir
>
> thx,
> Matthias
>
> On 7/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> There are two new JSRs for Java EE -
>>
>> http://www.jcp.org/en/jsr/detail?id=317
>>
>> http://www.jcp.org/en/jsr/detail?id=318
>>
>> I plan to vote "no" as Sun is the spec lead.
>>
>> Comments?
>>
>> geir
>>
>>
>>
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> mail: matzew-at-apache-dot-org
Re: JSR-317 and JSR-318 Vote Today
Posted by Matthias Wessendorf <ma...@apache.org>.
just a question.
how would a NO on:
317
effect open_jpa / cayenne ?
thx,
Matthias
On 7/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
>
> Comments?
>
> geir
>
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: JSR-317 and JSR-318 Vote Today
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
We'll probably be alone
On Jul 30, 2007, at 10:29 AM, Henning Schmiedehausen wrote:
> +1 here. Will we be alone on that or is there support from others?
>
> Best regards
> Henning
>
>
>
> On Mon, 2007-07-30 at 10:12 -0400, Geir Magnusson Jr. wrote:
>> There are two new JSRs for Java EE -
>>
>> http://www.jcp.org/en/jsr/detail?id=317
>>
>> http://www.jcp.org/en/jsr/detail?id=318
>>
>> I plan to vote "no" as Sun is the spec lead.
>>
>> Comments?
>>
>> geir
>>
>
>
Re: JSR-317 and JSR-318 Vote Today
Posted by Henning Schmiedehausen <he...@apache.org>.
+1 here. Will we be alone on that or is there support from others?
Best regards
Henning
On Mon, 2007-07-30 at 10:12 -0400, Geir Magnusson Jr. wrote:
> There are two new JSRs for Java EE -
>
> http://www.jcp.org/en/jsr/detail?id=317
>
> http://www.jcp.org/en/jsr/detail?id=318
>
> I plan to vote "no" as Sun is the spec lead.
>
> Comments?
>
> geir
>