Apache Open Letter to Sun, JCK, and how it really affects field of use.

[Wade Chandler <hw...@yahoo.com>]

All,

I'm sorry if this has been asked before, but I have
been reading and reading the emails and still don't
see it exactly. How exactly does the JCK license
impose any restrictions on Harmony end users? With the
Sun JRE for instance, I don't have a JCK or license
for the JCK, yet I can redistribute the runtime. I
obviously don't redistribute the JCK as I have never
had a copy.

I'm not a lawyer. I'm just a member of the Java
community at large and a member of different Java
projects and communities. I have been more active in
the past on Apache mailing lists (mainly AXIS and
Tomcat), have worked on iReport, and different Sun
sponsored projects. Anyways, I'm just having a hard
time understanding how JCK limitations actually affect
end users. I'm not asking for a laymans term version
of the issue, but instead the direct limiting language
or at least a link as I don't think I have a hard time
understanding legal terms and licenses. 

I can't find anywhere anything in a license I have
read which limits the end users of either a build of
tested sources or the RI (harmony RI would be included
in this). I was looking for the JCK, and found where
it can be downloaded, but one has to be a Java partner
to get it. So, I haven't actually read its license.

Again, sorry if it has been asked etc, but the FAQ
doesn't really address this nor does the letter
specifically point me to anything I can read which
shows the limitation and language.

I have only seen in the FAQ:
"To give a concrete example from the Sun / Apache     
  dispute, if Apache accepted Sun's terms, then users
of a standard, tested build of Apache Harmony for
Linux on a standard general purpose x86-based computer
(for example, a Dell desktop) would be prevented from
freely using that software and that hardware in any
application where the computer was placed in an
enclosed cabinet, like an information kiosk at a
shopping mall, or an X-ray machine at an airport."

and I do not understand how the JCK testing affects
redistribution. This seems more like a function of the
license included with the RI of Harmony unless the
intent is to include a JCK with the RI.

If the issue is someone can't take the Apache sources,
fix an actual bug, and then redistribute without
having a JCK and testing then I think having the JCK
license is still a good thing. Otherwise, people could
fix things however they can, possibly breaking some
functionality and then redistribute compromising the
actual compatibility. Otherwise, without TCK testing,
they can embed their build in their software, not call
it "Java" or a JSRXXX impl, and still use it...is this
not correct?

Also, I see many JSRs which say the TCK will not be
more than 50,000 yet do not say they will be free. Is
Apache working towards this going away as well? Is
this part of the JCP changes Apache is working for as
part of this issue? I know I don't have 50,000 to pay
for a TCK from any one or company.

Thanks for helping me understand the issue,

Wade

Re: Apache Open Letter to Sun, JCK, and how it really affects field of use.

[Sam Ruby <ru...@intertwingly.net>]

On 7/10/07, Bill Barker <wb...@wilshire.com> wrote:
>
> or continuing to work within the system,
> where we are making progress.

As of February[1], we were at an impasse on this issue.

As of April, we published an open letter[2].

As of today, three months later, we have no response to that letter.

We are taking patient, deliberate, and measured steps, but our
patience is not infinite.

- Sam Ruby

[1] http://www.apache.org/foundation/records/minutes/2007/board_minutes_2007_02_21.txt

[2] http://www.apache.org/jcp/sunopenletter.html

Re: Apache Open Letter to Sun, JCK, and how it really affects field of use.

[Justin Erenkrantz <ju...@erenkrantz.com>]

On 7/10/07, Bill Barker <wb...@wilshire.com> wrote:
> take the case pro-bono for the publicity.  Since I'm not on legal@, and
> nobody has suggested it here before, I'm guessing that no firm believes we
> have anything remotely looking like a case.  So that leaves us with the

The fact that we haven't discussed our legal options in any public
venue is because we still feel there is hope to resolving this
situation amicably - legal remedies are the absolute last resort.  --
justin

Re: Apache Open Letter to Sun, JCK, and how it really affects field of use.

[Bill Barker <wb...@wilshire.com>]

"Ralph Goers" <Ra...@dslextreme.com> wrote in 
message news:46930824.6020201@dslextreme.com...
> Roy T. Fielding wrote:
>> The JCK license is negotiated on a one-time basis between Sun
>> (the Spec Lead) and whatever entity is requesting access to
>> the TCK.  In our case, the offered license is covered with
>> CONFIDENTIAL marks that make it difficult for us to tell you the
>> exact terms. Feel free to ask Sun for a copy.
>>
>> Suffice it to say that that the JCK license (unlike other TCK
>> licenses we have from Sun) proposed a set of field of use
>> restrictions that would apply to any tested implementation as
>> a restriction on downstream users/redistributors of our software.
>> IMO, those terms violate the reciprocal agreements defined by the
>> Java Specification Participation Agreement that all participants
>> in the JCP must sign.
>>
> Well, since you feel that Sun has violated its agreement the ASF could 
> simply ignore the TCK terms and wait for Sun to file a lawsuit. The ASF 
> could then file a counter-claim for the breach of contract. (If you think 
> I actually believe this is a good strategy, think again).
>

Well, no, since that could potentially shutdown the ASF if we lose in court. 
And it is still dependant on the better strategy of finding a law firm to 
take the case pro-bono for the publicity.  Since I'm not on legal@, and 
nobody has suggested it here before, I'm guessing that no firm believes we 
have anything remotely looking like a case.  So that leaves us with the 
options of withdrawing from the JCP (and sending Geronimo and Tomcat to 
whatever new home they can find), or continuing to work within the system, 
where we are making progress.

>> Sun does not need to worry about Apache.  Sun needs to worry about
>> why Apache cannot participate under those terms, since working
>> against public benefit is not a good strategy for any corporation.
> It certainly hasn't hurt Microsoft.
>
> Ralph
>
> 

Re: Apache Open Letter to Sun, JCK, and how it really affects field of use.

[Ralph Goers <Ra...@dslextreme.com>]

Roy T. Fielding wrote:
> The JCK license is negotiated on a one-time basis between Sun
> (the Spec Lead) and whatever entity is requesting access to
> the TCK.  In our case, the offered license is covered with
> CONFIDENTIAL marks that make it difficult for us to tell you the
> exact terms. Feel free to ask Sun for a copy.
>
> Suffice it to say that that the JCK license (unlike other TCK
> licenses we have from Sun) proposed a set of field of use
> restrictions that would apply to any tested implementation as
> a restriction on downstream users/redistributors of our software.
> IMO, those terms violate the reciprocal agreements defined by the
> Java Specification Participation Agreement that all participants
> in the JCP must sign.
>
Well, since you feel that Sun has violated its agreement the ASF could 
simply ignore the TCK terms and wait for Sun to file a lawsuit. The ASF 
could then file a counter-claim for the breach of contract. (If you 
think I actually believe this is a good strategy, think again).

> Sun does not need to worry about Apache.  Sun needs to worry about
> why Apache cannot participate under those terms, since working
> against public benefit is not a good strategy for any corporation.
It certainly hasn't hurt Microsoft.

Ralph

Re: Apache Open Letter to Sun, JCK, and how it really affects field of use.

["Roy T. Fielding" <fi...@gbiv.com>]

On Jul 9, 2007, at 12:54 PM, Wade Chandler wrote:
> I'm sorry if this has been asked before, but I have
> been reading and reading the emails and still don't
> see it exactly. How exactly does the JCK license
> impose any restrictions on Harmony end users?

The JCK license is negotiated on a one-time basis between Sun
(the Spec Lead) and whatever entity is requesting access to
the TCK.  In our case, the offered license is covered with
CONFIDENTIAL marks that make it difficult for us to tell you the
exact terms. Feel free to ask Sun for a copy.

Suffice it to say that that the JCK license (unlike other TCK
licenses we have from Sun) proposed a set of field of use
restrictions that would apply to any tested implementation as
a restriction on downstream users/redistributors of our software.
IMO, those terms violate the reciprocal agreements defined by the
Java Specification Participation Agreement that all participants
in the JCP must sign.

To understand that, you need to learn a lot about the JCP and
a little about patent law.  The JCP is based on reciprocal license
agreements between all participants and the Spec Lead, in which
the participants license all of their copyright and patent claims
necessary to implement the final JSR specification to the Spec Lead
in return for a guarantee that the Spec Lead will license all of
the collected IP to anyone that implements an independent
implementation of the specification that has been proven to be
compliant with the specification by passing the TCK.

The big loophole in that process was how to prevent the Spec Lead
from placing access restrictions on the TCK such that they can
control who is allowed to receive the collected copyright/patent
licenses by virtue of passing the TCK.  We closed that loophole in
the big dust-up of 2002, wherein the JSPA was modified to prevent
the Spec Lead from imposing terms in the TCK that would prevent
an implementation from being distributed as open source.

FOU restrictions are a limitation on the scope of implementations
for which the Spec Lead is licensing whatever patent claims may be
necessarily infringed by a compliant implementation.  In other words,
whereas the Spec Lead has received patent licenses from all of the
EG participants, the Spec Lead has decided to only give out licenses
to those implementations that are *used* in a particular way or within
a particular context.  In this case, only those implementations that
do not overlap with one of the Spec Lead's commercial enterprises.
Anyone who makes, offers to sell, sells, exports, or uses the same
software within some other context or FOU would therefore be subject
to a patent infringement lawsuit by the Spec Lead, even though they
received the software from us for free.

FOU restrictions violate the open source definition, and thus cannot
be applied to any work under the Apache License.  FOU restrictions on
the TCK violate the reciprocal agreement that is the JSPA, thereby
destroying our benefit from that contract.  It also means the public
benefit of the JCP has been twisted into an artificial monopoly for
Sun.  There's a good chance that Sun's actions are not only a breech
of contract, but change the nature of the JCP to the extent that
participation might be a violation of antitrust laws.

That is why we asked for different terms from Sun and, after being
ignored for six months, asked again in an open letter.  Sun continues
to ignore Apache, continues to violate our contract under the JSPA,
and continues to thumb its nose at the process under with the JCP
was organized and carefully scrutinized for anti-competitive behavior.

A lot of Sun folks are on this list now.  You have to understand
that this is not just an Apache dispute, nor is the end result of any
particular benefit to Apache regardless of the outcome.  It is a
question of whether Rob Gingell's promises to the ASF are going to
be upheld by the current Sun management, whether Sun will allow JSRs
to be implemented as open standards as opposed to monopolies, and
ultimately whether the JCP will continue to exist as a standards
forum or revert to an industry consortium in which large
patent-owning companies collude to restrict competition.

Sun does not need to worry about Apache.  Sun needs to worry about
why Apache cannot participate under those terms, since working
against public benefit is not a good strategy for any corporation.

....Roy