 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
5 messages in org.apache.legal-discussRe: Fixing pom.xml issues. Automated ...| From | Sent On | Attachments |
|---|---|---|
| Anton Tagunov | May 30, 2008 12:47 pm | |
| Henri Yandell | May 30, 2008 5:53 pm | |
| Stefano Bagnara | May 31, 2008 4:39 am | |
| Henri Yandell | May 31, 2008 1:38 pm | |
| Stefano Bagnara | Jun 1, 2008 5:51 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Fixing pom.xml issues. Automated approach | Actions... |
|---|---|---|
| From: | Henri Yandell (bay...@apache.org) | |
| Date: | May 30, 2008 5:53:36 pm | |
| List: | org.apache.legal-discuss | |
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.
I don't see the need to declare existing poms as 'unsafe', just any particular ones we've identified as unsafe (ie: a BCL licensed pom).
Hen
On Fri, May 30, 2008 at 12:47 PM, Anton Tagunov <anto...@umail.ru> wrote:
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.
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.
--------------------------------------------------------------------- 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.