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. 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. > - 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? Although we have not yet built a script to produce a source package per Apache rules, when we do it will not include any of the /ext-src modules, correct? It won't include the category-a and it will not include the category-b either? What would be the point, since the build script brings down what it needs via the bootstrap, per the configuration flags used? 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. and 2) In the build instructions. 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? I have no objections if you want to shuffle things around in the directory structure, and update bootstrap logic accordingly. It is your time. But given that these files are not included in our releases, I don't think this solves the problem you originally set out to solve. > - It is understood that ext_source_B is a quarantine > area. The idea is that the code we have there will > only shrink with time. The code there can be updated > for security reasons but in general no new code should > be brought in without specific consensus (voting, checking > with the PPMC, etc, but not lazy consensus). > > NOTE: Consensus for replacing standard OOo 3.4 > functionality like the CoinMP solver code is a given > (particularly as the licensing is being worked on) but > we don't want this to be a loophole to bring in MPL'd > code into AOO. > > Of course we still have to comply with the standard > Apache policies concerning Category-B : "Code that is > more substantial, more volatile, or not directly consumed > at runtime in source form may only be distributed in > binary form." but at least now it should be pretty clear > and easy for everyone downloading the code from SVN where > they can expect licensing issues. > > Pedro. >
