Re: TCKs and the ASF

[Cameron Purdy <ca...@gmail.com>]

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 <da...@gmail.com>
wrote:

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

Re: TCKs and the ASF

[David Blevins <da...@gmail.com>]

Cameron, it has been a great experience working with you on revising the TCK agreement for the last 2 years.  I think we forged some clever compromises that have the potential to bring both our organizations closer together.  I do hope we can cross the finish line.  To my eyes we are toed up to it.

In the last 2 years, despite some seeing the lack of agreement as ego and trust, we have created some potential compromises I think are incredibly beneficial to Java EE itself.  Realigning enforcement rules to 1) require transparency-by-date rather than compliance-by-date and 2) allow innovation in products that might not yet have the resources to begin implementing the next major version are two critical components that can lead to a better industry.  

For #1 I think compliance-by-date is a lose-lose.  Oracle could never sue someone for being slow to comply without looking like a bully.  Being transparent-by-date is completely enforceable and good motivation for vendors to be quicker.

For #2 Implementations that are short of resources need greater allowance to innovate to stay in the game.  Go ahead and implement that new microservices idea.  As long as you don’t cause compatibility issues by tip-toing into the next spec version without passing the TCK, you’re good and thank you for any innovations that can benefit Java EE.  Again, enforceable and positive.

Lance and Bill, I know you two have worked quite a lot on all of this.  I do look forward to driving this home with you.

The next step is as it was in March, we need a new draft with the above understandings.  I know giving dates is a legal no-no, but please do give some indication we are moving forward.


-David

> On Aug 3, 2015, at 4:42 PM, Cameron Purdy <ca...@gmail.com> wrote:
> 
> 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 <ma...@gmail.com>> wrote:
> month++ :)
> 
> Any update?
> 
> 
> -David
> 
> On Jun 15, 2015, at 5:50 PM, Cameron Purdy <cameron.purdy@gmail.com <ma...@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 <ma...@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 <ma...@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 <ma...@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 <http://mail-archives.apache.org/mod_mbox/www-jcp-open/201404.mbox/browser>
> > >
> > >
> > >
> >
> >
> 
>