www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@apache.org>
Subject Re: Section 4.2, and patch build workflows
Date Mon, 25 Apr 2011 00:25:31 GMT
* "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 <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


Mime
View raw message