www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <bay...@apache.org>
Subject Re: Fixing pom.xml issues. Automated approach
Date Sat, 31 May 2008 00:53:59 GMT
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 <anton.tagunov@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.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
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


Mime
View raw message