You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcp-open@apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2007/07/01 00:22:05 UTC
Re: [Draft] New ASF/JCP Policies
On Jun 30, 2007, at 9:57 AM, Sam Ruby wrote:
> On 6/29/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> On Jun 29, 2007, at 9:57 PM, Sam Ruby wrote:
>>
>> > On 6/29/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >>
>> >> On Jun 27, 2007, at 6:57 AM, Matt Hogstrom wrote:
>> >>
>> >> > Are we going too far to the other side of the pendulum?
>> >>
>> >> I'm not sure. I've been thinking about this for a while, and I'd
>> >> like to offer the following "extreme" position :
>> >>
>> >> Why not just decide to only use TCKs that have no NDA?
>> >
>> > Do me a favor. Mark up the existing policies to the way you would
>> > like to see them (much like I did(*)), and we can vote on that.
>>
>> Sure. While I do that, what do you think?
>
> I think I would rather wait until I see what that means in operational
> terms, i.e., as a marked up version of our policies.
Aka "Fetch me a Rock"? :)
I'm asking a really simple question here trying to drive to some
consensus, since operational terms for your suggested changes are
only implied as well. Actually, re-reading my sentence, it needs an
extra word at the end, like "requirement") so that it would be
Why not just decide to only use TCKs that have no NDA requirement?
Yes, there are operational details there (do we just push everything
overboard now, or do we let some grace period happen?), but I think
we should all discuss.
Anyway, whether or not you choose to answer, I reread your suggested
modifications and think that it tangles a few issues. If we do
believe in the principles behind your suggestions, they should be up-
leveled so that there's a general ASF policy that our JCP
participation is compliant with.
For example, your suggested changes state we won't ask for a TCK
unless the EG that created the spec we're implementing :
" * Operate in an open, transparent manner in the same way that
our Apache community lists work
* Use consensus and/or voting for decision making
* License their specifications to allow royalty-free
implementations under an open source license and
* License their Reference Implementations (RIs) and Technology
Compatibility Kits (TCKs) in a manner that neither requires an NDA
for access, nor imposes restrictions that would preclude
implementation of the original JSR under open source licenses. In
particular, the license for the TCK may not impose FOU requirements
on implementations.
"
(There's a big problem with the last bullet - why are we telling
others how to license their software, the RI? - but lets not get
distracted...)
Inherent in the above is a statement that we won't implement a JSR
unless it follows the above rules. Why only JSRs? Why not have a
standard policy about any spec we implement? The TCK is a "side-
effect" or "burden" of implementation of a JCP spec, so a "no NDA"
policy actually solves the problem at hand. The above points re the
spec creation is a second thing entirely.
So why we don't cut to the core in what you are suggesting - there
are two policies there, that should be kept separate.
1) We won't use TCKs that require NDAs.
2) We won't implement standards that don't comply with the above rules.
If we don't have a rule #2, then I can still implement JSRs that
don't comply with the 4 rules (except for a handful, they all don't,
to some degree) if the TCK is available to us on terms that don't
require NDA.
Comments?
geir
Re: [Draft] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 2, 2007, at 11:47 PM, Justin Erenkrantz wrote:
> On 7/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> Either we believe in the principle or we don't. Communities
>> shouldn't be able to vote around what we deem policy.
>
> But, those communities can walk out the door and go set up shop at
> Glassfish or somewhere else. I'd hope to educate the communities
> first on why it's in the project's interests to follow these policies
> (whatever they are) - but if they disagreed with whatever policy we
> collectively decide upon, then our committers have the right to go
> elsewhere.
I think you'd have an interesting time explaining how the project's
interests would be better served, since getting these TCKs, even
under these terms, is what attracted many here (we help them work on
an equal basis to commercial implementations) and they seem to do
fine as is (modulo the PITA nature of the program).
> We can't force them to stay here if they don't want to.
> Our governance model does try to give all of our stakeholders a voice
> in the process - so they *should* feel empowered and that their input
> is welcome - but we might just end up pissing some parts of our own
> community if we take a harder line then we have in the past. And, on
> balance, if the overall policy is the right thing for us to take due
> to our charter, then I'm content to let the projects fall where they
> may. -- justin
Me too.
That said, I can easily argue the pragmatic side of simply holding
our nose and continuing. (I argued that for years - I'll well
rehearsed)
geir
Re: [Draft] New ASF/JCP Policies
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/2/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Either we believe in the principle or we don't. Communities
> shouldn't be able to vote around what we deem policy.
But, those communities can walk out the door and go set up shop at
Glassfish or somewhere else. I'd hope to educate the communities
first on why it's in the project's interests to follow these policies
(whatever they are) - but if they disagreed with whatever policy we
collectively decide upon, then our committers have the right to go
elsewhere. We can't force them to stay here if they don't want to.
Our governance model does try to give all of our stakeholders a voice
in the process - so they *should* feel empowered and that their input
is welcome - but we might just end up pissing some parts of our own
community if we take a harder line then we have in the past. And, on
balance, if the overall policy is the right thing for us to take due
to our charter, then I'm content to let the projects fall where they
may. -- justin
Re: [Draft] New ASF/JCP Policies
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Jul 2, 2007, at 11:33 PM, Geir Magnusson Jr. wrote:
> Either we believe in the principle or we don't. Communities
> shouldn't be able to vote around what we deem policy.
I wasn't clear I think. I meant that projects that have been
shipping certified versions and have access to the NDA materials may
decide to align with the ASF policy and not be grandfathered in. It
would be a show of support and not a circumvention. Sorry for the
confusion.
Re: [Draft] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 2, 2007, at 11:19 PM, Matt Hogstrom wrote:
>
> Onto the section about testing with a TCK. Perhaps it does not
> need to be brought up in this document but I think all projects
> that are working on implementations that fall under the old rules
> should have discussion and possibly a vote if they choose to
> continue under the old policies or decide to not certify future
> releases which makes the possibilities for some projects
> interesting going forward.
Either we believe in the principle or we don't. Communities
shouldn't be able to vote around what we deem policy.
Communities already can decide not to use a TCK because of NDA
reasons, but to my knowledge, none have, principles notwithstanding I
guess.
Lets stop beating around the bush - a "no NDA" policy would do quite
a bit of damage to any project where building a certified
implementation of a JSR is a core mission.
>
> We should consider that some projects may wish to work somewhere
> else (where I have no idea) if they feel their implementations
> benefit from being certified despite the encumbrance of more
> restrictive licenses.
Such communities are free to leave already. Getting free TCKs via
the ASF is a big attractor. This doesn't mean we'll stop with TCKs.
It just means we only use TCKs that have no NDA requirements.
> My even asking this question might cause one to think I'm
> referring to my personal interest in Apache Geronimo and please be
> assured I am not.
It never crossed my mind. Really. Not once.
> I am merely thinking through ramifications for any project that
> has a stake in the JSR's that have crummy license terms.
>
> This is a good discussion and a turning point for many ... this is
> what tests whether we choose to live by our principles.
Well, maybe. I'd argue that while this is a good thing, lets not
overstate how solid these "principles" are. I think our communities
have gotten quite a bit of benefit from being unprincipled :)
geir
>
>
> On Jul 2, 2007, at 1:57 PM, Justin Erenkrantz wrote:
>
>>> So then what is the policy right now?
>>
>> We don't know as we're still deciding how we want to revise it. =)
>>
>> Currently, we adhere to:
>>
>> http://www.apache.org/jcp/
>>
>> (which just says that we encourage the principles be followed)
>>
>> but a proposal being discussed is:
>>
>> http://people.apache.org/~rubys/jcp.html
>>
>> (which says that we require the principles be followed)
>
Re: [Draft] New ASF/JCP Policies
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I've caught up with the discussion and would like to throw in my two
cents on Sam's proposed changes.
From Sam's changes on representation:
***
2) Representation
Apache community members represent the ASF on various expert groups.
Our goal is to bring our interests in openness, meritocracy and
community to the expert groups we work on. While we will continue to
participate in existing working groups, we will no longer add
participants to new or existing working groups, nor will we request
access to TCKs for any given JSR produced by any working group,
unless those working groups:
* Operate in an open, transparent manner in the same way that
our Apache community lists work
* Use consensus and/or voting for decision making
* License their specifications to allow royalty-free
implementations under an open source license and
* License their Reference Implementations (RIs) and Technology
Compatibility Kits (TCKs) in a manner that neither requires an NDA
for access, nor imposes restrictions that would preclude
implementation of the original JSR under open source licenses. In
particular, the license for the TCK may not impose FOU requirements
on implementations.
***
I would reword as:
2) Representation
Apache community members represent the ASF on various expert groups.
Our goal is to bring our interests in openness, meritocracy and
community to the expert groups we work on. To be consistent with our
goals and principle's the ASF will participate in JSRs that:
* Operate in an open, transparent manner consistent with Apache
community lists
* Use consensus and/or voting for decision making
* License their specifications to allow royalty-free
implementations under an open source license and
* License their Reference Implementations (RIs) and Technology
Compatibility Kits (TCKs) in a manner that neither requires an NDA
for access, nor imposes restrictions that would preclude
implementation of the original JSR under open source licenses or
restrictions on the implementations use.
***
It's basically the same thought but put in a positive light rather
than why we won't participate, here is where we will. Also, I
reworded the FOU and broadened it to use. IANAL but I prefer not
being too specific as there will undoubtedly be other restrictions in
the future.
Onto the section about testing with a TCK. Perhaps it does not need
to be brought up in this document but I think all projects that are
working on implementations that fall under the old rules should have
discussion and possibly a vote if they choose to continue under the
old policies or decide to not certify future releases which makes the
possibilities for some projects interesting going forward.
We should consider that some projects may wish to work somewhere else
(where I have no idea) if they feel their implementations benefit
from being certified despite the encumbrance of more restrictive
licenses. My even asking this question might cause one to think I'm
referring to my personal interest in Apache Geronimo and please be
assured I am not. I am merely thinking through ramifications for any
project that has a stake in the JSR's that have crummy license terms.
This is a good discussion and a turning point for many ... this is
what tests whether we choose to live by our principles.
On Jul 2, 2007, at 1:57 PM, Justin Erenkrantz wrote:
>> So then what is the policy right now?
>
> We don't know as we're still deciding how we want to revise it. =)
>
> Currently, we adhere to:
>
> http://www.apache.org/jcp/
>
> (which just says that we encourage the principles be followed)
>
> but a proposal being discussed is:
>
> http://people.apache.org/~rubys/jcp.html
>
> (which says that we require the principles be followed)
Re: [Draft] New ASF/JCP Policies
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/2/07, Jeff Genender <jg...@apache.org> wrote:
> Justin Erenkrantz wrote:
> > Specifically as the ASF is a voting member of the JCP EC, we also have
> > an obligation for all of our votes to be consistent with our policies.
>
> So then what is the policy right now?
We don't know as we're still deciding how we want to revise it. =)
Currently, we adhere to:
http://www.apache.org/jcp/
(which just says that we encourage the principles be followed)
but a proposal being discussed is:
http://people.apache.org/~rubys/jcp.html
(which says that we require the principles be followed)
Hence, that's why abstaining is how I'd lean if I were casting the
vote and without any more context about what this vote means. --
justin
Re: [Draft] New ASF/JCP Policies
Posted by Jeff Genender <jg...@apache.org>.
Justin Erenkrantz wrote:
> Specifically as the ASF is a voting member of the JCP EC, we also have
> an obligation for all of our votes to be consistent with our policies.
So then what is the policy right now?
Jeff
> -- justin
Re: [Draft] New ASF/JCP Policies
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> YES. If they want "ASF, Member, Foo Spec Expert Group" they absolutely
> must have an open spec development process. That's different from our
> creating implementations.
>
> And I mentioned before - as members wearing any hat other than your ASF
> one, participate all you like across the open and closed universes.
>
> It's only if you sign off "Joe Smith, ASF" that you need to follow any
> ASF-policy.
Specifically as the ASF is a voting member of the JCP EC, we also have
an obligation for all of our votes to be consistent with our policies.
-- justin
Re: [Draft] New ASF/JCP Policies
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sam Ruby wrote:
>
> The ASF implements a number of specifications. And many of us wear
> multiple hats. As implementors, I fully agree with both the sentence
> I excerpted and the full post you made.
>
> But we wear multiple hats. If you look at http://www.apache.org/jcp/,
> you will see that it spells out the conditions upon which we will
> actively participate, or lend our good name if you prefer, in the
> actual DEVELOPMENT of standards themselves.
>
> I claim that when we participate, not as individuals, or as
> representatives of our respective employers, but in the development of
> standards as representatives of the Apache Software Foundation, then
> we care about a bit more.
YES. If they want "ASF, Member, Foo Spec Expert Group" they absolutely
must have an open spec development process. That's different from our
creating implementations.
And I mentioned before - as members wearing any hat other than your ASF
one, participate all you like across the open and closed universes.
It's only if you sign off "Joe Smith, ASF" that you need to follow any
ASF-policy.
Bill
Re: [Draft] New ASF/JCP Policies
Posted by Sam Ruby <ru...@apache.org>.
On 7/2/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Mark Thomas wrote:
> >
> > I am concerned that we are in danger of cutting off our nose to spite
> > our face here.
> >
> > I see three categories of standard body:
> > a) Operates in an open Apache-like manner
> > b) Is not open (NDAs on TCKs, closed EG lists etc) but does nothing that
> > prevents us releasing implementations of the spec under AL2
> > c) Operates in a way (eg FOU restriction on TCK) that prevents us
> > releasing implementations of the spec under AL2
> >
> > My main cause of concern is that the Servlet expert groups fall under b)
> > since an NDA is required for the Servlet TCK.
>
> How does requiring an NDA from the developers NOT prevent us from releasing
> under AL2, when the source code is not authoritatively validated? (Only the
> resulting binaries/.jar's from what I understand). We've twisted ourselves
> with anti-Apache-way practices just to work around this issue.
>
> Let's clarify. I don't *care* if the EG list is closed. I don't care if
> a spec is written entirely by one person developed privately in their own
> head, provided that it is a spec worth implementing to some developers here
> at the ASF. Specs are only that, reference documents.
>
> The only thing we care about is the openness of the implementation, and that
> the reference document it is produced from is also open. (This is true even
> when a reference must be reverse engineered from a closed implementation.
> Still, we have an open document at the end of the day, even if it's from the
> other side of the Chinese Wall.)
>
> Consider how many http: validators there are, many in closed source. We can
> (and certainly do) implement RFC2616 without the benefit of such products.
>
> There are actually two ways around this. We don't care if a TCK/test suite
> is closed source/NDA, even when it's considered the reference test. We do
> care, however, that we cannot label our code as an implementation until
> it passes a closed source/NDA suite.
>
> So, if a JSR either spell out that the closed/NDA suites are reference, but
> not the sole authoritative test of compliance, or ... spell out the reference
> test - which is authoritative - must not be subject to NDA. (I don't know
> that we care if we can or cannot republish it. We only care, I believe,
> that the ASF committer can obtain and use that test without additional burdens
> or liabilities.)
>
> We keep speaking of TCKs in black and white; I think it will help the JCP and
> ourselves to be clear about -what- our objections are, and that there are more
> than one solution to clear up this problem.
I couldn't figure out how best to excerpt your statement without
removing context, so I did not; but I want to focus on one statement
"The only thing we care about is the openness of the implementation,
and that the reference document it is produced from is also open."
The ASF implements a number of specifications. And many of us wear
multiple hats. As implementors, I fully agree with both the sentence
I excerpted and the full post you made.
But we wear multiple hats. If you look at http://www.apache.org/jcp/,
you will see that it spells out the conditions upon which we will
actively participate, or lend our good name if you prefer, in the
actual DEVELOPMENT of standards themselves.
I claim that when we participate, not as individuals, or as
representatives of our respective employers, but in the development of
standards as representatives of the Apache Software Foundation, then
we care about a bit more.
- Sam Ruby
Re: [Draft] New ASF/JCP Policies
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 7/1/07, Sam Ruby <ru...@apache.org> wrote:
> > 1) No NDAs can be required for participation in ASF activities. I'm
> > not sure how we'll ever be able to meaningfully require private@ and
> > members@ list to be under an NDA, but I expect that inconvenient
> > observation will be mooted via adding "technical" as a qualifier for
> > "ASF activities". This solves the NDA for TCK issue.
>
> +1
+1.
> > 2) The ASF won't participate in activities that aren't "run like an
> > Apache project". This solves the EG issue.
>
> +1
+1.
> > 3) The ASF won't implement specifications that weren't created in a
> > manner similar to "an Apache project". I'm not sure if we want this,
> > but to me it clearly falls out of your proposal, so I think that you
> > want this too.
+1.
> I don't believe it clearly falls out of my proposal, but I would
> support a proposal that removes my addition of "nor will we request
> access to TCKs for any given JSR produced by any working group," from
> the "Representation" section; and adds a new section that concerns
> itself with the conditions under which the ASF will formally request
> access to a TCK. This new section would essentially repeat the final
> bullet in the "Representation" section.
>
> This should completely decouple the two issues, no?
I'm not quite sure if it truly decouples it, but I'll play along.
> > If you want operational specifics to get have a meaningful action for
> > the TCK/NDA issue, I'd suggest :
> >
> > 1) We announce that we no longer accept NDAs and will allow existing
> > under-NDA TCK usage for 1 release.
>
> +1
Does that mean 1 release of the JSR specification? Or does that mean
one ASF release?
Either way a little bit of wiggle room is okay by me. So +1 to either
interpretation.
> > 2) We make a public request to Sun that they formally drop any NDA
> > requirements around our TCK usage. If they agree, we open things
> > up. If they don't, we just shut it down.
>
> -1 (of the non-veto variety)
>
> s/Sun/all affected expert groups/
>
> s/shut it down/cease ASF representation in the expert groups that don't comply/
+1 to those modifications to Geir's suggestion.
Do note that it'd also bar projects from implementing the specs that
are created in such a manner - since we signed the JSPA, we can't
release unless we first pass the TCK. But, if our policies prohibit
us from accepting the TCK, we can't do a release.
> Even with these changes, I'm not a fan of making this particular
> change retroactive, but if the majority feels that this should be
> done, I won't stand in the way.
I think if we mean it, we should make it retroactive. But, I'll
follow the majority as well - though placing a cap of 1 release (be it
the spec or our release) is a reasonable compromise that doesn't allow
us to bring everything to a halt... -- justin
Re: [Draft] New ASF/JCP Policies
Posted by Jeff Genender <jg...@apache.org>.
Joe Schaefer wrote:
> IMO an NDA should only be required if the author believes that
> the sofware in question contains trade secrets. To me that would
> seem to imply that we have access to the TCK's source, because I
> can't see anything particularly novel about a binary-only TCK.
>
We do have access to the source. We use it when debugging when running
against the TCK.
Jeff
Re: [Draft] New ASF/JCP Policies
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Geir Magnusson Jr." <ge...@pobox.com> writes:
> How can you agree to not republish if there are no additional burdens or
> liabilities when obtaining said thing we can't republish?
You have it backwards- republishing someone else's copyrighted works
is a *capability* granted by certain licenses. Not all licenses
grant the capability, and certainly that shouldn't be a requirement
we impose on a TCK licensed to the ASF.
IMO an NDA should only be required if the author believes that
the sofware in question contains trade secrets. To me that would
seem to imply that we have access to the TCK's source, because I
can't see anything particularly novel about a binary-only TCK.
--
Joe Schaefer
Re: [Draft] New ASF/JCP Policies
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
FWIW - this wasn't strictly the JCP-side of the policy, but ASF-wide.
Granted in JCP-terms, there is one TCK. Other standards bodies will
define things differently.
Bill
Geir Magnusson Jr. wrote:
>
> On Jul 2, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
>
>>
>> There are actually two ways around this. We don't care if a TCK/test
>> suite
>> is closed source/NDA, even when it's considered the reference test.
>> We do
>> care, however, that we cannot label our code as an implementation until
>> it passes a closed source/NDA suite.
>
> 1) Drop the bit about "closed source" for the test kit. That's irrelevant.
>
> 2) You can't call it complete or compatible w/o passing the test suite.
>
>>
>> So, if a JSR either spell out that the closed/NDA suites are
>> reference, but
>> not the sole authoritative test of compliance, or ... spell out the
>> reference
>> test - which is authoritative - must not be subject to NDA.
>
> The EG has to deliver the sole authoritative test - there only is one.
>
>> (I don't know
>> that we care if we can or cannot republish it. We only care, I believe,
>> that the ASF committer can obtain and use that test without additional
>> burdens
>> or liabilities.)
>
> How can you agree to not republish if there are no additional burdens or
> liabilities when obtaining said thing we can't republish?
>
> geir
>
>
>
Re: [Draft] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 2, 2007, at 1:10 PM, William A. Rowe, Jr. wrote:
>
> There are actually two ways around this. We don't care if a TCK/
> test suite
> is closed source/NDA, even when it's considered the reference
> test. We do
> care, however, that we cannot label our code as an implementation
> until
> it passes a closed source/NDA suite.
1) Drop the bit about "closed source" for the test kit. That's
irrelevant.
2) You can't call it complete or compatible w/o passing the test suite.
>
> So, if a JSR either spell out that the closed/NDA suites are
> reference, but
> not the sole authoritative test of compliance, or ... spell out the
> reference
> test - which is authoritative - must not be subject to NDA.
The EG has to deliver the sole authoritative test - there only is one.
> (I don't know
> that we care if we can or cannot republish it. We only care, I
> believe,
> that the ASF committer can obtain and use that test without
> additional burdens
> or liabilities.)
How can you agree to not republish if there are no additional burdens
or liabilities when obtaining said thing we can't republish?
geir
Re: [Draft] New ASF/JCP Policies
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Mark Thomas wrote:
>
> I am concerned that we are in danger of cutting off our nose to spite
> our face here.
>
> I see three categories of standard body:
> a) Operates in an open Apache-like manner
> b) Is not open (NDAs on TCKs, closed EG lists etc) but does nothing that
> prevents us releasing implementations of the spec under AL2
> c) Operates in a way (eg FOU restriction on TCK) that prevents us
> releasing implementations of the spec under AL2
>
> My main cause of concern is that the Servlet expert groups fall under b)
> since an NDA is required for the Servlet TCK.
How does requiring an NDA from the developers NOT prevent us from releasing
under AL2, when the source code is not authoritatively validated? (Only the
resulting binaries/.jar's from what I understand). We've twisted ourselves
with anti-Apache-way practices just to work around this issue.
Let's clarify. I don't *care* if the EG list is closed. I don't care if
a spec is written entirely by one person developed privately in their own
head, provided that it is a spec worth implementing to some developers here
at the ASF. Specs are only that, reference documents.
The only thing we care about is the openness of the implementation, and that
the reference document it is produced from is also open. (This is true even
when a reference must be reverse engineered from a closed implementation.
Still, we have an open document at the end of the day, even if it's from the
other side of the Chinese Wall.)
Consider how many http: validators there are, many in closed source. We can
(and certainly do) implement RFC2616 without the benefit of such products.
There are actually two ways around this. We don't care if a TCK/test suite
is closed source/NDA, even when it's considered the reference test. We do
care, however, that we cannot label our code as an implementation until
it passes a closed source/NDA suite.
So, if a JSR either spell out that the closed/NDA suites are reference, but
not the sole authoritative test of compliance, or ... spell out the reference
test - which is authoritative - must not be subject to NDA. (I don't know
that we care if we can or cannot republish it. We only care, I believe,
that the ASF committer can obtain and use that test without additional burdens
or liabilities.)
We keep speaking of TCKs in black and white; I think it will help the JCP and
ourselves to be clear about -what- our objections are, and that there are more
than one solution to clear up this problem.
Re: [Draft] New ASF/JCP Policies
Posted by Mark Thomas <ma...@apache.org>.
William A. Rowe, Jr. wrote:
> Sam Ruby wrote:
>> On 7/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>> If you want operational specifics to get have a meaningful action for
>>> the TCK/NDA issue, I'd suggest :
>>>
>>> 1) We announce that we no longer accept NDAs and will allow existing
>>> under-NDA TCK usage for 1 release.
>> +1
>
> A period of time seems more effective. Say, 120 days? Even if we start
> 'fixing' some JSP's tomorrow, there will be a list of them to sort through
> and solve one-by-one (if the spec lead and the ASF concur).
>
>>> 2) We make a public request to Sun that they formally drop any NDA
>>> requirements around our TCK usage. If they agree, we open things
>>> up. If they don't, we just shut it down.
>> -1 (of the non-veto variety)
>>
>> s/Sun/all affected expert groups/
>
> +1
>
>> s/shut it down/cease ASF representation in the expert groups that don't
>> comply/
>
> +1, and cease using those TCK's under NDA after some period of time as
> I'd floated under +1.
>
>> Even with these changes, I'm not a fan of making this particular
>> change retroactive, but if the majority feels that this should be
>> done, I won't stand in the way.
>
> I'm +/- 0 on changing this for current implementations that have already
> gone through and use an existing TCK under NDA. I'm strongly +1 for the
> change of all new code efforts, even minor bumps (say from spec v1.1 to 1.2).
I am concerned that we are in danger of cutting off our nose to spite
our face here.
I see three categories of standard body:
a) Operates in an open Apache-like manner
b) Is not open (NDAs on TCKs, closed EG lists etc) but does nothing that
prevents us releasing implementations of the spec under AL2
c) Operates in a way (eg FOU restriction on TCK) that prevents us
releasing implementations of the spec under AL2
My main cause of concern is that the Servlet expert groups fall under b)
since an NDA is required for the Servlet TCK. I see in this thread
proposals for new ASF policy that would prevent Tomcat using the TCK for
Tomcat 7 (or whatever we call it) onwards which in turn, if I understand
how the JCP works correctly, would prevent us from claiming spec
compliance for future Tomcat versions. Given that the Tomcat project
exists to implement the Servlet and JSP specs, this would effectively
kill the Tomcat project. I don't see how this helps the Tomcat community
in any way at all and would be -1 for any such new policy.
For standard bodies of type b) I believe we are better off continuing to
participate, whilst lobbying for them to change to type a). How we get
them to change is probably a topic for another thread.
Mark
Re: [Draft] New ASF/JCP Policies
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sam Ruby wrote:
> On 7/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> 1) No NDAs can be required for participation in ASF activities. I'm
>> not sure how we'll ever be able to meaningfully require private@ and
>> members@ list to be under an NDA, but I expect that inconvenient
>> observation will be mooted via adding "technical" as a qualifier for
>> "ASF activities". This solves the NDA for TCK issue.
>
> +1
+1 if we express this as "ASF technical activities". That does take out
all the issues of managing projects/people on private@/members@/board@.
And the point is, these aren't NDA's - they are simply respect for the
ASF and keeping private issues private to the Foundation.
That has nothing to do with an NDA - which we don't require that members
sign. We give our members/participants the credit that they can manage
private information, privately, without signing any NDA.
>> 2) The ASF won't participate in activities that aren't "run like an
>> Apache project". This solves the EG issue.
>
> +1
+1 - with the caviat that members of the ASF may participate in, and even
author specs in less-open venues. But not as a formal ASF activity or with
the ASF name attached to it; unless it's open, the Foundation doesn't belong
in the list of participants.
>> 3) The ASF won't implement specifications that weren't created in a
>> manner similar to "an Apache project". I'm not sure if we want this,
>> but to me it clearly falls out of your proposal, so I think that you
>> want this too.
-1. It's a finished specification. Either it interests us to implement
(there are committers with that spec itch to scratch) or it does not.
If it's /not/ encumbered, why do we care as a matter of policy?
> I don't believe it clearly falls out of my proposal, but I would
> support a proposal that removes my addition of "nor will we request
> access to TCKs for any given JSR produced by any working group," from
> the "Representation" section; and adds a new section that concerns
> itself with the conditions under which the ASF will formally request
> access to a TCK. This new section would essentially repeat the final
> bullet in the "Representation" section.
>
> This should completely decouple the two issues, no?
+1 - there is a difference between a spec in front of us that we can
implement, and those we cannot due to IP/TCK/NDA issues which would
prevent us from having an open, healthy development community. No?
>> This isn't actually something that's JCP specific, so I'll bring up
>> on board@ or members@
I agree, my +/-1's above map to how the foundation might work best, not
specifically related to the JCP.
>> If you want operational specifics to get have a meaningful action for
>> the TCK/NDA issue, I'd suggest :
>>
>> 1) We announce that we no longer accept NDAs and will allow existing
>> under-NDA TCK usage for 1 release.
>
> +1
A period of time seems more effective. Say, 120 days? Even if we start
'fixing' some JSP's tomorrow, there will be a list of them to sort through
and solve one-by-one (if the spec lead and the ASF concur).
>> 2) We make a public request to Sun that they formally drop any NDA
>> requirements around our TCK usage. If they agree, we open things
>> up. If they don't, we just shut it down.
>
> -1 (of the non-veto variety)
>
> s/Sun/all affected expert groups/
+1
> s/shut it down/cease ASF representation in the expert groups that don't
> comply/
+1, and cease using those TCK's under NDA after some period of time as
I'd floated under +1.
> Even with these changes, I'm not a fan of making this particular
> change retroactive, but if the majority feels that this should be
> done, I won't stand in the way.
I'm +/- 0 on changing this for current implementations that have already
gone through and use an existing TCK under NDA. I'm strongly +1 for the
change of all new code efforts, even minor bumps (say from spec v1.1 to 1.2).
Bill
Re: [Draft] New ASF/JCP Policies
Posted by Sam Ruby <ru...@apache.org>.
On 7/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> There are actually three fundamental principles involved that I think
> are worth enumerating to ensure this isn't simply "mob rule" aimed at
> something that made us mad. It shouldn't take long to do - there are
> at least four ASF board members in this thread, and it seems that all
> anyone ever needs is Wiki access to set policy anyway (see "the
> Apache Way" as an example :)
>
> 1) No NDAs can be required for participation in ASF activities. I'm
> not sure how we'll ever be able to meaningfully require private@ and
> members@ list to be under an NDA, but I expect that inconvenient
> observation will be mooted via adding "technical" as a qualifier for
> "ASF activities". This solves the NDA for TCK issue.
+1
> 2) The ASF won't participate in activities that aren't "run like an
> Apache project". This solves the EG issue.
+1
> 3) The ASF won't implement specifications that weren't created in a
> manner similar to "an Apache project". I'm not sure if we want this,
> but to me it clearly falls out of your proposal, so I think that you
> want this too.
I don't believe it clearly falls out of my proposal, but I would
support a proposal that removes my addition of "nor will we request
access to TCKs for any given JSR produced by any working group," from
the "Representation" section; and adds a new section that concerns
itself with the conditions under which the ASF will formally request
access to a TCK. This new section would essentially repeat the final
bullet in the "Representation" section.
This should completely decouple the two issues, no?
> This isn't actually something that's JCP specific, so I'll bring up
> on board@ or members@
>
> If you want operational specifics to get have a meaningful action for
> the TCK/NDA issue, I'd suggest :
>
> 1) We announce that we no longer accept NDAs and will allow existing
> under-NDA TCK usage for 1 release.
+1
> 2) We make a public request to Sun that they formally drop any NDA
> requirements around our TCK usage. If they agree, we open things
> up. If they don't, we just shut it down.
-1 (of the non-veto variety)
s/Sun/all affected expert groups/
s/shut it down/cease ASF representation in the expert groups that don't comply/
Even with these changes, I'm not a fan of making this particular
change retroactive, but if the majority feels that this should be
done, I won't stand in the way.
- Sam Ruby
P.S. Welcome back. We missed you.
Re: [Draft] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jul 1, 2007, at 9:44 AM, Sam Ruby wrote:
> On 7/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> On Jun 30, 2007, at 9:15 PM, Sam Ruby wrote:
>>
>> > On 6/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >>
>> >> > I think I would rather wait until I see what that means in
>> >> operational
>> >> > terms, i.e., as a marked up version of our policies.
>> >>
>> >> Aka "Fetch me a Rock"? :)
>> >
>> > No, thanks. I already have one.
>> >
>> > http://people.apache.org/~rubys/jcp.html
>> >
>>
>> Yes, and they are very good.
>>
>> But could you please comment on the general issue of being able to
>> implement specs that aren't created in an "open" manner? I like the
>> idea by I'm not sure if you actually meant it.
>
> I did not insert those words. Compare:
>
> http://www.apache.org/jcp/
>
> And if I read the svn logs[1] correctly, those words were created
> by you.
>
> I will acknowledge that I changed the context for those words from
> "encourage" to "require". Did I mean to do so? Yes.
There's a big difference. And you also tied getting a TCK to
conformance with those words, and that by extension ties
implementation of spec to conformance to those words.
>
> But, if you now would like to change those words, please propose
> something specific.
I will.
>
>> It's a side-effect of your "rock", but given it's targeted at the JCP
>> only, it really is targeted at a single company. Granted, that
>> company is behaving very badly, but I'd rather see us setup a general
>> principled policy, than have one targeting a single commercial
>> entity.
>
> Duh. This pages concerns itself with the JCP. This topic of this
> mailing list is the JCP.
>
> To the best of my knowledge, there is no other specification process
> where the ASF directly participates in collecting NDAs, or in private
> mailing lists. Should we, in the future, ever be presented with the
> "opportunity" to do so, I would strongly suggest that we pass on that
> opportunity. Should somebody identify another process that I have
> overlooked where people participate, not as individuals or as
> employees of their respective companies, but as representatives of the
> ASF, and do so on private mailing lists or under condition of NDA,
> then I would suggest that we revisit our participating in those
> activities too.
ASF communities implement specs from many other standards bodies.
Your changes subtly but explicitly tie the basic implementation of
JCP specs to a requirement that the EG that created the spec follow
those requirements. I'm asking if we'd be better served with a
general policy here, to avoid appearance of us going after one company.
>
> I will also note that no single company is singled out or targeted by
> the policy spelled out on that page, either before or after my
> proposed edits.
You are suggesting that the ASF require only JCP specs to have this
openness requirement if we are going to implement them. We all know
that the JCP is Sun run.
I'm suggesting that we should make that general policy that our JCP
participation falls under. You get what you want, but it's based on
general principle, rather than targeted action.
>
> Let me add my own +1 to the proposal I drafted. So at the moment, and
> 52 days after the deadline that you gave Sun, we have five +1s on the
> proposal, and no alternate proposals on the table.
I must have missed the rule where any discussion must be only in the
form of html, and email discussion doesn't count. Yeah, there as
some delay - I checked out and had some work stuff to do, but I'm
back now. So you can accept my apology and engage with me if you
think I have something interesting to add, or just call for a vote
and ignore me.
I've made the alternate proposal that we just do away with any NDA-ed
materials completely (rather than freeze in time), and suggested that
your proposed change to require some kind of pedigree of open spec
creation before we implement said spec would be better either as a
general policy, or dropped, since it tangles the TCK NDA issue with
how specs are created.
>
> Shall we proceed to an official vote? Or is there an alternate
> proposal imminent?
I've been trying to get some understanding behind how you and others
feel about the alternatives. How do you feel about getting rid of
all NDA-ed materials?
There are actually three fundamental principles involved that I think
are worth enumerating to ensure this isn't simply "mob rule" aimed at
something that made us mad. It shouldn't take long to do - there are
at least four ASF board members in this thread, and it seems that all
anyone ever needs is Wiki access to set policy anyway (see "the
Apache Way" as an example :)
1) No NDAs can be required for participation in ASF activities. I'm
not sure how we'll ever be able to meaningfully require private@ and
members@ list to be under an NDA, but I expect that inconvenient
observation will be mooted via adding "technical" as a qualifier for
"ASF activities". This solves the NDA for TCK issue.
2) The ASF won't participate in activities that aren't "run like an
Apache project". This solves the EG issue.
3) The ASF won't implement specifications that weren't created in a
manner similar to "an Apache project". I'm not sure if we want this,
but to me it clearly falls out of your proposal, so I think that you
want this too.
This isn't actually something that's JCP specific, so I'll bring up
on board@ or members@
If you want operational specifics to get have a meaningful action for
the TCK/NDA issue, I'd suggest :
1) We announce that we no longer accept NDAs and will allow existing
under-NDA TCK usage for 1 release.
2) We make a public request to Sun that they formally drop any NDA
requirements around our TCK usage. If they agree, we open things
up. If they don't, we just shut it down.
geir
Re: [Draft] New ASF/JCP Policies
Posted by Sam Ruby <ru...@apache.org>.
On 7/1/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> On Jun 30, 2007, at 9:15 PM, Sam Ruby wrote:
>
> > On 6/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >> > I think I would rather wait until I see what that means in
> >> operational
> >> > terms, i.e., as a marked up version of our policies.
> >>
> >> Aka "Fetch me a Rock"? :)
> >
> > No, thanks. I already have one.
> >
> > http://people.apache.org/~rubys/jcp.html
> >
>
> Yes, and they are very good.
>
> But could you please comment on the general issue of being able to
> implement specs that aren't created in an "open" manner? I like the
> idea by I'm not sure if you actually meant it.
I did not insert those words. Compare:
http://www.apache.org/jcp/
And if I read the svn logs[1] correctly, those words were created by you.
I will acknowledge that I changed the context for those words from
"encourage" to "require". Did I mean to do so? Yes.
But, if you now would like to change those words, please propose
something specific.
> It's a side-effect of your "rock", but given it's targeted at the JCP
> only, it really is targeted at a single company. Granted, that
> company is behaving very badly, but I'd rather see us setup a general
> principled policy, than have one targeting a single commercial entity.
Duh. This pages concerns itself with the JCP. This topic of this
mailing list is the JCP.
To the best of my knowledge, there is no other specification process
where the ASF directly participates in collecting NDAs, or in private
mailing lists. Should we, in the future, ever be presented with the
"opportunity" to do so, I would strongly suggest that we pass on that
opportunity. Should somebody identify another process that I have
overlooked where people participate, not as individuals or as
employees of their respective companies, but as representatives of the
ASF, and do so on private mailing lists or under condition of NDA,
then I would suggest that we revisit our participating in those
activities too.
I will also note that no single company is singled out or targeted by
the policy spelled out on that page, either before or after my
proposed edits.
Let me add my own +1 to the proposal I drafted. So at the moment, and
52 days after the deadline that you gave Sun, we have five +1s on the
proposal, and no alternate proposals on the table.
Shall we proceed to an official vote? Or is there an alternate
proposal imminent?
- Sam Ruby
[1] http://svn.apache.org/viewvc/infrastructure/site/trunk/docs/jcp/index.html
Re: [Draft] New ASF/JCP Policies
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jun 30, 2007, at 9:15 PM, Sam Ruby wrote:
> On 6/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> > I think I would rather wait until I see what that means in
>> operational
>> > terms, i.e., as a marked up version of our policies.
>>
>> Aka "Fetch me a Rock"? :)
>
> No, thanks. I already have one.
>
> http://people.apache.org/~rubys/jcp.html
>
Yes, and they are very good.
But could you please comment on the general issue of being able to
implement specs that aren't created in an "open" manner? I like the
idea by I'm not sure if you actually meant it.
It's a side-effect of your "rock", but given it's targeted at the JCP
only, it really is targeted at a single company. Granted, that
company is behaving very badly, but I'd rather see us setup a general
principled policy, than have one targeting a single commercial entity.
geir
Re: [Draft] New ASF/JCP Policies
Posted by Sam Ruby <ru...@apache.org>.
On 6/30/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> > I think I would rather wait until I see what that means in operational
> > terms, i.e., as a marked up version of our policies.
>
> Aka "Fetch me a Rock"? :)
No, thanks. I already have one.
http://people.apache.org/~rubys/jcp.html
- Sam Ruby