 | 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: | Stefano Bagnara (apa...@bago.org) | |
| Date: | Jun 1, 2008 5:51:58 am | |
| List: | org.apache.legal-discuss | |
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.