On Mon, Sep 26, 2011 at 11:02 PM, Carl Marcum <[email protected]> wrote: > > On 09/26/2011 10:31 PM, Rob Weir wrote: >> <snip>
>> As far as I can tell (and I may be wrong) the way to think of it is like >> this: >> >> 1) When we use a binary in the project (a 3rd party library) then >> having it be ALv2 or compatible is what we want. >> >> 2) When we include 3rd party source in the project, then ALv2 is also >> required, but we might have additional requirements, e.g. >> >> -- small contributions, in the nature of bug fixes and similar >> patches, nothing more required >> >> -- non-trivial code contributions made to the project -- a signed iCLA >> >> -- contribution of existing OSS projects -- signed SGA > > If something like and extension is made available under ALv2 can it be > included it without a SGA? > The relevant procedure is called "IP Clearance", which is described as: "From time to time, an external codebase is brought into the ASF that is not a separate incubating project but still represents a substantial contribution that was not developed within the ASF's source control system and on our public mailing lists. This is a short form of the Incubation checklist, designed to allow code to be imported with alacrity while still providing for oversight." See: http://incubator.apache.org/ip-clearance/index.html and http://incubator.apache.org/ip-clearance/ip-clearance-template.html Each case needs to be examined and documented. From what I can see the SGA is the normal way of doing this. I think the difference between binary and source use in AOOo is important. When we bring source into the project we are inviting other project members, as well as our downstream consumers, to invest their own time into that code base, to maintain and improve it. So it is worth the extra effort to ensure that the source code is unencumbered. With a binary inclusions this is not an issue. -Rob
