I think we're a long way from requiring a solution - I'm not convinced that the problem is even halfway understood yet.

I know of two use cases:

1) The Maven repository 2) People who want to flatten the Maven repository into the distribution for offline building

The latter in my opinion is a dumb idea and whoever is stuck on that should get over it - you can't do that unless the items you're distributing fall within the AL 2.0 license, and it sounds to me like the people wanting to do that are saying it doesn't. So - no, remove that feature. Both the pedant and the pragmatist will be happy with the removal.

The former however requires discussion.

With the former, a maven repository redistributes various artifacts under many licenses - thus it's only licenses like BCL that are a concern. There are three types of individual who contribute artifacts:

* Maven repository manager * Bundle uploader via JIRA * Sync'd repository owners

The artifacts tend to be:

* a maven-metadata.xml file - this is created by repository managers and (I think) repository owners. * a jar (javadoc, source, binary). Often including a license/notice file. The old style was to only have the license in the zip/archive, so I imagine this is sporadic. * a pom. Rarely with a source header, though likely covered by the license on the zip/archive it is also distributed in.

Both syncing repository owners and bundle uploaders have to prove they are members of the relevant source projects. So there is a level of checking to make sure people aren't randomly uploading someone else's crap.

What is our concern?

We've talked about source headers and licenses, but that's not a concern. There is the very open question of just how much a pom needs in it to be considered copyrightable, and there is the question of whether we want all ASF created poms to have a source header. Neither of these are the real concern of this thread imo (source headers on created (not generated) ASF poms are nice, and we should do that, but it doesn't concern this discussion as we can do what we want with our poms already).

The only concern imo is the right of distribution. If you read the t&c for sf.net, google.code, codeplex etc, they have a right of distribution in there, which I'm guessing also has text that it applies to them, subsidiaries, and partners etc. Currently for the Maven repository this is implied (for bundle uploads) and I'm assuming is verbal rather than written (for rsyncs). It also could be argued that it's not clear that mirrors would also be redistributing.

I'd therefore expect a solution to be more like:

1) Ensure we have a formal syncing agreement that provides distribution rights to Apache and partners with each syncer. 2) Ensure that bundle uploads confer such rights - much the way we have a checkbox in our JIRA. As the JIRA is at Codehaus, we would have to a) confirm that our checkbox solution can apply to a single project at a time rather than all of them (probably not, but I think we could hard code something in there with little trouble) and b) ask Codehaus if that plugin could be added. It could however simply be their being asked to state that when making the issue.