On Thu, Jan 12, 2012 at 2:59 PM, Pedro Giffuni <p...@apache.org> wrote: > > --- Gio 12/1/12, Rob Weir <robw...@apache.org> ha scritto: > ... >> >> If you look carefully, you'll see that SVN, via the website >> stuff that is now there, has tons of content now that is in >> incompatible licenses, in the form of GPL and other licensed >> documentation. Ditto for the wiki. Ditto for extensions site. >> These are all hosted by the Apache, on behalf of the project, >> but they are not part of our releases. Are you saying SVN >> must be cleaned of all of that, even if it is not part of our >> releases? >> > > I certainly had understood the policy for website, Wiki and > even the extensions site is that we shouldn't be hosting > copyleft content. There might be a transitory situation during > incubation and some things are still to be decided but even you > have clearly stood in the position where any new content in the > Wiki, etc should be under AL2. >
My point about website content being ALv2 was to give us the flexibility of including website content in a future release. Even online documentation might have a role if it could be bundled in a release, since that would allow downstream consumers to modify that documentation website and reuse it for their products. But it still comes down to the question of what is in a release. >> >> I'm happy to have someone review the issue, if you can >> state what the policy issue is. I simply don't see any >> problem here. We're not including category-b source code >> in our release, period. >> > > I am really not going into this discussion with you again. > > I think the issue is very easy to resolve: drop the > tarballs from SVN and provide sufficient instructions so > that the people doing the builds can download the tarballs > themselves: we even have nice "fetch_tarball.sh" script to > do just that. > The advice we've received in the past is that no policy issue related to a release is resolved simply by moving code. Back up and look at the downstream consumer, the person receiving a release. How do we feature AL as the default? How are we ensuring that category-b is included only by their explicit choice, rather than automatically? How are we ensuring that the downstream consumer has proper notice of the licenses and notices relevant to the code that they are downloading in our releases? How are we avoiding forking MPL components or doing further development work on them? How are we making an effort to push patches upstream? Those are the things we should be careful about. But in an automated script, whether it downloads MPL tarballs from an Apache server or an Apache Extras, I simply don't see any policy concern one way or another there. On the other hand, I do see relevant technical issues, including how do we ensure that we can maintain prior releases, including via security patches, if our binary releases are based on code that is scattered all over the web and which could disappear tomorrow based on the whim of other less stable OSS maintainers, or based on corporations merging or existing the business. I think the only prudent thing we can do is maintain a copy of all of our dependencies. Another way to think of it is this: the rights and obligations of a downstream consumer are invariant over the choice of where the category-b code is downloaded from. Would you agree with that much? If so, I don't see any basis for a policy distinction purely based on the location of the downloaded code. > Pedro. >
