www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: Fixing pom.xml issues. Automated approach
Date Sun, 01 Jun 2008 12:52:21 GMT
Henri Yandell ha scritto:
> Except when we include a dump of the repository in one of our
> distributions - I don't see us putting pain on the repository so we
> can let people embed the repository in Apache distributions without
> having to think about it. In that case, if a pom lacks a source
> header, then go find the author and get a source header added; or
> don't embed in the distribution. Not that there is any real need to
> embed a pom in a distribution - just the jar.

You keep touching this issue, but this is not important at all. It was 
simply an example to make it clear that we currently don't know WHAT we 
are granted to do with things we find in the repository because there 
had not been enough control/requirements/checks to put things there.
It is like trying to incubate a library under an unknown license and 
created by an unknown number of contributors.

>> , and we should talk about
>> "license" and not for "people to confer rights" when uploading the pom to
>> JIRA. If we ask for a license we know what exactly can be done, if you ask
> 
> License is the right word, but we're talking about license in terms of
> a CLA not license in terms of having a source header on the pom. The
> easiest agreement with people would be to have the syncing
> repositories sign a CLA. Source headers are nice, but not essential
> imo.

Ok, then AT LEAST let start writing a CLA and deciding what this CLA 
should make them to agree before uploading stuff there, and let's decide 
what do do with everything there uploaded previously to that CLA.
As an example I would like this CLA to allow derivative works and not 
only redistribution, otherwise when javamail 1.4.2 is out I will have to 
way for the javamail 1.4.1 contributor to upload a new one instead of 
being able to create the 1.4.2 myself and upload it.

>> for a specific set of rights then you will be stuck to that rights once a
>> new tool will require a new way to handle that meta data.
>> As an example if you simply ask rights for redistribution then you will not
>> have the rights to create a derivative work of that one just because a new
>> version of a bundle has been created and the original pom author is no more
>> there. We have to ensure that each pom is published under a very liberal
>> license, or we'll simply create an useless metadata database.
> 
> Agreed that the actual agreement needs to include various bits. That's
> up to a lawyer - my dumb understanding is that the right to 'use' is
> not a copyright right but something people habitually put in there. I
> imagine we would put it in there out of the same "it's simpler" habit.

When you run maven it automatically makes a copy of that stuff in your 
local repository and IMHO it is not "fair use" because it's part of an 
automated process.
Furthermore the content of that artifacts is used as part of the 
building process: sometimes the content of the pom is enough to "alter" 
or "partecipate" to the resulting artifacts (the repository also hosts 
the maven plugins).
I heard in this list that having an automated process that automatically 
download mm-mysql jdpc driver or hibernate without a specific action 
from the user taking notice of this was not allowed: why should we treat 
poms differently?

> We do NOT need to ensure that a pom is published under a very liberal
> license though, the repository takes any artifact thing that can be
> redistributed; the same should hold of a pom. So a GPL artifact can
> have a GPL pom, while a pom for a BCL artifact (which can't be
> distributed) just can't be under the BCL. It doesn't have to be AL
> 2.0.

What I intended is that we HAVE TO require some licensing for that poms, 
so while we are there why don't we ask for a very liberal licensing that 
will permit creation of derivative db, redistributable tools based on 
that metadata and so on?

> Alternatively - we could make the legalese very simple:
> 
> * Syncing providers guarantee that poms they provide are something
> they have rights to AND they are putting them under the public domain.
> * JIRA uploaders confirm they are putting them under the public domain.

This would work for me: "public domain" is liberal enough, I guess.

> That would match the way they are treated - much like HTML pages -
> sites mirror them (Google mirror my site as do Wayback but I've
> permitted neither) and people use ideas in the pages to implement the
> same ideas, but they don't take the content.

Sure, in fact they (google) are sometimes violating copyrights and if 
someone think about suing them they remove the content. Or at least they 
did so until they had more and better lawyers to fight in the court ;-)

> The only use case that
> isn't covered is someone forking a project and taking the pom from the
> repository rather than the original project - so sure they can't do
> that and they need to take the pom from the original source.

If I fork a project under a restrictive license I will not be able to 
publish a derivative pom to the maven repository as "public domain" 
because I don't have enough copyright on that pom to broad the 
licensing. WHat I can do is take the pom they published in public domain 
(assuming public domain allows me to create a derivative work in the 
public domain, too)

> But what do I know. Let's wait until we've got a better problem
> defined, I'm not convinced that treating this like Apache source code
> is the right thing.

I'm happy that finally a more deep discussion started about this. It's 2 
years that I'm worried about this and I tried to wake up this list, the 
repository list and maven list a couple of times, before ;-)

Stefano


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