www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron Purdy <cameron.pu...@gmail.com>
Subject Re: TCKs and the ASF
Date Thu, 21 May 2015 02:33:57 GMT
David, all -

The team at Oracle (led by Bill and Lance) has actually been working
diligently on this behind the scenes, and just got me a new internal
version to review a week or so ago. Unfortunately, I've been busy playing
with useless managerial nonsense like spreadsheets and powerpoints, so I
haven't had a chance to review it yet, but our goal was to get an actual
copy of it turned around to Apache to discuss, and hopefully to conclude
our discussion and push it out as a new baseline agreement (e.g. improving
the process for all licensees over time, not just doing this for Apache). I
will try to get some time with them to review and discuss internally, and
hopefully we're very close to pushing something back to you to look at
(that is our goal).

Peace,

Cameron.

On Tue, May 19, 2015 at 2:25 AM, David Blevins <david.blevins@gmail.com>
wrote:

> 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