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: [VOTE] New ASF/JCP Policies
Date Thu, 12 Jul 2007 05:07:17 GMT
--- Joe Schaefer <joe+apache@sunstarsys.com> wrote:
> Wade Chandler <hwadechandler-apache@yahoo.com>
> writes:
> 
> > --- Joe Schaefer <joe+apache@sunstarsys.com>
> wrote:
> 
> [...]
> 
> >> If someone's willing and able to successfully
> >> violate the old contract, you can't fix that
> >> situation by offering them a new one with more
> >> favorable terms. 
> >
> > This is part of the problem though. The rules are
> not
> > very specific as to license conditions of the TCK.
> 
> They don't have to be specific, IMO, when there is a
> 
> general prohibition in section 5C of the JSPA
> (emphasis mine):
> 
>   "Other than as set forth above, the Spec Lead
> agrees not
>    to impose *any contractual condition* or covenant
> that
>    would limit or restrict the right of any licensee
> to create
>    or distribute such Independent Implementations."
> 
> The FOU restrictions deny us the right to distribute
> an
> Independent Implementation of JSR 176 under the
> Apache License.
> Were we to accept the FOU restrictions, we'd be
> responsible
> for enforcing them, which means that we'd be
> offering harmony
> to users under a discriminatory contract, not the AL
> 2.0.  
> That simply won't fly here, nor will it fly over the
> rest
> of the open source distribution network.
> 

Yes, after re-reading the JSPA being sure to read this
particular paragraph I agree. I think no matter where
the license is (such as in the TCK) if it is
prohibitive on the Independent Implementation (II) in
any regard if the II meets the 3 terms:
(a) fully implement the Spec(s) including all its
required interfaces and functionality;
(b) do not modify, subset, superset or otherwise
extend the Licensor Name Space, or
include any public or protected packages, classes,
Java interfaces, fields or methods within the Licensor
Name Space other than those required/authorized by the
Spec or Specs being implemented; and
(c) pass the TCK for such Spec.

then it violates the JSPA. 

I haven't seen the text at issue, but if it does
indeed limit distribution or any terms the licensee
may have on their end II, then it is certainly
violating the legal and binding agreement which is the
JSPA. So, I think if there is a definite limitation
then there is certainly a case which can be made even
in a court of law if it happens to be the only course
of action as the legally binding agreement is in
breach. Although, the courts are not community build,
neither is breaking a legal agreement nor a verbal or
written agreement in my mind.

Looking at the JCP2 this jumps out:
"1.2.1 EARLY WARNING AND FEEDBACK ON LICENSING TERMS
FOR THE RI AND TCK

The Spec Lead's company or organization is responsible
for the Reference Implementation (RI) and Technology
Compatibility Kit (TCK) and its licensing under terms
compatible with the licensing guidelines established
for use within the JCP. The Spec Lead will provide the
EC with the terms under which the RI and TCK will be
licensed no later than the start of JSR Review. EC
members will provide feedback on the terms as an
indication of how the community might react as a whole
to the terms. "

and

"2.2.1 CONFIRMATION OF LICENSING TERMS FOR RI AND TCK

The Spec Lead's company or organization is responsible
for the Reference Implementation (RI) and Technology
Compatibility Kit (TCK) and its licensing under terms
compatible with the licensing guidelines established
for use within the JCP. The Spec Lead will provide the
EC with confirmation of the terms under which the RI
and TCK will be licensed at each review period. EC
members will provide feedback on the terms as an
indication of how the community might react as a whole
to the terms. "

Did this take place? Are the licensing terms different
than what was reviewed? This sounds like another
possible issue.

Another route is it looks as if a JSR could be forced
into maintenance and it handed over to another party,
albeit not guaranteed to be fast, according to (JCP2):

" 1.1.1 REVISE EXISTING SPECIFICATIONS

Existing Specifications, along with their associated
RIs and TCKs, are maintained by a designated
Maintenance Lead using the processes described in
section 4 of this document. Maintenance Leads (and
their host companies or organizations) are expected to
assume long term ownership of their Specifications,
RIs, and TCKs with due respect of the will of the Java
Community Members with regard to evolution. This means
that Maintenance Leads will automatically be the Spec
Leads for all significant revisions to their
Specifications going forward but they will not have
the exclusive right to decide when a significant
revision will take place. That will be decided by the
EC in response to a revision JSR that can be initiated
by any Java Community Member (or Members). The only
provision is that the submitter(s) should make a
reasonable effort to get some of the members of the
previous Expert Group to join the revision effort. "

" 2.1.3 UNCOOPERATIVE OR UNRESPONSIVE EXPERT GROUP
MEMBERS

There may be rare instances when members of the Expert
Group feel that one of their fellow Experts is not
acting in ways that advance the work of the Expert
Group. These concerns should be brought to the
attention of the Spec Lead and/or the EC as quickly as
possible so they may be proactively addressed and
resolved. The Expert Group members are expected to
make a reasonable effort to resolve any such issues
among themselves. If a 2/3 majority of the members of
the Expert Group find that a Spec Lead is being
unresponsive, and the Spec Lead does not work to
resolve the situation in a timely manner, the EC may
direct the PMO to ask the Member who provided the Spec
Lead to provide a replacement. "

"4. MAINTENANCE
4.1 KEEP THE SPECIFICATION UP TO DATE

    definition - Maintenance Lead (ML) : The Expert
responsible for maintaining the Specification. 

The Maintenance Lead is responsible for carrying out
maintenance on the Specification and dealing with
errata by fielding requests for clarification,
interpretation, and enhancements to the Specification
from both Members and the public via an e-mail address
listed in the Specification. The ML will consider all
requests and will decide how and if the Specification
should be updated in response. The ML will typically
be the Spec Lead from the Expert Group that developed
the Specification. The ML is not required to do all
these tasks alone. The ML may find it very helpful to
recruit members of the Expert Group that helped to
develop the Specification to assist with the
Maintenance duties.
4.1.1 THE MAINTENANCE LEAD MAKES A LONG TERM
COMMITMENT

The Maintenance Lead (and his or her host company or
organization) is expected to assume long term
ownership of the Specification, RI, and TCK with due
respect of the will of the Java Community Members with
regard to evolution. This means that a Maintenance
Lead will automatically be the Spec Lead for all
significant revisions to their Specification going
forward but he or she will not have the exclusive
right to decide when a significant revision will take
place (see section 1.1.1).
4.1.2 RELINQUISHING OWNERSHIP

    definition - Dormant Specification (Dormant) : A
Specification that does not have an identified
Maintenance Lead. All Specifications become Dormant at
the end of their life cycles. 

    definition - Transfer Ballot: The EC ballot to
approve transfer of ownership of a Specification, RI,
and TCK from one Member to another Member. 

If the ML decides to discontinue his or her work for
whatever reason (including discontinuing maintenance
activities or declining to take on the role of Spec
Lead during a significant revision initiated by a JSR)
the ML should make a reasonable effort to locate
another Member who is willing to take on the task. If
the ML fails to find a replacement, the PMO will
declare the Specification to be Dormant. No further
maintenance will be carried out on it until a new ML
is identified and ownership of the Specification, RI,
and TCK is transferred to the new ML's organization
(subject to a successful Transfer ballot by the EC). "

which states a JSR is Dormant at the end of their life
cycles. So, any organization can ask for clarity,
enhancements, and interpretation. If the ML is not
responsive then that person can be replaced and at
least get a new audience if even in the same company.
If then the company finally decides not to participate
in the maintenance if an ML will not be appointed then
a transfer ballot will have to be given. As it is not
specific as to what exactly maintenance is, a revision
JSR should be able to be created to examine and
reaffirm RI and TCK licensing agreements. This
wouldn't be exactly community building, but neither is
not responding nor court action. 

This seems like a plan of action which could work
without Apache pulling away from the JCP process in
any way and tests the JCP. The JCP processes don't
seem to mention these after the fact type issues and
doesn't seem to give the EC power to act on them which
seems like something which needs to be addressed for
the overall processes as well.

Wade

Mime
View raw message