 | 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 31, 2008 1:38:06 pm | |
| List: | org.apache.legal-discuss | |
On Sat, May 31, 2008 at 4:39 AM, Stefano Bagnara <apa...@bago.org> wrote:
Henri Yandell ha scritto:
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.
If a pom is a creative work and people can claim copyright on it then we should treat them as any other piece of code
The ones we create, sure. We (the board) have expressly stated to the Maven PMC that we are happy for the Maven repository to not be treated the same way we treat other third party code - ie) we can redistribute non AL 2.0 compatible licensed works in the repository. I know that's not what you meant, but it's an important point. We are far more like an ISP or a Forge in this case than we are a code foundation.
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.
, 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.
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.
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.
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.
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. 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.
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.
Hen
--------------------------------------------------------------------- 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.