You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by kelvin goodson <ke...@gmail.com> on 2006/11/01 15:47:57 UTC
clarification on SF license and sandboxes
Can anyone tell me if it's OK to put code into a sandbox that has been
attached to a JIRA without granting ASF license?
Thanks
Re: clarification on SF license and sandboxes
Posted by kelvin goodson <ke...@gmail.com>.
thanks, i'll pursue that
On 01/11/06, Craig L Russell <Cr...@sun.com> wrote:
>
> It's best practice to require that contributions be accompanied by
> the checkbox to grant the license. I haven't seen any official Apache
> policy guideline on this subject.
>
> Is the contributor willing to re-attach the file to the JIRA, this
> time with the checkbox ticked? That's the best way to handle it.
>
> Craig
>
> On Nov 1, 2006, at 6:47 AM, kelvin goodson wrote:
>
> > Can anyone tell me if it's OK to put code into a sandbox that has been
> > attached to a JIRA without granting ASF license?
> >
> > Thanks
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: clarification on SF license and sandboxes
Posted by Henri Yandell <fl...@gmail.com>.
Thanks for all the replies by the way. Definitely helping me
understand the other viewpoint (and try to poke holes :) ).
On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
<snip...>
> > How do you know you can use the code to identify and fix the bug?
> >
> > And more confusingly - how do you write a unit test for that bug
> > without taking too much copyright from the example code?
> >
> > Legal-wise (and my understanding of this stuff is always iffy) - I
> > thought that if something wasn't licensed/publically announced in the
> > public domain, that it was 'All Rights Reserved'. So anything that
> > doesn't check the 'code-grant' checkbox seems completely unusable.
>
> I'm certainly no expert on this, but I'd say if someone opens a bug
> report and attaches code to it saying that this is an example
> reproducing the bug, then they've given you the rights to use it to
> identify and fix the bug. In all cases we're assuming the person
> posting the code has the right to grant usage since any other case is
> invalid no matter how they check the box.
>
> Writing a unit tests using their code as a template is separate issue
> which I won't try to address (not qualified).
Yeah, same here. It underlies a more general one though - if something
is not being granted to us, we don't know what the terms are under
which it is being attached.
> Code grant serves another purpose -- it's for explicitly saying "I
> want you to include my code in the project code, and I give you full
> rights to do so".
>
> > From a more ASF-selfish point of view - what are we losing if we don't
> > allow people to put stuff in without granting us the right to use
> > that? Are we going to see lots of people not attaching patches/test
> > code?
>
> It's going to depend on the people, but in general, yes. It's hard
> to get people to attach test code. It's harder still if you expect
> them to independently write a test case for which ASF will get a
> code-grant. If you're only interested in fixing problems for people
> who have time to make code-grant test cases instead of snippets of
> work they are probably doing for-hire, you're going to lose a lot of
> potential contributions.
Is it normal to have permission to publish snippets of for-hire work?
I would have thought that posting such things would break most
people's contracts/NDAs etc. Not allowing a grey-line set of
attachments is a bonus to people in that position I think.
It seems that mostly people would either attach/report-issues that we
can use, or they shouldn't have reported/attached in the first place
for whatever internal legal reason. A policy which allows things to be
published publically, but not be used in code seems pretty unlikely
given the general level of paranoia.
> Some projects may find that acceptable, but
> unless there's a legal reason why it cannot be allowed, why make the
> process any more difficult?
Because we're making the process more difficult by allowing the
option. Apparantly I have to chase up people in Bugzilla to find out
which option they would have checked, and I have to start checking
which option an attachment was flagged under everytime I look at an
attachment in JIRA.
We also have JIRAs that have not migrated to the ASF who do not have
this turned on yet. So they need to be doing the same as Bugzilla
users.
> In my experience, it's rare that such a
> posted example is useful (even for test cases) outside of identifying
> the bug in the first place unless the reporter already wrote a
> standalone (and thus grantable) test case. And in those cases, ask
> the reporter to check the code grant button.
But you think that if they couldn't post that example, that they
wouldn't have reported the bug?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Mike Kienenberger <mk...@gmail.com>.
On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
> On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
> > > On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > > > On 11/6/06, Henri Yandell <fl...@gmail.com> 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
> > > sued?
> > >
> > > 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
> > > inclusion".
> >
> > As you mentioned before, it's typically used to post example code
> > demonstrating a bug. As a project committer, what's in it for me is
> > that I can use the submitted code to identify and fix the bug. The
> > code doesn't have to be apache licensed for me to do that (ASF
> > licensing isn't viral). There's still benefit to the project simply
> > in identifying and fixing bugs even without a code grant to the ASF.
>
> How do you know you can use the code to identify and fix the bug?
>
> And more confusingly - how do you write a unit test for that bug
> without taking too much copyright from the example code?
>
> Legal-wise (and my understanding of this stuff is always iffy) - I
> thought that if something wasn't licensed/publically announced in the
> public domain, that it was 'All Rights Reserved'. So anything that
> doesn't check the 'code-grant' checkbox seems completely unusable.
I'm certainly no expert on this, but I'd say if someone opens a bug
report and attaches code to it saying that this is an example
reproducing the bug, then they've given you the rights to use it to
identify and fix the bug. In all cases we're assuming the person
posting the code has the right to grant usage since any other case is
invalid no matter how they check the box.
Writing a unit tests using their code as a template is separate issue
which I won't try to address (not qualified).
Code grant serves another purpose -- it's for explicitly saying "I
want you to include my code in the project code, and I give you full
rights to do so".
> From a more ASF-selfish point of view - what are we losing if we don't
> allow people to put stuff in without granting us the right to use
> that? Are we going to see lots of people not attaching patches/test
> code?
It's going to depend on the people, but in general, yes. It's hard
to get people to attach test code. It's harder still if you expect
them to independently write a test case for which ASF will get a
code-grant. If you're only interested in fixing problems for people
who have time to make code-grant test cases instead of snippets of
work they are probably doing for-hire, you're going to lose a lot of
potential contributions. Some projects may find that acceptable, but
unless there's a legal reason why it cannot be allowed, why make the
process any more difficult? In my experience, it's rare that such a
posted example is useful (even for test cases) outside of identifying
the bug in the first place unless the reporter already wrote a
standalone (and thus grantable) test case. And in those cases, ask
the reporter to check the code grant button.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 11/6/06, Henri Yandell <fl...@gmail.com> 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
> > sued?
> >
> > 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
> > inclusion".
>
> As you mentioned before, it's typically used to post example code
> demonstrating a bug. As a project committer, what's in it for me is
> that I can use the submitted code to identify and fix the bug. The
> code doesn't have to be apache licensed for me to do that (ASF
> licensing isn't viral). There's still benefit to the project simply
> in identifying and fixing bugs even without a code grant to the ASF.
How do you know you can use the code to identify and fix the bug?
And more confusingly - how do you write a unit test for that bug
without taking too much copyright from the example code?
Legal-wise (and my understanding of this stuff is always iffy) - I
thought that if something wasn't licensed/publically announced in the
public domain, that it was 'All Rights Reserved'. So anything that
doesn't check the 'code-grant' checkbox seems completely unusable.
>From a more ASF-selfish point of view - what are we losing if we don't
allow people to put stuff in without granting us the right to use
that? Are we going to see lots of people not attaching patches/test
code?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Craig L Russell <Cr...@Sun.COM>.
On Nov 6, 2006, at 1:10 PM, Mike Kienenberger wrote:
> On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
>> On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
>> > On 11/6/06, Henri Yandell <fl...@gmail.com> 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
>> sued?
>>
>> 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
>> inclusion".
>
> As you mentioned before, it's typically used to post example code
> demonstrating a bug. As a project committer, what's in it for me is
> that I can use the submitted code to identify and fix the bug. The
> code doesn't have to be apache licensed for me to do that (ASF
> licensing isn't viral). There's still benefit to the project simply
> in identifying and fixing bugs even without a code grant to the ASF.
>
+1
I believe that there you have captured the reason for this statement
in the JIRA "attach file" screen:
<jira>
Contributions intended for inclusion in ASF products (eg. patches,
code) must be licensed to ASF under the terms of the Apache Software
License. Other attachments (eg. log dumps, test cases) need not be.
</jira>
A test case with real domain classes might be needed to demonstrate a
problem, but that should not require the bug submitter to contribute
the domain classes to Apache.
Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: clarification on SF license and sandboxes
Posted by Mike Kienenberger <mk...@gmail.com>.
On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
> On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 11/6/06, Henri Yandell <fl...@gmail.com> 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
> sued?
>
> 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
> inclusion".
As you mentioned before, it's typically used to post example code
demonstrating a bug. As a project committer, what's in it for me is
that I can use the submitted code to identify and fix the bug. The
code doesn't have to be apache licensed for me to do that (ASF
licensing isn't viral). There's still benefit to the project simply
in identifying and fixing bugs even without a code grant to the ASF.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Martin Cooper <ma...@apache.org>.
On 11/6/06, Henri Yandell <fl...@gmail.com> wrote:
>
> On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 11/6/06, Henri Yandell <fl...@gmail.com> 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?
It's probably better to ask this question on the infra@ list, since it's a
lot more likely that the discussion surrounding the explicit addition of
this checkbox happened there rather than here. I'm sure you'd rather have a
definitive answer rather than lots of pure speculation. ;-)
--
Martin Cooper
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
> sued?
>
> 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
> inclusion".
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: clarification on SF license and sandboxes
Posted by Henri Yandell <fl...@gmail.com>.
On 11/6/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 11/6/06, Henri Yandell <fl...@gmail.com> 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
sued?
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
inclusion".
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Mike Kienenberger <mk...@gmail.com>.
On 11/6/06, Henri Yandell <fl...@gmail.com> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Henri Yandell <fl...@gmail.com>.
On 11/4/06, Craig L Russell <Cr...@sun.com> wrote:
> I notice that the current JIRA "attach file" form does not default
> anything, and requires the submitter to choose explicitly the
> copyright status for the submission. (I think this is a change from
> previous behavior, and if so, a very welcome change).
>
> So it's now very clear that the user must choose whether the
> submission is intended as a contribution.
>
> As far as I'm concerned, this issue is now resolved. If a JIRA
> submission is marked as "Attachment not intended for inclusion" it
> should not be used.
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".
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Craig L Russell <Cr...@Sun.COM>.
I notice that the current JIRA "attach file" form does not default
anything, and requires the submitter to choose explicitly the
copyright status for the submission. (I think this is a change from
previous behavior, and if so, a very welcome change).
So it's now very clear that the user must choose whether the
submission is intended as a contribution.
As far as I'm concerned, this issue is now resolved. If a JIRA
submission is marked as "Attachment not intended for inclusion" it
should not be used.
Thanks to everyone who commented.
Craig
On Nov 4, 2006, at 5:08 AM, robert burrell donkin wrote:
> On 11/2/06, Craig L Russell <Cr...@sun.com> wrote:
>> Hi Martin,
>>
>> Thanks for your comments. They seem to contradict what Henri is
>> saying. Can we continue this discussion until we reach some
>> conclusion?
>
> from a legal perspective:
>
> "5. Submission of Contributions. Unless You explicitly state
> otherwise, any Contribution intentionally submitted for inclusion in
> the Work by You to the Licensor shall be under the terms and
> conditions of this License, without any additional terms or
> conditions. Notwithstanding the above, nothing herein shall supersede
> or modify the terms of any separate license agreement you may have
> executed with Licensor regarding such Contributions."
>
> selecting the 'no' checkbox seems to reasonably explicit to me
>
> however, if copyright cannot be claimed on a patch then this is not
> relevant. AIUI US copyright law does not allow copyright to be claimed
> on unoriginal works or technical works capable of only one reasonable
> and correct solution. some bug fixes fall into this category.
>
> so, it isn't always necessary to gain explicit permission but it's
> almost always a good idea.
>
> from an ethically perspective, i think that an effort should be made
> to gain active permission whenever the user does not make their
> intentions clear.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: clarification on SF license and sandboxes
Posted by robert burrell donkin <ro...@gmail.com>.
On 11/2/06, Craig L Russell <Cr...@sun.com> wrote:
> Hi Martin,
>
> Thanks for your comments. They seem to contradict what Henri is
> saying. Can we continue this discussion until we reach some conclusion?
from a legal perspective:
"5. Submission of Contributions. Unless You explicitly state
otherwise, any Contribution intentionally submitted for inclusion in
the Work by You to the Licensor shall be under the terms and
conditions of this License, without any additional terms or
conditions. Notwithstanding the above, nothing herein shall supersede
or modify the terms of any separate license agreement you may have
executed with Licensor regarding such Contributions."
selecting the 'no' checkbox seems to reasonably explicit to me
however, if copyright cannot be claimed on a patch then this is not
relevant. AIUI US copyright law does not allow copyright to be claimed
on unoriginal works or technical works capable of only one reasonable
and correct solution. some bug fixes fall into this category.
so, it isn't always necessary to gain explicit permission but it's
almost always a good idea.
from an ethically perspective, i think that an effort should be made
to gain active permission whenever the user does not make their
intentions clear.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Martin,
Thanks for your comments. They seem to contradict what Henri is
saying. Can we continue this discussion until we reach some conclusion?
Thanks,
Craig
On Nov 1, 2006, at 6:57 PM, Martin Cooper wrote:
> On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
>>
>> Given that there is a checkbox in JIRA, and the fact that this is
>> confusing at least, could we get the checkbox removed, or the policy
>> documented?
>
>
> The point of the checkbox is that if it's checked, you don't need
> to ask
> further. That Bugzilla doesn't have it means that we have to ask,
> which
> generally takes longer. Documenting the policy would be fine, but
> removing
> the checkbox would be a step backwards, IMO, especially since we
> specifically asked for it to be added.
>
> --
> Martin Cooper
>
>
> Craig
>>
>> On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote:
>>
>> > On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
>> >> It's best practice to require that contributions be accompanied by
>> >> the checkbox to grant the license. I haven't seen any official
>> Apache
>> >> policy guideline on this subject.
>> >
>> > Given that Bugzilla doesn't have such a thing - it would seem
>> that it
>> > can't be that critical.
>> >
>> > Hen
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: clarification on SF license and sandboxes
Posted by Martin Cooper <ma...@apache.org>.
On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
>
> Given that there is a checkbox in JIRA, and the fact that this is
> confusing at least, could we get the checkbox removed, or the policy
> documented?
The point of the checkbox is that if it's checked, you don't need to ask
further. That Bugzilla doesn't have it means that we have to ask, which
generally takes longer. Documenting the policy would be fine, but removing
the checkbox would be a step backwards, IMO, especially since we
specifically asked for it to be added.
--
Martin Cooper
Craig
>
> On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote:
>
> > On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
> >> It's best practice to require that contributions be accompanied by
> >> the checkbox to grant the license. I haven't seen any official Apache
> >> policy guideline on this subject.
> >
> > Given that Bugzilla doesn't have such a thing - it would seem that it
> > can't be that critical.
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
>
Re: clarification on SF license and sandboxes
Posted by Craig L Russell <Cr...@Sun.COM>.
Given that there is a checkbox in JIRA, and the fact that this is
confusing at least, could we get the checkbox removed, or the policy
documented?
Craig
On Nov 1, 2006, at 4:11 PM, Henri Yandell wrote:
> On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
>> It's best practice to require that contributions be accompanied by
>> the checkbox to grant the license. I haven't seen any official Apache
>> policy guideline on this subject.
>
> Given that Bugzilla doesn't have such a thing - it would seem that it
> can't be that critical.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: clarification on SF license and sandboxes
Posted by Henri Yandell <fl...@gmail.com>.
On 11/1/06, Craig L Russell <Cr...@sun.com> wrote:
> It's best practice to require that contributions be accompanied by
> the checkbox to grant the license. I haven't seen any official Apache
> policy guideline on this subject.
Given that Bugzilla doesn't have such a thing - it would seem that it
can't be that critical.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: clarification on SF license and sandboxes
Posted by Craig L Russell <Cr...@Sun.COM>.
It's best practice to require that contributions be accompanied by
the checkbox to grant the license. I haven't seen any official Apache
policy guideline on this subject.
Is the contributor willing to re-attach the file to the JIRA, this
time with the checkbox ticked? That's the best way to handle it.
Craig
On Nov 1, 2006, at 6:47 AM, kelvin goodson wrote:
> Can anyone tell me if it's OK to put code into a sandbox that has been
> attached to a JIRA without granting ASF license?
>
> Thanks
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: clarification on SF license and sandboxes
Posted by Martin van den Bemt <ml...@mvdb.net>.
If I am not mistaken, if it is a patch it is already handles by the apache license itself. If it
isn't a patch, I think it's best to ask for the granting specifically..
Mvgr,
Martin
kelvin goodson wrote:
> Can anyone tell me if it's OK to put code into a sandbox that has been
> attached to a JIRA without granting ASF license?
>
> Thanks
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org