www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Section 4.2, and patch build workflows
Date Mon, 25 Apr 2011 00:32:28 GMT
On Sun, Apr 24, 2011 at 8:25 PM, Henri Yandell <bayard@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 <nick@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


Mime
View raw message