You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Brian Behlendorf <br...@collab.net> on 2004/07/09 03:34:40 UTC
proposal: modify incubation application process to require a reference
to the code itself
In walking through the incubation documents (helping a couple of groups
who have asked me about how to do this) it struck me that there was no
requirement that the proposal provide a link to download and evaluate the
code around which a project is being proposed - in fact it appears the
code itself could be kept secret until project acceptance into the
incubator. It seems to me that any honest assessment of the merit of
accepting a proposal should include a look at the code itself, if only to
get a gut-check on how maintainable and evolveable that codebase might be
going forward. Many proposals have provided just such a link despite it
not being required. Requiring it would also avoid the situation where
someone says "if Apache approves it *then* I'll release the code".
Thoughts?
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Sanjiva Weerawarana wrote:
>
> Given that there are many places where one can start an open source
> project, IMO it makes perfect sense for Apache to have a higher
> standard. If the company's strategy question is whether to open source
> or not, then if the decision depends on acceptance to Apache then I'd
> say we're better off without it!
i disagree. for one thing, this is basically stating that the proposal
isn't sufficient. i disagree with that on principle; if the proposal
isn't enough to allow us to make up our minds, propping it up with the
code seems makeshift.
for another thing, the asf *does* have a higher standard: we require
transfer of ownership and ip. it makes perfect sense to me that a
company may be willing to transfer those to the asf, but *not* be
willing to throw them into the open -- which is the potential if
the code is exposed before the acceptance and transfer.
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQPJiFJrNPMCpn3XdAQHM7wP8CxzWkngqfh7hA88MAmI8JTloVv0dHDP7
X1/uHGQz1wBZ/ZxavOb1oTHfo+n9AkJnVq5TnjTutYymX8W7nEAF8YNG2OfBILoC
zlPqWyL51jUVNvtI2h0DdgPjizb5B66OzhTF1UT280W/lg6chkom5eV75a0kgquv
XE/9iyHq/VQ=
=Seyj
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a reference to the code itself
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
"Andreas Hartmann" <an...@apache.org> writes:
> Another thought:
>
> What if a company considers to introduce an open source strategy,
> but the decision depends on whether the code is accepted as an
> Apache project or not? I think they will avoid showing the code
> before the project is accepted or rejected.
Given that there are many places where one can start an open source
project, IMO it makes perfect sense for Apache to have a higher
standard. If the company's strategy question is whether to open source
or not, then if the decision depends on acceptance to Apache then I'd
say we're better off without it!
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Brian Behlendorf wrote:
>
>>
>> In walking through the incubation documents (helping a couple of
>> groups who have asked me about how to do this) it struck me that there
>> was no requirement that the proposal provide a link to download and
>> evaluate the code around which a project is being proposed - in fact
>> it appears the code itself could be kept secret until project
>> acceptance into the incubator.
Another thought:
What if a company considers to introduce an open source strategy,
but the decision depends on whether the code is accepted as an
Apache project or not? I think they will avoid showing the code
before the project is accepted or rejected.
I'm not experienced when it comes to these things, I hope you
tolerate my silly statements and maybe I can even learn
something :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Andreas Hartmann <an...@apache.org>.
Brian Behlendorf wrote:
>
> In walking through the incubation documents (helping a couple of groups
> who have asked me about how to do this) it struck me that there was no
> requirement that the proposal provide a link to download and evaluate
> the code around which a project is being proposed - in fact it appears
> the code itself could be kept secret until project acceptance into the
> incubator.
I'd like to express a concern about this. I think the decision about
incubation should not depend on the code. When a the idea / goals /
concepts of a project can attract developers, they would certainly
be interested in improving the code base. Couldn't it even be
possible to re-build the code base from scratch?
Is it really useful to require a certain quality standard already
in the beginning of the incubation process?
Just my $0.02 ...
-- Andreas
> It seems to me that any honest assessment of the merit of
> accepting a proposal should include a look at the code itself, if only
> to get a gut-check on how maintainable and evolveable that codebase
> might be going forward. Many proposals have provided just such a link
> despite it not being required. Requiring it would also avoid the
> situation where someone says "if Apache approves it *then* I'll release
> the code".
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a reference to the code itself
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jul 12, 2004, at 5:39 PM, Brian Behlendorf wrote:
> On Mon, 12 Jul 2004, Stefano Mazzocchi wrote:
>> Brian Behlendorf wrote:
>>
>>> On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
>>>> why? if the idea excites people but the code sucks, are we going to
>>>> turn it down?
>>> In that case, we might decide to accept a new project into the
>>> incubator for the same purpose, but decide not to accept the sucky
>>> code.
>>
>> java.apache.org history shows a long history of failures in
>> incubating projects without code. jakarta doesn't, exactly because we
>> established that rule.
>>
>> It would be a *major* step back if we lifted that requirement.
>
> Keep in mind that availablility of the code is a requirement during
> incubation, of course. The question is what's an appropriate bar to
> set *before* a project is accepted into the incubator.
>
I can imagine cases where it might be reasonable to suggest such a
thing ;)
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian Behlendorf wrote:
> On Mon, 12 Jul 2004, Stefano Mazzocchi wrote:
>
>> Brian Behlendorf wrote:
>>
>>> On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
>>>
>>>> why? if the idea excites people but the code sucks, are we going to
>>>> turn it down?
>>>
>>>
>>> In that case, we might decide to accept a new project into the
>>> incubator for the same purpose, but decide not to accept the sucky code.
>>
>>
>> java.apache.org history shows a long history of failures in incubating
>> projects without code. jakarta doesn't, exactly because we established
>> that rule.
>>
>> It would be a *major* step back if we lifted that requirement.
>
>
> Keep in mind that availablility of the code is a requirement during
> incubation, of course. The question is what's an appropriate bar to set
> *before* a project is accepted into the incubator.
Ok, just making sure.
> Let's also admit there are open source projects out there, perhaps even
> within the ASF, whose code quality makes it difficult to build
> communities around.
Absolutely. In fact, some of the ASF projects are simply too good.
--
Stefano.
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 12 Jul 2004, Stefano Mazzocchi wrote:
> Brian Behlendorf wrote:
>
>> On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
>>
>>> why? if the idea excites people but the code sucks, are we going to
>>> turn it down?
>>
>> In that case, we might decide to accept a new project into the incubator
>> for the same purpose, but decide not to accept the sucky code.
>
> java.apache.org history shows a long history of failures in incubating
> projects without code. jakarta doesn't, exactly because we established that
> rule.
>
> It would be a *major* step back if we lifted that requirement.
Keep in mind that availablility of the code is a requirement during
incubation, of course. The question is what's an appropriate bar to set
*before* a project is accepted into the incubator.
Let's also admit there are open source projects out there, perhaps even
within the ASF, whose code quality makes it difficult to build
communities around.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Craig McClanahan <cr...@apache.org>.
Noel J. Bergman wrote:
>>java.apache.org history shows a long history of failures in incubating
>>projects without code. jakarta doesn't, exactly because we established
>>that rule.
>>
>>
>
>
>
>>It would be a *major* step back if we lifted that requirement.
>>
>>
>
>We wouldn't be lifting it because we haven't had that requirement. In the
>case of Geronimo, we pretty much forced Geronimo to code from scratch,
>based on their expertise. That said, it would be extremely rare to
>incubate a new community without seed code. I don't know of another such.
>But we do have a quite successful precedent for making an exception.
>
>Again, I think it goes back to community. We've rejected code without a
>community, but I don't think I'd reject a community that lacked code, if
>we had ASF Members who wanted to sponsor it.
>
> --- Noel
>
>
There's still an outstanding question from the original message in this
thread, though ... would we reject an entry into incubation if there
*was* code, but we couldn't look at it unless the incubation was
accepted? I believe we would always want to require code review in such
a circumstance. Whether or not we'd be willing to do such a code review
privately (under some form of NDA) is a separate question.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
RE: proposal: modify incubation application process to require a reference to the code itself
Posted by "Noel J. Bergman" <no...@devtech.com>.
> java.apache.org history shows a long history of failures in incubating
> projects without code. jakarta doesn't, exactly because we established
> that rule.
> It would be a *major* step back if we lifted that requirement.
We wouldn't be lifting it because we haven't had that requirement. In the
case of Geronimo, we pretty much forced Geronimo to code from scratch,
based on their expertise. That said, it would be extremely rare to
incubate a new community without seed code. I don't know of another such.
But we do have a quite successful precedent for making an exception.
Again, I think it goes back to community. We've rejected code without a
community, but I don't think I'd reject a community that lacked code, if
we had ASF Members who wanted to sponsor it.
--- Noel
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian Behlendorf wrote:
> On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
>
>> Brian Behlendorf wrote:
>>
>>> It seems to me that any honest assessment of the merit of
>>> accepting a proposal should include a look at the code itself, if
>>> only to
>>> get a gut-check on how maintainable and evolveable that codebase
>>> might be
>>> going forward.
>>
>>
>> why? if the idea excites people but the code sucks, are we going to
>> turn it down?
>
> In that case, we might decide to accept a new project into the incubator
> for the same purpose, but decide not to accept the sucky code.
java.apache.org history shows a long history of failures in incubating
projects without code. jakarta doesn't, exactly because we established
that rule.
It would be a *major* step back if we lifted that requirement.
--
Stefano.
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
> Brian Behlendorf wrote:
>> It seems to me that any honest assessment of the merit of
>> accepting a proposal should include a look at the code itself, if only to
>> get a gut-check on how maintainable and evolveable that codebase might be
>> going forward.
>
> why? if the idea excites people but the code sucks, are we going to
> turn it down?
In that case, we might decide to accept a new project into the
incubator for the same purpose, but decide not to accept the sucky code.
>> Many proposals have provided just such a link despite it
>> not being required. Requiring it would also avoid the situation where
>> someone says "if Apache approves it *then* I'll release the code".
>
> why do we want to avoid this situation? what business of it is ours
> if the submitter wants to entrust their baby to us and only to us?
> we should say no when given such an expression of confidence?
I thought I explained it in the half-dozen paragraphs that followed, but
I'll try it again...
It's definitely our business, because it's code that the ASF will become
responsible for maintaining. Furthermore it puts a burden on the ASF to
make the project successful, beyond our own intentions to do so. We
aren't here to provide an open-sourcing service to companies - I don't
believe we can (nor should we be expect to) look into the eyes of a
company's executive and say "grant your code to us and we'll guarantee a
community and a healthy project". There's an implicit promise in an
arrangement like that.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Brian Behlendorf wrote:
>
>>It seems to me that any honest assessment of the merit of
>>accepting a proposal should include a look at the code itself, if only to
>>get a gut-check on how maintainable and evolveable that codebase might be
>>going forward.
>
>
> why? if the idea excites people but the code sucks, are we going to
> turn it down?
I agree with Ken. In my experience, good ideas and bad code work a lot
better in creating a community than good ideas with good code. And the
reason is that it makes it a lot easier to suck people in, because they
like the concept but not the code and start fixing it.
I also agree with Ken that a proposal should just indicate that a
working codebase is in place and the mentor should be able to attest
that (so he/she should be given a copy of the software, with source, to
try it out), but this doesn't require things to be thrown in the wild
(practice that would be hard for those companies that are willing to
open source some of their software).
So, in short: I personally think that we *must* require a working
codebase (incubating communities out of simple ideas is just asking for
trouble), but that the incubator is not equipped to judge the value of a
software quality at the acceptance stage, but only at the exiting the
process.
Basically, the whole idea of the incubator is that we are using
darwinian principles to evaluate quality and health of a community,
assuming that without value, such a community wouldn't form around it.
What the incubator "acceptance process" should try to filter is those
proposals who cannot even make it inside our petri dishes, and code,
besides being somewhat operational, should not be part of the judgment,
or we make the mistake of doing some of that darwinian selection ourselves.
And why would that be a mistake? in my experience, projects could change
shape when they are incubated (even in the pre-incubation days), one guy
could come along and just reshape the thing in such a way that at that
point the community can florishes.
Code quality doesn't mean anything for incubation: it comes up by itself
later, when the incubation is successful. Very counterintuitive, I
agree, but that's what I've seen happening far too many times for being
a statistical singularity.
--
Stefano.
RE: proposal: modify incubation application process to require a reference to the code itself
Posted by "Noel J. Bergman" <no...@devtech.com>.
Brian Behlendorf wrote:
> If a company isn't willing to put the code base out themselves under
> their own ownership, but would rather it be (C) ASF, that leads me to
> wonder about what liability the company is attempting to avoid by doing
> so. It may be paranoia, but seeing a company willing to put the code out
> under an open source license with a (C) to them does a lot to quell
> concerns about whether the codebase is IP-clean.
> To be clear, the ASF takes a legal risk with every line of code it
> publishes to the public.
> > An IP pre-review could cause a problem. IP made available for review
would
> > have to be free of encumbrances. We do not want a situation where
people
> > who have reviewed it become tainted. Certainly that can be the case if
the
> > license were a proprietary one, but it does not seem to matter if the
> > license is an OSI-approved one or not. Claims can be made based upon
(L)GPL
> > as easily as upon more classically recognized proprietary licenses. So,
no,
> > I do not agree that "any legal mechanism that provides for anyone in the
> > community to conveniently read the source should be acceptable, even if
the
> > license restricts distribution, for instance."
>
> Good point; that suggests the requirement be to be very clear that review
> of the code places no encumbrances.
Brian, the gist of your message appears to be a concern that the Foundation
could be exposed, at least unintentionally and possibly intentionally, by a
contribution, and therefore you want to vet the code first. I respect your
intention to protect the Foundation. Neither of us, last time I checked, is
an IP attorney. If the Board wishes to put this issue to our lawyer, that'd
be great. However, my understanding is this:
- As has been said before, when we receive a Software Grant
and/or CLA, the presumption is that the contributor has
the right to provide it.
- We do not have an indemnification clause in the Software
Grant, but that is not necessary if there is fraudulent
conduct. Nor would it be realistic or even appropriate
to have one.
- We neither can, nor want to, claim that we have reviewed
the code to ascertain that it does not infringe on IP
owned by someone else. Instead, we required that to be
stated by the Contributor in the Software Grant for the
initial donation, along with CLAs for continuing work.
- When we review code, we look to make sure that we have
a Software Grant, correct licenses and copyright. As
people work on the code, if someone notices something,
such as someone's name or other thing that flags a
question in their mind, they should point it out and ask.
- If there are specific allegations made, we respond to them
with alacrity and honesty. But it is simply not possible
to claim that no line of code, contributed at any time, does
not infringe some third party's rights without an exhaustive
analysis to make sure it wasn't lifted from another source
and doesn't infringe on some patent.
- Our potential liability is very limited. Roy has spoken about
this on multiple occassions.
- A corporation that has closed source under their own copyright
putting it out under their copyright on its way to us does not
appear to provide any protection once it is distributed under
our copyright and via our infrastructure. And I don't believe
that it is reasonable to put a corporation's through multiple
relicensing phases, nor their developers for that matter. Why
should we impose these expenses if there is no real benefit?
Craig McClanahan wrote:
> would we reject an entry into incubation if there *was* code,
> but we couldn't look at it unless the incubation was accepted?
> Whether or not we'd be willing to do such a code review privately
> (under some form of NDA) is a separate question.
If there is any encumbrance, then I don't believe that we should look at the
code. Which means we wait for the Software Grant.
Again, none of us are IP attorneys. If the concern is limiting the
Foundation's liability, let's push this to the Board to put to our counsel.
Unless our legal counsel says differently, I don't see any reason to impose
this as a mandate for reasons that I laid out earlier today.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: several messages
Posted by Brian Behlendorf <br...@collab.net>.
On Mon, 12 Jul 2004, Rodent of Unusual Size wrote:
> for another thing, the asf *does* have a higher standard: we require
> transfer of ownership and ip. it makes perfect sense to me that a
> company may be willing to transfer those to the asf, but *not* be
> willing to throw them into the open -- which is the potential if
> the code is exposed before the acceptance and transfer.
Well, this worries me some more. The simplest thing a company could do to
meet the requiremet is put the code on their own site as a downloadable
tarball. In such a scenario, the company can elect whatever license they'd
want, Apache or otherwise; and they'd call themselves the copyright owner.
The only risk to the company in doing so, compared to giving it to Apache,
is that any third-party claims others might make (based on copyright,
patent, or trademark) would be against the company, rather than to the
ASF. If a company isn't willing to put the code base out themselves under
their own ownership, but would rather it be (C) ASF, that leads me to
wonder about what liability the company is attempting to avoid by doing
so. It may be paranoia, but seeing a company willing to put the code out
under an open source license with a (C) to them does a lot to quell
concerns about whether the codebase is IP-clean. We're not a
code-laundry, and I don't want to even allow for the possibility that we
might be abused as such.
On Mon, 12 Jul 2004, Leo Simons wrote:
> One of the key requirements is that there's enough people interested in a
> project and willing to help. Ensuring that will usually be very difficult
> without making code available, but not always. Consider geronimo. There was
> no code, but we accepted it anyway (IIRC the board did, even). Good decision.
Not strictly true, there was a lot of pre-existing code, and it was the
quality of that code that I think excited a lot of people about the
project.
On Mon, 12 Jul 2004, Noel J. Bergman wrote:
> That said, if there are ASF Members who want to incubate a project, I would
> prefer that we give them a chance to succeed, even if the endeavor
> ultimately fails. I don't share the concern that "it's code that the ASF
> will become responsible for maintaining." I don't see that we have an
> obligation to maintain a failed project, although I would put the CVS
> tarball in the archives, or preferably just do an svn remove, as an audit
> trail. Nor do I believe that there is any requirement for the Incubator to
> expend extraordinary efforts to make a project successful beyond that which
> ASF Members are willing to contribute as mentors.
To be clear, the ASF takes a legal risk with every line of code it
publishes to the public. Projects that go quiescent are a liability; as
are failed projects. There's also a PR problem for the ASF if there are
too many failed projects. So some care should be taken in deciding what
to admit into the incubator; less so than to graduate, of course, but care
nonetheless. We should probably also do more active garbage collection on
established projects, but that's another topic for somewhere else...
> An IP pre-review could cause a problem. IP made available for review would
> have to be free of encumbrances. We do not want a situation where people
> who have reviewed it become tainted. Certainly that can be the case if the
> license were a proprietary one, but it does not seem to matter if the
> license is an OSI-approved one or not. Claims can be made based upon (L)GPL
> as easily as upon more classically recognized proprietary licenses. So, no,
> I do not agree that "any legal mechanism that provides for anyone in the
> community to conveniently read the source should be acceptable, even if the
> license restricts distribution, for instance."
Good point; that suggests the requirement be to be very clear that review
of the code places no encumbrances. This could be as an additional
freedom granted above and beyond the (L)GPL, so it doesn't have to be
Apache licensed.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Stefano Mazzocchi <st...@apache.org>.
Noel J. Bergman wrote:
> As I see it, community is our concern. Either we have a strong community
> coming in, or we believe that we have the ability to form one around some
> catalyst.
>
> If we are accepting a contribution based upon its community, the quality of
> its code is probably not a pre-determining criteria, and we would be
> unlikely to terminate the project when we do see it. On the other hand,
> perhaps we might have a group of ASF people interested in some problem
> domain, but who feel that without a major starting point, the ramp up effort
> is too great. Someone comes along and proposes to contribute a starting
> point. In that scenario, the code could be an important desiderata, and we
> do risk terminating the project if the community decides that the seed isn't
> strong enough.
>
> That said, if there are ASF Members who want to incubate a project, I would
> prefer that we give them a chance to succeed, even if the endeavor
> ultimately fails. I don't share the concern that "it's code that the ASF
> will become responsible for maintaining." I don't see that we have an
> obligation to maintain a failed project, although I would put the CVS
> tarball in the archives, or preferably just do an svn remove, as an audit
> trail. Nor do I believe that there is any requirement for the Incubator to
> expend extraordinary efforts to make a project successful beyond that which
> ASF Members are willing to contribute as mentors.
>
> An IP pre-review could cause a problem. IP made available for review would
> have to be free of encumbrances. We do not want a situation where people
> who have reviewed it become tainted. Certainly that can be the case if the
> license were a proprietary one, but it does not seem to matter if the
> license is an OSI-approved one or not. Claims can be made based upon (L)GPL
> as easily as upon more classically recognized proprietary licenses. So, no,
> I do not agree that "any legal mechanism that provides for anyone in the
> community to conveniently read the source should be acceptable, even if the
> license restricts distribution, for instance." If you want it in blunt
> terms, I would not want to see a situation where someone can poison the
> well. IANAL, but until we have an encumbrance-free contribution, I don't
> believe that anyone, including prospective mentors, should be reviewing it.
> And since the contributor may not want to sign the Software Grant until a
> decision has been made to accept the project, if we make it a *requirement*
> to review the code prior to Incubation, we could have a Catch-22.
>
> Therefore, since I feel that we could have valid reasons for accepting a
> project without a prior review, and since performing a prior review could
> create problems, I'm not sure that we want to make this a mandate, and lose
> a perfectly good project.
I resonate with Noel.
--
Stefano.
RE: proposal: modify incubation application process to require a reference to the code itself
Posted by "Noel J. Bergman" <no...@devtech.com>.
As I see it, community is our concern. Either we have a strong community
coming in, or we believe that we have the ability to form one around some
catalyst.
If we are accepting a contribution based upon its community, the quality of
its code is probably not a pre-determining criteria, and we would be
unlikely to terminate the project when we do see it. On the other hand,
perhaps we might have a group of ASF people interested in some problem
domain, but who feel that without a major starting point, the ramp up effort
is too great. Someone comes along and proposes to contribute a starting
point. In that scenario, the code could be an important desiderata, and we
do risk terminating the project if the community decides that the seed isn't
strong enough.
That said, if there are ASF Members who want to incubate a project, I would
prefer that we give them a chance to succeed, even if the endeavor
ultimately fails. I don't share the concern that "it's code that the ASF
will become responsible for maintaining." I don't see that we have an
obligation to maintain a failed project, although I would put the CVS
tarball in the archives, or preferably just do an svn remove, as an audit
trail. Nor do I believe that there is any requirement for the Incubator to
expend extraordinary efforts to make a project successful beyond that which
ASF Members are willing to contribute as mentors.
An IP pre-review could cause a problem. IP made available for review would
have to be free of encumbrances. We do not want a situation where people
who have reviewed it become tainted. Certainly that can be the case if the
license were a proprietary one, but it does not seem to matter if the
license is an OSI-approved one or not. Claims can be made based upon (L)GPL
as easily as upon more classically recognized proprietary licenses. So, no,
I do not agree that "any legal mechanism that provides for anyone in the
community to conveniently read the source should be acceptable, even if the
license restricts distribution, for instance." If you want it in blunt
terms, I would not want to see a situation where someone can poison the
well. IANAL, but until we have an encumbrance-free contribution, I don't
believe that anyone, including prospective mentors, should be reviewing it.
And since the contributor may not want to sign the Software Grant until a
decision has been made to accept the project, if we make it a *requirement*
to review the code prior to Incubation, we could have a Catch-22.
Therefore, since I feel that we could have valid reasons for accepting a
project without a prior review, and since performing a prior review could
create problems, I'm not sure that we want to make this a mandate, and lose
a perfectly good project.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
-----BEGIN PGP SIGNED MESSAGE-----
Brian Behlendorf wrote:
> It seems to me that any honest assessment of the merit of
> accepting a proposal should include a look at the code itself, if only to
> get a gut-check on how maintainable and evolveable that codebase might be
> going forward.
why? if the idea excites people but the code sucks, are we going to
turn it down?
> Many proposals have provided just such a link despite it
> not being required. Requiring it would also avoid the situation where
> someone says "if Apache approves it *then* I'll release the code".
why do we want to avoid this situation? what business of it is ours
if the submitter wants to entrust their baby to us and only to us?
we should say no when given such an expression of confidence?
- --
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQCVAwUBQPJi85rNPMCpn3XdAQGJbgQAse4g1psWSqcpA/3BdhKK4kRkt3SxIENt
+iiOOmNSRe2FcIFqZEsE1OFzKp6IETWEyrRFy+Zqxn7pzHA6E+0RqczP1ZJE+r42
yVcQQfIPsvJe3RFDN460TL66now9FLFDAQbg+bmOLRErDEyMjr3vuOYijp6PRYC+
wspiBggzGwQ=
=KZ8l
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: proposal: modify incubation application process to require a
reference to the code itself
Posted by Leo Simons <ls...@jicarilla.org>.
Brian Behlendorf wrote:
> In walking through the incubation documents (helping a couple of groups
> who have asked me about how to do this) it struck me that there was no
> requirement that the proposal provide a link to download and evaluate
> the code around which a project is being proposed - in fact it appears
> the code itself could be kept secret until project acceptance into the
> incubator. It seems to me that any honest assessment of the merit of
> accepting a proposal should include a look at the code itself, if only
> to get a gut-check on how maintainable and evolveable that codebase
> might be going forward. Many proposals have provided just such a link
> despite it not being required. Requiring it would also avoid the
> situation where someone says "if Apache approves it *then* I'll release
> the code".
>
> Thoughts?
One of the key requirements is that there's enough people interested in
a project and willing to help. Ensuring that will usually be very
difficult without making code available, but not always. Consider
geronimo. There was no code, but we accepted it anyway (IIRC the board
did, even). Good decision.
I think the right thing to do is to suggest the code is made available
for download so people can evaluate, or otherwise explain why it is not
made available. Something like that.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org