On 15 January 2012 03:29, Rob Weir <robw...@apache.org> wrote: > On Fri, Jan 13, 2012 at 3:27 PM, Pedro Giffuni <p...@apache.org> wrote: >> Hello fellow indians; ;) >> >> I think there is consensus that this is (at least) >> a gray area so I have the following proposal, which >> shouldn't get in the way of having this properly >> solved by legal but which I think should solve at >> least temporarily the issues that we have. It's >> actually very simple but who knows, maybe it's even >> acceptable as a general incubator policy at the ASF. >> >> The ext_source in shall be divided, according to >> the categories of the licenses, into two >> directories in SVN, namely: >> >> ext_source_A >> ext_source_B >> > > This is assuming all 3rd party modules are pure, under a single > license. I don't believe this is always the case.
Then can /should they be put in the most restrictive category? > Why not treat it the way we treat 3rd party modules in releases, e.g., > with a LICENSE and NOTICE file? We could put a LICENSE file in > /ext-src. That would make it clear to anyone who browses that > directory. +1 On one of the projects I work on we require libraries to have a corresponding licences/FOOBAR_license.txt file This then allows some simple machine processing to check the license is correctly recorded against all libraries included. This is built into the build system and automatically flags when something seems to be missing. >> - Ext_source_B shall have a prominent text note that warns >> users that the code there is made available only for >> builder convenience but that the code is in general >> not acceptable for inclusion in Apache source code >> releases. >> > > OK, though this is solving a problem we don't really have, right? I think the point is that it clearly separates out stuff that is OK to stay and stuff that needs to be carefully managed. It's a step towards satisfying those who are concerned about including this source whilst avoiding the need to remove the convenience for developers of having the source available. This separation will make it easier for people to evaluate the impact of these files when it comes to graduation and will serve to signal that there is a process in place for the management of these dependencies (or that there needs to be a process). > So if we really want to give proper notice > to the person downloading our source release, this needs to be done: > 1) In the LICENSE and NOTICE files That has to happen anyway (for cat b licenses). > Putting extra verbiage in the SVN tree that is not included in the > releases -- I don't see the point. Is this to protect casual browsers > of our SVN tree? For me the point is not about casual browers it is about developers like me who don't download source tars but instead checkout from SVN. We can't assume that all such developers will understand the nuances of license compatibility or even bother to check. Ross
