www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Burch <n...@apache.org>
Subject Section 4.2, and patch build workflows
Date Mon, 21 Mar 2011 13:39:06 GMT
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!)


To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message