On Mon, Jan 16, 2012 at 6:07 AM, Ross Gardler <rgard...@opendirective.com> wrote: > 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? >
They certainly could. But the categories are really an creature of Apache policy. They are not necessarily relevant to downstream consumers, whose policies could be quite different than ours. That's why it is good that we give the complete details in the LICENSE file rather than some Apache-centric view of the world. That's why I think it would be far more useful to summarize exactly what license applies. We could even make a nice HTML table of this: component, version, original URL, license, etc. >> 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. > That could work. >>> - 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. > We already do that. All of these third party modules are already segregated from the main SVN tree. This is true regardless of license. The legacy project didn't have them under version control. They just stored them on a web server, totally separated from the source code for OOo. That option did not appear to be available to us at Apache, so we stick them in the ext-src directory in SVN. > 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). > Or we could document exactly what we're doing now, the precautions we're already taking. It seems that it would be hard to say whether what we're doing already is inadequate if you don't know what exactly we're already doing. Not you specifically, but in general. >> 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). > Category-b doesn't go out in released source packages. And for binary packages we're already include the required licenses and notifications. >> 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. > That maybe is the piece of the puzzle that may not be clear unless you are a developer building AOO. You do not need to checkout the category-b source bundles from SVN. In fact you should not. You would only be wasting harddrive space. Our build doc doesn't call for these modules to be checked-out. Someone would need to go out of their way to check them out of SVN explicitly. The whole idea is that these are downloaded via the build script, based on the configure options chosen by the builder. If they want to build the default binaries, with no category-b code, then of course, none of these modules are downloaded. And if they want to enable the optional category-b stuff, then they override the configure settings and the bootstrap script downloads the additional components, according to the user's platform. I believe this is done via http requests, not even via an automated svn co. We can't prevent someone from modifying the MPL code. But they would need to go far out of their way to do this. > Ross
