You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Nick Burch <ni...@apache.org> on 2011/04/04 14:03:08 UTC
Re: Section 4.2, and patch build workflows
*ping*. Anyone out there know about section 4.2 and patch builds?
Cheers
Nick
On Mon, 21 Mar 2011, Nick Burch wrote:
> Hi All
>
> Largely with my work hat on, I've got a question about section 4.2 of the
> Apache License v2. Specificially, what we need to do, when, how that fits
> into the contribution workflow, and if there are any tools to help...
>
> Section 4 (Redistribution) clause 2 reads:
> "You must cause any modified files to carry prominent notices stating
> that You changed the files"
>
> Now, thinking about a few contribution workflows and how it applies in the
> case of a bug fix or new small feature.
>
> 1 - I post the patch, get a lazy consensus OK, and commit it. I then do
> a snapshot build including the patch for work
> 2 - I post the patch, get the OK, but it depends on another library that
> isn't released yet. It will be committed as soon as the other project
> releases the dependency though. In the mean time, I do a snapshot
> build of the dependency, and a snapshot build of the project including
> the patch.
> 3 - I post a patch to a project I'm not a committer on. While it's being
> discussed, I do a snapshot build with the patch in it.
> 4 - I take a git clone of a project I'm not a committer on, and work up
> my patch in that. I then publish my patch in a public git repo, as
> well as sending in the patch to the project. While the project
> discusses it, I do a snapshot build from my git repo.
>
> For all of these cases, let's say that as well as wanting to distribute the
> patched binary in $DAY_JOB product, I also want to include both the patched
> source (to aid debugging) and the patch itself (to make life easy for both
> $WORK and downstream users)
>
> From reading clause 4.2, it looks like when building the source jar for my
> patched build, I'd need to start adding various notice bits into the source +
> then make sure I don't accidently commit that to Apache's svn at a later
> date...
>
> Is that really the case? And does it apply for all 4 examples? And if so,
> what tools (if any?) do other people use when building their patched source
> jars (and I guess also patched c source trees for use with gdb etc) to ensure
> it matches the license but avoids accidently committing that to svn? And do I
> need to include the "I changed this" stuff in the patch, or only in the
> source bundle?
>
> (If this is already answered somewhere, then I couldn't find it, but I'll be
> happy if someone could point me at it!)
>
> Thanks
> Nick
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Section 4.2, and patch build workflows
Posted by Gilles Scokart <gs...@gmail.com>.
I was thinking the NOTICE file should be kept small, like something
that could be showed in a "About" popup.
Also, putting all the external contributions into a the NOTICE file is
something much stronger than putting it in the source file. Indeed
AL2 imposes to keep the NOTICE file in any redistribution (not the
source file).
[1] is an interresting thread that illustrates the usage of the NOTICE file.
[1] http://markmail.org/thread/xdywc5lhrmlwxexi
Gilles Scokart
On 4 July 2011 01:04, Nick Burch <ni...@apache.org> wrote:
> On Sun, 24 Apr 2011, Henri Yandell wrote:
>>
>> On Sun, Apr 24, 2011 at 5:32 PM, Benson Margulies <bi...@gmail.com>
>> wrote:
>>>
>>> On Sun, Apr 24, 2011 at 8:25 PM, Henri Yandell <ba...@apache.org> wrote:
>>>>
>>>> * "You must cause any modified files to carry prominent notices stating
>>>> that You changed the files"
>>>>
>>>>
>>>> Interesting question. Normally I would include the patch file and
>>>> modify the NOTICE to indicate a change was made. I think AL 2.0 has
>>>> already crossed the bridge of whether a file is independent of its
>>>> NOTICE (ie it isn't). The modified file has a prominent notice that
>>>> links to the license and that then points to the NOTICE file which
>>>> explains the change.
>>>
>>> If you're a lawyer (cause I'm not) I'm about to make a nonsense, but
>>> still,
>>>
>>> The plain English sense of 'cause any ... files to carry prominent
>>> notices' -- to me -- requires a marking in the file. If it wanted
>>> your interpretation, I'd think that it had to say, 'cause ... to carry
>>> prominent notices or to be accompanied by a NOTICE file ... containing
>>> ...'
>>
>> Every file points to the NOTICE file (via its LICENSE) in a prominent
>> way. The weakness in my suggestion is (imo) not in the prominent part,
>> but in the LICENSE itself which only indicates NOTICE files being for
>> attribution/copyright indication. I think that we can consider
>> identifying the modifications to be an area of attribution.
>>
>> The technical issue with my suggestion is that someone copying a file
>> may lose the indication that a change has occurred. They'll also lose
>> any necessary copyright indication/attribution in the NOTICE file as
>> well, which I think is more important. By putting this in the NOTICE
>> file we put both of the items they're meant to identify when re-using,
>> while maintaining a sane technical solution.
>
> Anyone else have any thoughts on this? Personally it seems like a fairly
> simple, workable idea to me
>
> Nick
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Section 4.2, and patch build workflows
Posted by Nick Burch <ni...@apache.org>.
On Sun, 24 Apr 2011, Henri Yandell wrote:
> On Sun, Apr 24, 2011 at 5:32 PM, Benson Margulies <bi...@gmail.com> wrote:
>> On Sun, Apr 24, 2011 at 8:25 PM, Henri Yandell <ba...@apache.org> wrote:
>>> * "You must cause any modified files to carry prominent notices stating
>>> �that You changed the files"
>>>
>>>
>>> Interesting question. Normally I would include the patch file and
>>> modify the NOTICE to indicate a change was made. I think AL 2.0 has
>>> already crossed the bridge of whether a file is independent of its
>>> NOTICE (ie it isn't). The modified file has a prominent notice that
>>> links to the license and that then points to the NOTICE file which
>>> explains the change.
>>
>> If you're a lawyer (cause I'm not) I'm about to make a nonsense, but still,
>>
>> The plain English sense of 'cause any ... files to carry prominent
>> notices' �-- to me -- requires a marking in the file. If it wanted
>> your interpretation, I'd think that it had to say, 'cause ... to carry
>> prominent notices or to be accompanied by a NOTICE file ... containing
>> ...'
>
> Every file points to the NOTICE file (via its LICENSE) in a prominent
> way. The weakness in my suggestion is (imo) not in the prominent part,
> but in the LICENSE itself which only indicates NOTICE files being for
> attribution/copyright indication. I think that we can consider
> identifying the modifications to be an area of attribution.
>
> The technical issue with my suggestion is that someone copying a file
> may lose the indication that a change has occurred. They'll also lose
> any necessary copyright indication/attribution in the NOTICE file as
> well, which I think is more important. By putting this in the NOTICE
> file we put both of the items they're meant to identify when re-using,
> while maintaining a sane technical solution.
Anyone else have any thoughts on this? Personally it seems like a fairly
simple, workable idea to me
Nick
Re: Section 4.2, and patch build workflows
Posted by Henri Yandell <ba...@apache.org>.
On Sun, Apr 24, 2011 at 5:32 PM, Benson Margulies <bi...@gmail.com> wrote:
> On Sun, Apr 24, 2011 at 8:25 PM, Henri Yandell <ba...@apache.org> wrote:
>> * "You must cause any modified files to carry prominent notices stating
>> that You changed the files"
>>
>>
>> Interesting question. Normally I would include the patch file and
>> modify the NOTICE to indicate a change was made. I think AL 2.0 has
>> already crossed the bridge of whether a file is independent of its
>> NOTICE (ie it isn't). The modified file has a prominent notice that
>> links to the license and that then points to the NOTICE file which
>> explains the change.
>
> If you're a lawyer (cause I'm not) I'm about to make a nonsense, but still,
>
> The plain English sense of 'cause any ... files to carry prominent
> notices' -- to me -- requires a marking in the file. If it wanted
> your interpretation, I'd think that it had to say, 'cause ... to carry
> prominent notices or to be accompanied by a NOTICE file ... containing
> ...'
Every file points to the NOTICE file (via its LICENSE) in a prominent
way. The weakness in my suggestion is (imo) not in the prominent part,
but in the LICENSE itself which only indicates NOTICE files being for
attribution/copyright indication. I think that we can consider
identifying the modifications to be an area of attribution.
The technical issue with my suggestion is that someone copying a file
may lose the indication that a change has occurred. They'll also lose
any necessary copyright indication/attribution in the NOTICE file as
well, which I think is more important. By putting this in the NOTICE
file we put both of the items they're meant to identify when re-using,
while maintaining a sane technical solution.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Section 4.2, and patch build workflows
Posted by Benson Margulies <bi...@gmail.com>.
On Sun, Apr 24, 2011 at 8:25 PM, Henri Yandell <ba...@apache.org> wrote:
> * "You must cause any modified files to carry prominent notices stating
> that You changed the files"
>
>
> Interesting question. Normally I would include the patch file and
> modify the NOTICE to indicate a change was made. I think AL 2.0 has
> already crossed the bridge of whether a file is independent of its
> NOTICE (ie it isn't). The modified file has a prominent notice that
> links to the license and that then points to the NOTICE file which
> explains the change.
If you're a lawyer (cause I'm not) I'm about to make a nonsense, but still,
The plain English sense of 'cause any ... files to carry prominent
notices' -- to me -- requires a marking in the file. If it wanted
your interpretation, I'd think that it had to say, 'cause ... to carry
prominent notices or to be accompanied by a NOTICE file ... containing
...'
>
> So no need to plaster notes over the source, put it in the NOTICE. I
> would autogen that by including the patches and appending each patch
> comment to the NOTICE file.
>
> Hen
>
> On Mon, Apr 4, 2011 at 5:03 AM, Nick Burch <ni...@apache.org> wrote:
>> *ping*. Anyone out there know about section 4.2 and patch builds?
>>
>> Cheers
>> Nick
>>
>> On Mon, 21 Mar 2011, Nick Burch wrote:
>>>
>>> Hi All
>>>
>>> Largely with my work hat on, I've got a question about section 4.2 of the
>>> Apache License v2. Specificially, what we need to do, when, how that fits
>>> into the contribution workflow, and if there are any tools to help...
>>>
>>> Section 4 (Redistribution) clause 2 reads:
>>> "You must cause any modified files to carry prominent notices stating
>>> that You changed the files"
>>>
>>> Now, thinking about a few contribution workflows and how it applies in the
>>> case of a bug fix or new small feature.
>>>
>>> 1 - I post the patch, get a lazy consensus OK, and commit it. I then do
>>> a snapshot build including the patch for work
>>> 2 - I post the patch, get the OK, but it depends on another library that
>>> isn't released yet. It will be committed as soon as the other project
>>> releases the dependency though. In the mean time, I do a snapshot
>>> build of the dependency, and a snapshot build of the project including
>>> the patch.
>>> 3 - I post a patch to a project I'm not a committer on. While it's being
>>> discussed, I do a snapshot build with the patch in it.
>>> 4 - I take a git clone of a project I'm not a committer on, and work up
>>> my patch in that. I then publish my patch in a public git repo, as
>>> well as sending in the patch to the project. While the project
>>> discusses it, I do a snapshot build from my git repo.
>>>
>>> For all of these cases, let's say that as well as wanting to distribute
>>> the patched binary in $DAY_JOB product, I also want to include both the
>>> patched source (to aid debugging) and the patch itself (to make life easy
>>> for both $WORK and downstream users)
>>>
>>> From reading clause 4.2, it looks like when building the source jar for my
>>> patched build, I'd need to start adding various notice bits into the source
>>> + then make sure I don't accidently commit that to Apache's svn at a later
>>> date...
>>>
>>> Is that really the case? And does it apply for all 4 examples? And if so,
>>> what tools (if any?) do other people use when building their patched source
>>> jars (and I guess also patched c source trees for use with gdb etc) to
>>> ensure it matches the license but avoids accidently committing that to svn?
>>> And do I need to include the "I changed this" stuff in the patch, or only in
>>> the source bundle?
>>>
>>> (If this is already answered somewhere, then I couldn't find it, but I'll
>>> be happy if someone could point me at it!)
>>>
>>> Thanks
>>> Nick
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Section 4.2, and patch build workflows
Posted by Henri Yandell <ba...@apache.org>.
* "You must cause any modified files to carry prominent notices stating
that You changed the files"
Interesting question. Normally I would include the patch file and
modify the NOTICE to indicate a change was made. I think AL 2.0 has
already crossed the bridge of whether a file is independent of its
NOTICE (ie it isn't). The modified file has a prominent notice that
links to the license and that then points to the NOTICE file which
explains the change.
So no need to plaster notes over the source, put it in the NOTICE. I
would autogen that by including the patches and appending each patch
comment to the NOTICE file.
Hen
On Mon, Apr 4, 2011 at 5:03 AM, Nick Burch <ni...@apache.org> wrote:
> *ping*. Anyone out there know about section 4.2 and patch builds?
>
> Cheers
> Nick
>
> On Mon, 21 Mar 2011, Nick Burch wrote:
>>
>> Hi All
>>
>> Largely with my work hat on, I've got a question about section 4.2 of the
>> Apache License v2. Specificially, what we need to do, when, how that fits
>> into the contribution workflow, and if there are any tools to help...
>>
>> Section 4 (Redistribution) clause 2 reads:
>> "You must cause any modified files to carry prominent notices stating
>> that You changed the files"
>>
>> Now, thinking about a few contribution workflows and how it applies in the
>> case of a bug fix or new small feature.
>>
>> 1 - I post the patch, get a lazy consensus OK, and commit it. I then do
>> a snapshot build including the patch for work
>> 2 - I post the patch, get the OK, but it depends on another library that
>> isn't released yet. It will be committed as soon as the other project
>> releases the dependency though. In the mean time, I do a snapshot
>> build of the dependency, and a snapshot build of the project including
>> the patch.
>> 3 - I post a patch to a project I'm not a committer on. While it's being
>> discussed, I do a snapshot build with the patch in it.
>> 4 - I take a git clone of a project I'm not a committer on, and work up
>> my patch in that. I then publish my patch in a public git repo, as
>> well as sending in the patch to the project. While the project
>> discusses it, I do a snapshot build from my git repo.
>>
>> For all of these cases, let's say that as well as wanting to distribute
>> the patched binary in $DAY_JOB product, I also want to include both the
>> patched source (to aid debugging) and the patch itself (to make life easy
>> for both $WORK and downstream users)
>>
>> From reading clause 4.2, it looks like when building the source jar for my
>> patched build, I'd need to start adding various notice bits into the source
>> + then make sure I don't accidently commit that to Apache's svn at a later
>> date...
>>
>> Is that really the case? And does it apply for all 4 examples? And if so,
>> what tools (if any?) do other people use when building their patched source
>> jars (and I guess also patched c source trees for use with gdb etc) to
>> ensure it matches the license but avoids accidently committing that to svn?
>> And do I need to include the "I changed this" stuff in the patch, or only in
>> the source bundle?
>>
>> (If this is already answered somewhere, then I couldn't find it, but I'll
>> be happy if someone could point me at it!)
>>
>> Thanks
>> Nick
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org