Hello ASF legal-hackers :-)

Inspired by recent discussions I'd like to write down several thoughts on dealing with pom.xml-s legal issues.

After I completed writing the mail I have discovered that I what I have written is a kind of action plan. Here it is:

[0] General plan

[0.1] go through transive pom.xml closure of ASF projects figuring out "safe" pom-s.

[0.2] mark "safe" poms

a "safe" pom is a pom for which license is known or which is known to be under the same license as the source code of the artifacts it covers

[0.3] replace "unsafe" poms

new versions of maven/ivy will have "safe-poms-only" mode

[0.4] un-foreseen difficulty

[1] Finding "safe" poms

[1.1] an automated SVN/CVS crawler

for open source projects which publicly expose SVN/CVS repository or HTML browser (viewvc) for it

an automated crawler can determine if pom.xml in maven central is identical to those in project's SVN/CVS

if so pom.xml is "safe" and is covered by the same license as the project source code

[1.2] otherwise pom.xml can be checked for being trivial

if it is identical to what maven would generate and even has no project description it can be declared public domain and is safe

[2] Marking poms as safe

[2.1] a new convention is needed we can agree that pom.xml.license contains license for pom.xml itself

pom.xml.license can uploaded to maven central for "safe" pom-s

[2.2] instead of exact license pom.xml.license can say that pom.xml is under the same license as project source code

[2.3] the convention can allow pom.xml copyright holder to include license info directly into pom.xml not providing pom.xml.license

only when it is a third party that has verified that pom.xml is "safe" pom.license.xml is created

[2.4] additionally a new name for pom.xml can be adopted like "pom-safe.xml"

the purpose of such file is to co-reside with the original pom.xml in maven-central

this is needed for section [3]

[2.5] alternatively to [2.1] + [2.4] a new central repo can be established

it can be hosted by the same parties as the current one but be accessible under a different URL

by its charter only "safe" poms would be uploaded there perhaps it could adopt a closed list of licenses for pom-s there contained

[3] Replacing "un-safe" poms

[3.1] When it has not been possible to establish that a pom is "safe" a new "safe" pom can be generated

[3.2] this would be the most dumb pom automatically generated by maven all unsafe information including project description would be absent

[3.3] not even project site url would be present

[3.4] SVN/CVS links would be taken from the original "unsafe" pom when
available

[3.5] this "safe" pom will need to co-exist with the original "unsafe" pom approach [2.4] or [2.5] can be taken to achive this

we can automatically strip project description etc and proclaim it being under MIT/public domain/etc

[0.2.1] uplodaing pom.xml.license to maven central

[0.2.2] ask maven central to create a new URL like http://repo1.maven.org/maven2-safe/

allow uploading only "safe" pom-s/artifacts there.

these pom-s would either have license info built-in or would be accompanied with pom.xml.license files.

[0.2.3] establishing a new "safe" maven central otherwise proceed as in [0.2.2]

[4] There is one difficutly that saddens me a lot now.

It is related to section [3], replacing "un-safe" poms

Unsafe pom-s can actually be replaced by "dumb" or hand crafted versions.

However the mere act of choosing "groupId" for the project appears to be an act
of creativity. And even the stripped/dump/new pom should have it. Same probably true for "artifactId".

What can we about that? For me the question is open.

Thanks for giving your time to this mail. If the effort is deemed worthy I reckon the text can be put on one of our
wiki-s.