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, 16 Jun 2015 09:11:47 GMT
Looking forward to the new draft and agree that something we can evaluate and discuss is key
at this point.

Thanks for the update, Cameron.


-David

On Jun 16, 2015, at 1:50 AM, Cameron Purdy <cameron.purdy@gmail.com> wrote:

> Brief update: Several of us reviewed the proposed changes with two of our lawyers today
who have been helping with this process, and we identified a small number of remaining items
that need to be cleaned up before we can circulate this draft. My intention is to get permission
from our lawyers and from my management to share the draft publicly for purposes of discussion,
in order that the concerns raised previously by various parties can be evaluated against the
draft. If draft appears to be suitably close (which definition of "suitable" will naturally
vary from one person's perspective to the next), then we can begin the process of internal
approvals that will be necessary to adopt this as our new standard TCK license agreement (as
opposed to the use of "side letters"). I apologize for the delays inherent to this process
(and perhaps inherent to me), and I would like to thank Bill and Lance for their continued
diligence in driving this towards completion. With fingers crossed ...
> 
> On Wed, May 20, 2015 at 10:59 PM, David Blevins <david.blevins@gmail.com> wrote:
> Many thanks, Cameron, Bill and Lance.
> 
> Very much looking forward to the new draft.
> 
> 
> -David
> 
> 
> On May 20, 2015, at 7:33 PM, Cameron Purdy <cameron.purdy@gmail.com> wrote:
> 
> > 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