www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Tagunov" <anton.tagu...@umail.ru>
Subject Fixing pom.xml issues. Automated approach
Date Fri, 30 May 2008 19:47:51 GMT
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

			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.

With best regards,
Anton Tagunov

DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message