www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: JSR-317 and JSR-318 Vote Today
Date Wed, 01 Aug 2007 04:30:10 GMT
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

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


--- "Andrew C. Oliver" <acoliver@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.

View raw message