incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: clarification on SF license and sandboxes
Date Mon, 06 Nov 2006 20:58:50 GMT
On 11/6/06, Mike Kienenberger <> wrote:
> On 11/6/06, Henri Yandell <> wrote:
> > I'm still confused - why do we allow people to upload attachments that
> > are not intended for inclusion?
> >
> > I can see one very reasonable reason from a user point of view - the
> > example they want to upload is business related and so they want to do
> > their best to explain the problem to us, but not to have us publish
> > those details any further. However that reason doesn't hold up as it's
> > public if it's in our JIRA and if we don't know the license on it,
> > then can we even use it to resolve the issue?
> >
> > What makes an attachment special? Why don't we have to do this for
> > comments and the jira issue itself?
> >
> > Not seeing why we don't just say:  "All issues + attachments are
> > intended for inclusion".
> There's a difference between "I don't want to contribute this code to
> the project code base" versus "I don't want my code published."
> The "no" option means the code is not for inclusion into the project.
> It doesn't necessarily mean that the code is confidential.

What does 'not for inclusion' mean though?

If it's marked that way, can I take bits of the code out of it? Do I
have to worry about looking at that code and then implementing
something in the apache code that does the same thing and getting

For example, what if someone posts a bit of Sun's Java source to the
Harmony JIRA and marks it 'not for inclusion'. There's a world of
meaning in that not for inclusion flag. What's in it for the ASF to
have a not for inclusion option?

I'm not seeing why we allow it - better to say "Anything here is for


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message