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 Mon, 03 Aug 2015 23:42:21 GMT
David - Unfortunately, I was not able to push this through while I was
still at Oracle. (I was fired this morning.) However, Bill and Lance know
the goals and the plot, and they still have the same approval process to go
through, which might even be easier now since I will not be the one asking
for it ;-)

I am sorry to have let you down in terms of bringing this to a successful
conclusion. As you may be able to imagine now, I have had my hands full
with some other pressing issues.

Peace,

Cameron.

On Thu, Jul 16, 2015 at 11:15 AM, David Blevins <david.blevins@gmail.com>
wrote:

> month++ :)
>
> Any update?
>
>
> -David
>
> On Jun 15, 2015, at 5:50 PM, 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