www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@gmail.com>
Subject Re: TCKs and the ASF
Date Tue, 19 May 2015 06:25:53 GMT
Moving this thread back to the public for one more attempt at getting the TCK "scholarship
agreement" renewed.  We've all put in a significant amount of time on this and it would be
a shame to let it die.  Better to have discussions end with boolean true or false than a null.


It goes without saying, but must be noted all views in this email are my own.

 - My perception of our status; all major issues have been resolved and now we are missing
that last and final push.

 - My request to Oracle; please send us an agreement with the amendments we've previously
discussed.


I joined this discussion actively in January of 2014.  At that time I heard a lot from Oracle
people saying "Apache isn't responding".  I heard the same thing from Apache people, "Oracle
isn't responding".  With some goodwill, both sides consciously started working together again
and indeed progress has been made.

It has, however, been very slow and conversations died again in January of 2015.  We find
ourselves in another "Apache isn't responding" and "Oracle isn't responding" situation.

In that year of activity both sides made significant progress and broke through some issues
that seemed unresolvable.

Apache had a list of 10 of issues which we posted publicly in April 2014[1].  After some months
of discussion we did receive a draft license in August 2014 from Oracle that addressed some
of the issues.  That draft raised another 2.  Post JavaOne and into the holiday season we
did manage to address the remaining issues including the additional 2.

It appears that the only possible next step forward is a new draft from Oracle.

In the hopes of either resolution or posterity, here is a recap of the issues raised and next
steps.


=----------------------------------------=

 1) Section 2.1(b)(iv) - our need: developing test suites
 3) Section 2.1(c)(i) - our need: snapshot builds
 5) Section 2.1(c)(iii) - our need: announcing builds for testing
 6) Section 2.1(c)(iv) - our need: exemption of non-secure builds
 7) Section 2.1(c) - our need: no unnatural translation requirement
 9) Section 10.8 has a typo -- fixed

Resolved in August 2014 draft license.

No change needed for the next draft.


=----------------------------------------=

 10) Exhibit A is missing a number of the TCKs Apache needs

Deemed easily resolvable.

An updated list of projects from Apache should be enough.  Apache can produce this for Oracle.


=----------------------------------------=

 4) Section 2.1(c)(ii) notice in intermediate builds

Notice is fine, however current language requires the notice to be maintained in redistributions
of those builds.  Without the notice-preservation requirement this section is fine.


=----------------------------------------=

 8) The indemnity clause in Section 7.5 creates potentially massive exposure for ASF

This was a big one for Apache.

In section 7.2, Oracle indemnifies Apache.  In section 7.5, Apache indemnify Oracle.  While
Apache is in no real position to effectively indemnify Oracle, the intended mutual protection
of those two clauses is obvious.  Internal discussion does not lead me to believe this is
a showstopper.  It appears people are willing to give a little here.  The good faith should
not go unnoticed.

No modification necessary in the next draft.


=----------------------------------------=

 2) Sections 2.1(b)(v) and 2.1(d) perpetual and forced upgrade

This was the biggest one for us all and the seminal issue for ever hoping to resolve matters
with the TCK license agreement.


The long and short of this is that all Apache projects would be legally:

 - not allowed to ship updated* releases of software passing a previous version of a TCK

 - required to implement the newest version of the TCK for any updated* release within N days
of TCK.next availability

 - required to stop shipping any updated* releases of all software targeting previous TCK
versions after N days of TCK.next availability

I put the word update with an asterisk as initial attempts at resolving this involved spelling
out what can be updated and what cannot be updated.  The August 2014 draft allowed bug fixes
to be done, but no enhancements or new features -- JavaEE-related or not -- to be added to
any software that didn't implement and pass the latest version of the respective TCK.

Even with the August 2014 draft license there would be would a few ramifications to Apache's
day-to-day business.

Active Projects: some projects, such as Tomcat, maintain more than one active branch due to
the large number of users and frequently back port new features from the most current version
to the previous to better support the community.  This practice would become illegal and releases
Tomcat 7.x (Servlet 3.0) not allowed N days after the release of Servlet 3.1, at which time
only Tomcat 8 would be allowed to ship enhancements or new features.  Users would have to
upgrade from Tomcat 7 and migrate to Tomcat 8 to get any enhancements for Tomcat, Java EE
related or otherwise.

Struggling Projects: some projects at Apache occasionally lose resources, such as OpenJPA,
making it hard to implement the latest TCK version.  This would mean OpenJPA trunk (2.4.0),
which contains enhancements, could never be released without breaking contract despite it
not being targeted to JPA 2.1 and still maintaining complete compliance with JPA 2.0.  Many
in OpenJPA still hope to implement JPA 2.1, however restrictions on its JPA 2.0 codebase do
not help it bolster its numbers and regain health.

Inactive Projects: some projects, such as Geronimo, drop off completely.  The last commit
to Geronimo trunk was 2 years and 2 months ago.  This as well would count as breaking contact
as language explicitly requires licensees to producing a compliant version within a set period
of time.


Primary concerns on Oracle's side included (my own paraphrasing and interpretation):

 - Ensuring projects completely and compliantly implement the specifications they say they
implement

 - Ensuring projects stay current with the latest version of their respective specification

These concerns were justified and did take some discussion to work through.  An ask from some
projects in Apache did include wanting the TCK license agreement to bless allowing the project
to implement only selected parts of their respective JSRs.  Effectively only partial compliance.
 There are situations that can justify not wanting to implement a particularly bad part of
a JSR, especially portions which contain large legacy compliance requirements.  While this
concern is valid, consensus was reached that 1) the JCP itself is the best place to address
this, 2) there is precedent of specifications making legacy features optional, and 3) there
is no way to give licensees this choice in a legal document without jeopardizing the basic
notion of standards and compliance.


Essentially, the concerns of each organization boil down to two realistic "Nuclear" concerns:

 - Destruction of the Java EE brand from implementations that fail to do the above two but
poison the market by claiming compliance

 - Destruction of Apache from lawsuit over legal requirements that are unrealistic for a volunteer
organization or anti-open-source in nature

After several months of being stuck in the minutia, scaling back to the big picture "Nuclear"
concerns and focusing there revealed a compromise that not only addressed each other's biggest
concern but appears to help each other achieve them better.


The path forward appears as follows:

1) Instead of requiring a project to upgrade to the latest release of a specification N number
of days after it's available we allow a project to continue to release without adopting "the
latest spec release" provided:

  a) there is clear indication to users if the project has not moved to the latest release


  b) there is transparency on the intent of the project to eventually move to the latest release

2) If a project DOES intend to implement the next version of the specification, it must adopt
the whole thing.

  a) No "partial compatibility" is allowed. Projects can not pick the pieces of a new spec
that they like unless they're willing to do the work to pass compatibility on the whole thing.

  b) No final release can be made till the project passes the TCK completely.

3) If a project DOES NOT intend to implement the next version of the specification, notices
must be made to the community in download pages, readmes, etc.

  a) After 120 days of a specification release by the JCP, new releases of the project that
do not implement the latest version of the specification must clearly state (e.g. download
page, readme, etc.) both what version the project supports and what version the latest spec
is to clearly show that the project is shipping an older version of the specification.

  b) After 365 days of a specification release by the JCP, new releases of the project that
do not implement the latest version of the specification must prominently warn (e.g. download
page, readme, etc.) that the release is shipping an older version of the spec support:

    iii) the warning must include a declaration of whether the project has real intention
to support the updated spec in the future. ("prominent" = significant emphasis i.e. big, red,
bold and maybe even add the deprecated <flash> tag; "warn" = literally, it's a warning,
as in it literally needs to say "Warning!!!") 


The concept is simple: transparency.

It forces implementations to be transparent about their status.  It must advertise its intentions
to its users and let them make an informed decision.

If one day Tomcat stops implementing Servlets and wants to continue as a project, it can do
so, but not quietly.  The news sites would cover it and it would go viral.  No quietly backing
away or hiding.

The potential of 3.b.iii in particular has great power to clear waters that can currently
be muddy; which vendors are still in the game and which are out.

=----------------------------------------=



The above is our status to my count.  We're close.

We're not just close, but I truly believe we're forging a better path than what previously
existed.  It's not just good for Apache or Oracle, but good for the industry.

I ask everyone to return to the table and finish our work.


-David


[1] http://mail-archives.apache.org/mod_mbox/www-jcp-open/201404.mbox/browser



Mime
View raw message