You are viewing a plain text version of this content. The canonical link for it is here.
Posted to repository@apache.org by Robert Burrell Donkin <rd...@apache.org> on 2007/09/30 16:49:32 UTC
POM licensing
many (most?) pom's in the repository lack license information. it's
therefore unclear under what conditions the meta-data can be used or
re-used. this prevents meta-data mining.
since the respository is hosted on apache hardware, IMHO the meta-data
released through the repository should be explicitly licensed under
ALv2.0.
- robert
Re: POM licensing
Posted by Gilles Scokart <gs...@gmail.com>.
2007/10/2, Stefano Bagnara <ap...@bago.org>:
>
> Daniel Kulp ha scritto:
> > Well, I'm not so sure a "released" pom is considered source. There was
> > a discussion about something similar in Geronimo in regards to the Sun
> > schemas. Are they source or more of a binary "contract" and not source
> > that a user would/should be interested in modifying.
> >
> > In the poms case, the release plugin does modify them. Thus, are they
> > considered "generated artifacts"? Generated artifacts could fall into
> > Category B.
>
> Some of the poms submitted have been written from scratch by the
> submitter and not generated, so (at least in this case) they are sources.
Also, some of us (reposiroty users) are building an internal company
repository. Most of the time, the meta data are just a copy of the one
taken on the central repository. But sometimes, we modify it. In that
scénario it is certainly not a binary.
--
Gilles SCOKART
Re: POM licensing
Posted by Stefano Bagnara <ap...@bago.org>.
Daniel Kulp ha scritto:
> Well, I'm not so sure a "released" pom is considered source. There was
> a discussion about something similar in Geronimo in regards to the Sun
> schemas. Are they source or more of a binary "contract" and not source
> that a user would/should be interested in modifying.
>
> In the poms case, the release plugin does modify them. Thus, are they
> considered "generated artifacts"? Generated artifacts could fall into
> Category B.
Some of the poms submitted have been written from scratch by the
submitter and not generated, so (at least in this case) they are sources.
>> - What do we do with non-ASL projects? e.g: javamail is distributed
>> under the CDDL, on the java.net repository they publish their own
>> artifacts and their own poms. The poms do not include any header, so
>> we cannot simply take it and publish it in central and we cannot use
>> it directly because it does not contains license header.
>
> Well. Technically we COULD write our own poms from scratch and submit
> them (and the jar) to central. The CDDL does permit that. (The older
> BCL would not) Definitely a pain to do though.
We definitely have to deal with this some way: having a repository is
cool, but if we don't fix the legal issue it will only be a big flop.
>> Should we
>> write our own descriptors for this artifacts? Wouldn't be a source of
>> confusion if we publish on central poms declaring the same
>> artifactId/groupid of the one published on java.net but including
>> different informations?
>
> That has already happened. :-(
> http://repo1.maven.org/maven2/javax/xml/soap/saaj-api/1.3/
> http://download.java.net/maven/1/javax.xml.soap/poms/
>
> The one on central is more useful for remote-resources (has the license
> information, name, url, etc....) but has a dependency to an artifact not
> at central. The one at java.net has resolvable dependencies, but not
> any of the rest of the useful info.
So if I checkout and build a maven project that does not include a
reference to java.net my installed saaj-api will require
activation:activation:1.0.2 also when I will try to build the project
having java.net in the repositories (the first I checkout and build will
change the behaviour of the other). Very bad :-(
Stefano
Re: POM licensing
Posted by Daniel Kulp <da...@iona.com>.
On Monday 01 October 2007, Stefano Bagnara wrote:
> Daniel Kulp ha scritto:
> > I think there are two issues that are being discussed on this
> > thread:
> >
> > 1) The license of the POM itself
> > 2) The license of the artifacts the pom describes (usually a jar)
> > [...]
> > The first one is a bit trickier. I guess that would be the header
> > that is stuck at the top of the pom. But, as mentioned previously,
> > there are cases where the release plugin strips that header. (I
> > know, the proper fix is it fix the plugin). Also, should the pom
> > be under the same license as the artifact. If the pom has the
> > above lines in it, is that good enough? Good question.
>
> Even if we fix the release plugin, we put an hard oversight on the new
> poms accepted via the "JIRA Upload" workflow, and we add new checks
> for automatically-rsynced repositories to enforce presence of a
> "known" license header on the pom (and I think this would be already a
> BIG effort)
>
> - how do we deal with all of the old poms not having such header?
>
> - Furthermore, what would be the allowed POM licenses? I think we
> should only accept licenses that we are already allowed to
> redistribute within ASF projecs (Category A in
> http://people.apache.org/~cliffs/3party.html, because pom.xml is a
> source, so Category B does not work)
Well, I'm not so sure a "released" pom is considered source. There was
a discussion about something similar in Geronimo in regards to the Sun
schemas. Are they source or more of a binary "contract" and not source
that a user would/should be interested in modifying.
In the poms case, the release plugin does modify them. Thus, are they
considered "generated artifacts"? Generated artifacts could fall into
Category B.
> - What do we do with non-ASL projects? e.g: javamail is distributed
> under the CDDL, on the java.net repository they publish their own
> artifacts and their own poms. The poms do not include any header, so
> we cannot simply take it and publish it in central and we cannot use
> it directly because it does not contains license header.
Well. Technically we COULD write our own poms from scratch and submit
them (and the jar) to central. The CDDL does permit that. (The older
BCL would not) Definitely a pain to do though.
> Should we
> write our own descriptors for this artifacts? Wouldn't be a source of
> confusion if we publish on central poms declaring the same
> artifactId/groupid of the one published on java.net but including
> different informations?
That has already happened. :-(
http://repo1.maven.org/maven2/javax/xml/soap/saaj-api/1.3/
http://download.java.net/maven/1/javax.xml.soap/poms/
The one on central is more useful for remote-resources (has the license
information, name, url, etc....) but has a dependency to an artifact not
at central. The one at java.net has resolvable dependencies, but not
any of the rest of the useful info.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: POM licensing
Posted by Stefano Bagnara <ap...@bago.org>.
Daniel Kulp ha scritto:
> I think there are two issues that are being discussed on this thread:
>
> 1) The license of the POM itself
> 2) The license of the artifacts the pom describes (usually a jar)
> [...]
> The first one is a bit trickier. I guess that would be the header that
> is stuck at the top of the pom. But, as mentioned previously, there
> are cases where the release plugin strips that header. (I know, the
> proper fix is it fix the plugin). Also, should the pom be under the
> same license as the artifact. If the pom has the above lines in it,
> is that good enough? Good question.
Even if we fix the release plugin, we put an hard oversight on the new
poms accepted via the "JIRA Upload" workflow, and we add new checks for
automatically-rsynced repositories to enforce presence of a "known"
license header on the pom (and I think this would be already a BIG effort)
- how do we deal with all of the old poms not having such header?
- Furthermore, what would be the allowed POM licenses? I think we should
only accept licenses that we are already allowed to redistribute within
ASF projecs (Category A in http://people.apache.org/~cliffs/3party.html,
because pom.xml is a source, so Category B does not work)
- What do we do with non-ASL projects? e.g: javamail is distributed
under the CDDL, on the java.net repository they publish their own
artifacts and their own poms. The poms do not include any header, so we
cannot simply take it and publish it in central and we cannot use it
directly because it does not contains license header. Should we write
our own descriptors for this artifacts? Wouldn't be a source of
confusion if we publish on central poms declaring the same
artifactId/groupid of the one published on java.net but including
different informations?
Stefano
Re: POM licensing
Posted by Daniel Kulp <da...@iona.com>.
I think there are two issues that are being discussed on this thread:
1) The license of the POM itself
2) The license of the artifacts the pom describes (usually a jar)
The second is the easy one. IMO, all poms for apache artifacts should
have:
<licenses>
<license>
<name>The Apache Software License, Version 2.0</name>
<url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
<distribution>repo</distribution>
</license>
</licenses>
<organization>
<name>The Apache Software Foundation</name>
<url>http://www.apache.org/</url>
</organization>
either directly in them or inherited from a parent pom. (possibly the
org.apache:apache:pom). IMO, all non-apache poms should ALSO have that
as required meta-data in it. I'd really like it if the sync scripts
would stop syncing stuff that didn't have those entries. Actually, I'd
like it even more if it also required the <url> and <name> elements.
Plugins like the remote-resources plugin use that information and
not-having it really sucks. Auditing the dependencies for license
incompatibilities would be a lot easier. I assume the data-mining that
Robert is trying to do is similar.
The first one is a bit trickier. I guess that would be the header that
is stuck at the top of the pom. But, as mentioned previously, there
are cases where the release plugin strips that header. (I know, the
proper fix is it fix the plugin). Also, should the pom be under the
same license as the artifact. If the pom has the above lines in it,
is that good enough? Good question.
Dan
On Sunday 30 September 2007, Robert Burrell Donkin wrote:
> On Sun, 2007-09-30 at 17:52 +0100, Steve Loughran wrote:
> > On 30/09/2007, Trustin Lee <tr...@gmail.com> wrote:
> > > Isn't it enough for all project POMs to extend
> > > org.apache:apache:pom (currently version 4)?
>
> not sure whether that's good enough from a legal perspective: i'm not
> sure that pom extension necessarily derivation, and even if it did
> then works derived from . much cleaner to have an explicit header.
>
> > -lots of the .pom files aren't in the right namespace
> > - those of us who hand write our pom files dont extend anything from
> > maven. -I've always added author metadata as a comment in pom files
> > I've supplied, primarily to remove the blame from the original team
> > when I was the author of the bad metadata. My incompetence
> > shouldn't be the cause of support calls to other people.
>
> the repository isn't stored in version control so it's more difficult
> to demonstrate provinence postmortem. henri's repository commit's is
> useful but provinence information cannot be recorded in the commit
> message (since there isn't one).
>
> > Interestingly, most RPM .spec files that I've worked with (jpackage,
> > and stuff of my own doing) does include license info.
>
> interesting
>
> just a license (for the collective) or more detailed information?
>
> - robert
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 30/09/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> On Sun, 2007-09-30 at 17:52 +0100, Steve Loughran wrote:
>
> > Interestingly, most RPM .spec files that I've worked with (jpackage,
> > and stuff of my own doing) does include license info.
>
> interesting
>
> just a license (for the collective) or more detailed information?
well, jpackage related stuff is all I've worked with, and they lead by example:
http://www.jpackage.org/template.spec
And as most people doing java RPMs start with these, it propagates
http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/release/metadata/rpm/smartfrog.spec?view=markup
now, I'm not a fan of RPMs (and the jpackage mail list has publicly
denounced me, so I unsubscribed), but with enough effort they can be
made to work. Its just a painful amount of effort and you need to test
on *every* target OS, at least if you want init.d scripts to install
and run properly.
The license info is just comments though; no proper machine readable
content. To be brutal, .spec files themselves are barely machine
readable. They get turned by rpmbuild into a set of scripts that are
guaranteed not to work propery at uninstall time once your OS has
started to get even a hint inconsistent.
-steve
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Sun, 2007-09-30 at 17:52 +0100, Steve Loughran wrote:
> On 30/09/2007, Trustin Lee <tr...@gmail.com> wrote:
>
> >
> > Isn't it enough for all project POMs to extend org.apache:apache:pom
> > (currently version 4)?
not sure whether that's good enough from a legal perspective: i'm not
sure that pom extension necessarily derivation, and even if it did then
works derived from . much cleaner to have an explicit header.
> -lots of the .pom files aren't in the right namespace
> - those of us who hand write our pom files dont extend anything from maven.
> -I've always added author metadata as a comment in pom files I've
> supplied, primarily to remove the blame from the original team when I
> was the author of the bad metadata. My incompetence shouldn't be the
> cause of support calls to other people.
the repository isn't stored in version control so it's more difficult to
demonstrate provinence postmortem. henri's repository commit's is useful
but provinence information cannot be recorded in the commit message
(since there isn't one).
> Interestingly, most RPM .spec files that I've worked with (jpackage,
> and stuff of my own doing) does include license info.
interesting
just a license (for the collective) or more detailed information?
- robert
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 30/09/2007, Trustin Lee <tr...@gmail.com> wrote:
>
> Isn't it enough for all project POMs to extend org.apache:apache:pom
> (currently version 4)?
-lots of the .pom files aren't in the right namespace
- those of us who hand write our pom files dont extend anything from maven.
-I've always added author metadata as a comment in pom files I've
supplied, primarily to remove the blame from the original team when I
was the author of the bad metadata. My incompetence shouldn't be the
cause of support calls to other people.
Interestingly, most RPM .spec files that I've worked with (jpackage,
and stuff of my own doing) does include license info.
-steve
Re: POM licensing
Posted by Trustin Lee <tr...@gmail.com>.
On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
> many (most?) pom's in the repository lack license information. it's
> therefore unclear under what conditions the meta-data can be used or
> re-used. this prevents meta-data mining.
>
> since the respository is hosted on apache hardware, IMHO the meta-data
> released through the repository should be explicitly licensed under
> ALv2.0.
Isn't it enough for all project POMs to extend org.apache:apache:pom
(currently version 4)?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Sun, 2007-09-30 at 21:49 +0100, Steve Loughran wrote:
> On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
<snip>
> > > What MD-mining have you been planning?
> >
> > the discordia lab plans to extract licensing related information to
> > build a artifact->license database (probably using RDF). this can then
> > be used to cross reference to license family meta-data.
>
> My colleague paolo castagna -who was at apachecon EU and is probably
> on the mail list- has done the RDF extraction. I've always been
> meaning to do some walking of the dependency graph.
IIRC i had an interesting chat with Paolo on this very subject @
apachecon
> Paolo? Are you there?
hello again (if you are)
- robert
Re: POM licensing
Posted by Stefano Bagnara <ap...@bago.org>.
Gilles Scokart ha scritto:
> I seriously doubt that pom are not copyrightable. I'm not a lawer, but
> I'm quiet sure that writing a pom for complex project requires a serious
> dose of creativity. Think to the way you can use pom inheritance, or
> think to the number of optional dependencies or verion ranges you can
> use. Someone can even combine via a pom some modules that were even not
> expected by the developpers of the project.
>
> That, combined to the fact that it might be difficult to find back the
> original author of the pom. I think that we have a problem.
>
> Gilles
Sorry for not being "specific".
I was referring to simple poms only including the groupId, artifactId,
license reference and the dependencies.
I also agree that other build informations are probably copyrightable.
We have 2 cases:
poms submitted by the project building the artifacts (maybe because they
use maven or they use an automated tool to deploy the pom). In this case
we can evangelize people to add the licensing.
Otherwise we can have poms written by users for third party libraries:
most time this poms only include the "simple" information above
(artifactId, groupId, license of the artifact, dependencies).
If they are not copyrightable then most of the current central
repository is safe to be used, otherwise I see a big problem because I
think many of the poms there have been simply submitted by "someone"
(not an Apache committer or someone that signed a CLA or flagged "a
grant" in JIRA) and it has to be understood if central has the right to
really redistribute files received in that way, and if we (maven users)
have the rights (we need a use license) to read and use that
informations to build our projects.
Am I too "pessimistic" about the issue?
Stefano
> 2007/10/1, Stefano Bagnara < apache@bago.org <ma...@bago.org>>:
>
> Carlos Sanchez ha scritto:
> > i'm trying to follow this thread and seems that we are talking about
> > two different things:
> >
> > 1) the license of the project the pom describes
> > 2) the license of the pom itself
> >
> > For 1) all apache projects must extend the parent apache pom
> > <parent>
> > <groupId>org.apache</groupId>
> > <artifactId>apache</artifactId>
> > <version>4</version>
> > </parent>
> >
> > For 2) all projects need to add the license header to the pom as they
> > do with any other file in apache svn
>
> The issue is #2. Very few poms in the maven repository have a license
> header, so this would let me thing that we cannot legally use them as
> they don't declare any license and they don't give us any right of use
> or redistribution.
>
> So either the basic informations contained in a pom are not
> copyrightable, or we have to deal with their copyright and licensing.
>
> In the former case everything is ok and we simply need the central
> repository to declare a licensing for its "database" (the collection of
> the poms could be an index/database).
>
> In the latter we have to make sure every pom added to the central comes
> with a license that allow redistribution and allow automated use by
> tools like maven.
>
> WDYT?
>
> Stefano
>
>
>
>
> --
> Gilles SCOKART
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Mon, 2007-10-01 at 22:46 +0100, Steve Loughran wrote:
> On 01/10/2007, Gilles Scokart <gs...@gmail.com> wrote:
> > I seriously doubt that pom are not copyrightable. I'm not a lawer, but I'm
> > quiet sure that writing a pom for complex project requires a serious dose of
> > creativity. Think to the way you can use pom inheritance, or think to the
> > number of optional dependencies or verion ranges you can use. Someone can
> > even combine via a pom some modules that were even not expected by the
> > developpers of the project.
>
> stick some ant stuff inline and you have original work. I dont think
> dependency metadata and other things like are (c), but the
> instructions needed to go from source to working artifacts? Oh yes.
yes, i think so
the expression has copyright. facts themselves do not. see (for example)
http://www.softwarefreedom.org/resources/2007/originality-requirements.html.
in theory, all existing poms in the apache repository should be original
works covered by CLAs unless explicitly marked otherwise (see
http://www.apache.org/licenses/icla.txt section 7). in practice, i have
doubts about that the provinance of most of the meta-data could be
proven.
> > That, combined to the fact that it might be difficult to find back the
> > original author of the pom. I think that we have a problem.
>
> again, this is why I add author info as comments in my poms. Maybe
> someone can go back through all the existing bugreps to identify the
> provider. ouch.
yes: ouch
IMO apache needs to store it's released artifacts in subversion. this
would allow accurate and easy tracking together with commit messages. i
also like the idea of pre-commit hooks.
- robert
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 01/10/2007, Gilles Scokart <gs...@gmail.com> wrote:
> I seriously doubt that pom are not copyrightable. I'm not a lawer, but I'm
> quiet sure that writing a pom for complex project requires a serious dose of
> creativity. Think to the way you can use pom inheritance, or think to the
> number of optional dependencies or verion ranges you can use. Someone can
> even combine via a pom some modules that were even not expected by the
> developpers of the project.
stick some ant stuff inline and you have original work. I dont think
dependency metadata and other things like are (c), but the
instructions needed to go from source to working artifacts? Oh yes.
>
> That, combined to the fact that it might be difficult to find back the
> original author of the pom. I think that we have a problem.
again, this is why I add author info as comments in my poms. Maybe
someone can go back through all the existing bugreps to identify the
provider. ouch.
Re: POM licensing
Posted by Gilles Scokart <gs...@gmail.com>.
I seriously doubt that pom are not copyrightable. I'm not a lawer, but I'm
quiet sure that writing a pom for complex project requires a serious dose of
creativity. Think to the way you can use pom inheritance, or think to the
number of optional dependencies or verion ranges you can use. Someone can
even combine via a pom some modules that were even not expected by the
developpers of the project.
That, combined to the fact that it might be difficult to find back the
original author of the pom. I think that we have a problem.
Gilles
2007/10/1, Stefano Bagnara <ap...@bago.org>:
>
> Carlos Sanchez ha scritto:
> > i'm trying to follow this thread and seems that we are talking about
> > two different things:
> >
> > 1) the license of the project the pom describes
> > 2) the license of the pom itself
> >
> > For 1) all apache projects must extend the parent apache pom
> > <parent>
> > <groupId>org.apache</groupId>
> > <artifactId>apache</artifactId>
> > <version>4</version>
> > </parent>
> >
> > For 2) all projects need to add the license header to the pom as they
> > do with any other file in apache svn
>
> The issue is #2. Very few poms in the maven repository have a license
> header, so this would let me thing that we cannot legally use them as
> they don't declare any license and they don't give us any right of use
> or redistribution.
>
> So either the basic informations contained in a pom are not
> copyrightable, or we have to deal with their copyright and licensing.
>
> In the former case everything is ok and we simply need the central
> repository to declare a licensing for its "database" (the collection of
> the poms could be an index/database).
>
> In the latter we have to make sure every pom added to the central comes
> with a license that allow redistribution and allow automated use by
> tools like maven.
>
> WDYT?
>
> Stefano
>
>
--
Gilles SCOKART
Re: POM licensing
Posted by Stefano Bagnara <ap...@bago.org>.
Carlos Sanchez ha scritto:
> i'm trying to follow this thread and seems that we are talking about
> two different things:
>
> 1) the license of the project the pom describes
> 2) the license of the pom itself
>
> For 1) all apache projects must extend the parent apache pom
> <parent>
> <groupId>org.apache</groupId>
> <artifactId>apache</artifactId>
> <version>4</version>
> </parent>
>
> For 2) all projects need to add the license header to the pom as they
> do with any other file in apache svn
The issue is #2. Very few poms in the maven repository have a license
header, so this would let me thing that we cannot legally use them as
they don't declare any license and they don't give us any right of use
or redistribution.
So either the basic informations contained in a pom are not
copyrightable, or we have to deal with their copyright and licensing.
In the former case everything is ok and we simply need the central
repository to declare a licensing for its "database" (the collection of
the poms could be an index/database).
In the latter we have to make sure every pom added to the central comes
with a license that allow redistribution and allow automated use by
tools like maven.
WDYT?
Stefano
Re: POM licensing
Posted by Carlos Sanchez <ca...@apache.org>.
i'm trying to follow this thread and seems that we are talking about
two different things:
1) the license of the project the pom describes
2) the license of the pom itself
For 1) all apache projects must extend the parent apache pom
<parent>
<groupId>org.apache</groupId>
<artifactId>apache</artifactId>
<version>4</version>
</parent>
For 2) all projects need to add the license header to the pom as they
do with any other file in apache svn
On 10/1/07, Steve Loughran <st...@gmail.com> wrote:
> On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
>
> >
> > > 3. we could make it explicit for all future uploads.
> >
> > that'd do a lot to clarify the status and allow people outside apache to
> > safe copy and use this meta-data
>
> OK. all POMs that I have provided are apache licensed. That includes
> smartfrog poms that are in
> http://smartfrog.sourceforge.net/repository/.
>
> We actually autogenerate all our POMs under Ant from templates that
> have space for a dynamically inserted comment...all we include is
> dependency info. I will change the comment to make it clear that even
> though the libs are all LPGL, these poms are apache licensed.
>
> How does this go?
>
> <property name="pom.comments"
> value="
> Created ${build.date} by ${user.name}.
> This metadata file is published under an Apache license.
> " />
>
> Would that be enough info?
>
> Obviously we should be publishing all this stuff as machine readable
> RDF triplets or something, if you really want to mine the meta-data.
> Then more facts/beliefs would get added during the build /publish
> process, so every pom has a complete audit trail (our comments like to
> do blame assignment, but now that we do releases on shared vmware
> images, that isnt so reliable
>
> >
> > > What MD-mining have you been planning?
> >
> > the discordia lab plans to extract licensing related information to
> > build a artifact->license database (probably using RDF). this can then
> > be used to cross reference to license family meta-data.
>
> My colleague paolo castagna -who was at apachecon EU and is probably
> on the mail list- has done the RDF extraction. I've always been
> meaning to do some walking of the dependency graph.
>
> Paolo? Are you there?
>
> -steve
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
>
> > 3. we could make it explicit for all future uploads.
>
> that'd do a lot to clarify the status and allow people outside apache to
> safe copy and use this meta-data
OK. all POMs that I have provided are apache licensed. That includes
smartfrog poms that are in
http://smartfrog.sourceforge.net/repository/.
We actually autogenerate all our POMs under Ant from templates that
have space for a dynamically inserted comment...all we include is
dependency info. I will change the comment to make it clear that even
though the libs are all LPGL, these poms are apache licensed.
How does this go?
<property name="pom.comments"
value="
Created ${build.date} by ${user.name}.
This metadata file is published under an Apache license.
" />
Would that be enough info?
Obviously we should be publishing all this stuff as machine readable
RDF triplets or something, if you really want to mine the meta-data.
Then more facts/beliefs would get added during the build /publish
process, so every pom has a complete audit trail (our comments like to
do blame assignment, but now that we do releases on shared vmware
images, that isnt so reliable
>
> > What MD-mining have you been planning?
>
> the discordia lab plans to extract licensing related information to
> build a artifact->license database (probably using RDF). this can then
> be used to cross reference to license family meta-data.
My colleague paolo castagna -who was at apachecon EU and is probably
on the mail list- has done the RDF extraction. I've always been
meaning to do some walking of the dependency graph.
Paolo? Are you there?
-steve
Re: POM licensing
Posted by Matthieu Riou <ma...@offthelip.org>.
On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
>
> On Sun, 2007-09-30 at 17:44 +0100, Steve Loughran wrote:
> > On 30/09/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> > > many (most?) pom's in the repository lack license information. it's
> > > therefore unclear under what conditions the meta-data can be used or
> > > re-used. this prevents meta-data mining.
> > >
> > > since the respository is hosted on apache hardware, IMHO the meta-data
> > > released through the repository should be explicitly licensed under
> > > ALv2.0.
> >
> > interesting point.
> >
> > 1. under US law (not EU), indexed data itself isnt really
> > copyrightable. The form might be, but not the index.
>
> yes, AIUI the expression only is copyrightable.
>
> IIRC there is some protection for databases to prevent data mining of
> complete data sets but i doubt that applies in this case
>
> my worry is the automated transformation of that expression into another
> usually requires copyright permission. so, though i might be ok going
> through a pom and writing down it's license, the automated case may not.
> probably a question for legal-discuss...
Interesting, I hadn't thought of the license of the license information.
Assuming the POMs are under the same license as the original work, then an
extraction of it can probably be considered a derived work, no? When does an
index starts becoming an extract of the original? Might be a question for
legal-discuss as you mentioned.
> 2. Anyone who provides the artifacts+nmetadata via a JIRA bugrep may
> > be implicitly licensing it, though since those bugs are filed on
> > codehaus (correct?), that may not hold.
>
> codehaus makes things more difficult. AL2.0 gives apache rights to code
> submitted to apache. i don't think that this applies to code submitted
> through codehaus.
>
> > 3. we could make it explicit for all future uploads.
>
> that'd do a lot to clarify the status and allow people outside apache to
> safe copy and use this meta-data
>
> > What MD-mining have you been planning?
>
> the discordia lab plans to extract licensing related information to
> build a artifact->license database (probably using RDF). this can then
> be used to cross reference to license family meta-data.
>
> - robert
>
>
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Sun, 2007-09-30 at 17:44 +0100, Steve Loughran wrote:
> On 30/09/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> > many (most?) pom's in the repository lack license information. it's
> > therefore unclear under what conditions the meta-data can be used or
> > re-used. this prevents meta-data mining.
> >
> > since the respository is hosted on apache hardware, IMHO the meta-data
> > released through the repository should be explicitly licensed under
> > ALv2.0.
>
> interesting point.
>
> 1. under US law (not EU), indexed data itself isnt really
> copyrightable. The form might be, but not the index.
yes, AIUI the expression only is copyrightable.
IIRC there is some protection for databases to prevent data mining of
complete data sets but i doubt that applies in this case
my worry is the automated transformation of that expression into another
usually requires copyright permission. so, though i might be ok going
through a pom and writing down it's license, the automated case may not.
probably a question for legal-discuss...
> 2. Anyone who provides the artifacts+nmetadata via a JIRA bugrep may
> be implicitly licensing it, though since those bugs are filed on
> codehaus (correct?), that may not hold.
codehaus makes things more difficult. AL2.0 gives apache rights to code
submitted to apache. i don't think that this applies to code submitted
through codehaus.
> 3. we could make it explicit for all future uploads.
that'd do a lot to clarify the status and allow people outside apache to
safe copy and use this meta-data
> What MD-mining have you been planning?
the discordia lab plans to extract licensing related information to
build a artifact->license database (probably using RDF). this can then
be used to cross reference to license family meta-data.
- robert
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 30/09/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> many (most?) pom's in the repository lack license information. it's
> therefore unclear under what conditions the meta-data can be used or
> re-used. this prevents meta-data mining.
>
> since the respository is hosted on apache hardware, IMHO the meta-data
> released through the repository should be explicitly licensed under
> ALv2.0.
interesting point.
1. under US law (not EU), indexed data itself isnt really
copyrightable. The form might be, but not the index.
2. Anyone who provides the artifacts+nmetadata via a JIRA bugrep may
be implicitly licensing it, though since those bugs are filed on
codehaus (correct?), that may not hold.
3. we could make it explicit for all future uploads.
What MD-mining have you been planning?
Re: POM licensing
Posted by Craig L Russell <Cr...@Sun.COM>.
IMHO this is a real problem.
If there is a difference between the published pom from the project's
distribution and the mirrored poms, then the mirrored poms should be
fixed. Stripping the IP notice from a release is a bug plain and
simple, and wherever this has been done it should be fixed.
Craig
On Sep 30, 2007, at 11:00 AM, Robert Burrell Donkin wrote:
> On Sun, 2007-09-30 at 09:44 -0700, Wendy Smoak wrote:
>> On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
>>> many (most?) pom's in the repository lack license information. it's
>>> therefore unclear under what conditions the meta-data can be used or
>>> re-used. this prevents meta-data mining.
>>>
>>> since the respository is hosted on apache hardware, IMHO the meta-
>>> data
>>> released through the repository should be explicitly licensed under
>>> ALv2.0.
>>
>> It should be there (assuming it's present in svn). There was a
>> bug in
>> the release plugin that stripped comments:
>> http://jira.codehaus.org/browse/MRELEASE-180
>
> probably explains why so many are missing
>
> - robert
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Sun, 2007-09-30 at 09:44 -0700, Wendy Smoak wrote:
> On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
> > many (most?) pom's in the repository lack license information. it's
> > therefore unclear under what conditions the meta-data can be used or
> > re-used. this prevents meta-data mining.
> >
> > since the respository is hosted on apache hardware, IMHO the meta-data
> > released through the repository should be explicitly licensed under
> > ALv2.0.
>
> It should be there (assuming it's present in svn). There was a bug in
> the release plugin that stripped comments:
> http://jira.codehaus.org/browse/MRELEASE-180
probably explains why so many are missing
- robert
Re: POM licensing
Posted by Gilles Scokart <gs...@gmail.com>.
2007/10/2, Steve Loughran <st...@gmail.com>:
>
> Unless we are going to a policy that all POMs in the repos are apache
> licensed, the copyright info should be in XML nodes itself, rather
> than just human-parsed comments.
+1
IF multiple license are allowed for poms, soon or later you will need a tool
to check which pom you can use in your context.
But would it be really a problem to have a policy saying that all poms in
the repos are apache licensed (once solved the problem of all the existing
poms that have an unknown license, of curse).
I think that such policy would simplify a lot of things, and would just be a
minor limitation for very few user.
--
Gilles SCOKART
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Tue, 2007-10-09 at 11:26 +0100, Steve Loughran wrote:
> On 08/10/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> >
> > ALv2.0 is safe for inclusion by reference
> >
> > the reason for the long license header is to explain to all the
> > copyright status of the work. apache is granted only a license by it's
> > contributors. the copyright is not assigned but remains in the hands of
> > the authors.
> >
> > > If the whole boilerplate is needed in java files I don't see how it
> > > could be shorted in a pom.xml.
> >
> > apache policy means that the source of apache poms should have the
> > complete boilerplate.
>
>
> ok, so lets confirm this so the changes can go into ant 1.7.1
> metadata, which will be released this month
>
> -every ant POM file needs the normal apache2 header as the java source
> in an XML comment
>
> or
>
> -every ant pom file should have the complete apache license in an XML comment
>
> I dont mind which, I just need to know what changes to make
this is a policy tricky call and IMHO really colelctive input from legal
committee (rather than just me). i'll ping them but invite people over
to the discussion here (since there's no reason why this needs to be
secret).
- robert
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 08/10/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
>
> ALv2.0 is safe for inclusion by reference
>
> the reason for the long license header is to explain to all the
> copyright status of the work. apache is granted only a license by it's
> contributors. the copyright is not assigned but remains in the hands of
> the authors.
>
> > If the whole boilerplate is needed in java files I don't see how it
> > could be shorted in a pom.xml.
>
> apache policy means that the source of apache poms should have the
> complete boilerplate.
ok, so lets confirm this so the changes can go into ant 1.7.1
metadata, which will be released this month
-every ant POM file needs the normal apache2 header as the java source
in an XML comment
or
-every ant pom file should have the complete apache license in an XML comment
I dont mind which, I just need to know what changes to make
-steve
-every
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 08/10/2007, Robert Burrell Donkin <rd...@apache.org> wrote:
> > > Or you go up to RDF triples. Maybe dublin core docs cover this, though
> > > you end up with a bit of the metadata that not enough people will
> > > write. You could always make the presence of pom copyright info
> > > mandatory in all new artifacts, I suppose.
>
> i'm not sure that dublin core covers the nuances well enough (licensor
> verses copyright holder for example) but RDF is good
Yes, I think you'd have to move a long way up the semweb product tree
to come up with the FSF's model of ownership and transitive credit ::)
>
> > I'm not sure this would work, otherwise we would probably already have
> > simpler license headers in our java files.
>
> ALv2.0 is safe for inclusion by reference
ok. will do this in the next releases of whatever I dabble in..
>
> the reason for the long license header is to explain to all the
> copyright status of the work. apache is granted only a license by it's
> contributors. the copyright is not assigned but remains in the hands of
> the authors.
>
> > If the whole boilerplate is needed in java files I don't see how it
> > could be shorted in a pom.xml.
>
> apache policy means that the source of apache poms should have the
> complete boilerplate.
We'll patch the ant ones.
Re: POM licensing
Posted by Robert Burrell Donkin <rd...@apache.org>.
On Tue, 2007-10-02 at 13:26 +0200, Stefano Bagnara wrote:
> Steve Loughran ha scritto:
> > On 02/10/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> >> The solution is to put the copyright below the root element.
> >> See http://svn.apache.org/repos/asf/incubator/servicemix/trunk/pom.xml
> >> In such cases, the header is kept untouched.
> >
> >
> > Unless we are going to a policy that all POMs in the repos are apache
> > licensed, the copyright info should be in XML nodes itself, rather
> > than just human-parsed comments.
> >
> > <pom-copyright licenseuri="http://apache.org/apache/2.0"
> > copyrightholder="http://apache.org/" date="2005-2007" />
neat :-)
but copyrightholder->licensoruri (since copyright is not necessary to
offer a license and the licensor is the entity offer the work under the
given license)
> > Or you go up to RDF triples. Maybe dublin core docs cover this, though
> > you end up with a bit of the metadata that not enough people will
> > write. You could always make the presence of pom copyright info
> > mandatory in all new artifacts, I suppose.
i'm not sure that dublin core covers the nuances well enough (licensor
verses copyright holder for example) but RDF is good
> I'm not sure this would work, otherwise we would probably already have
> simpler license headers in our java files.
ALv2.0 is safe for inclusion by reference
the reason for the long license header is to explain to all the
copyright status of the work. apache is granted only a license by it's
contributors. the copyright is not assigned but remains in the hands of
the authors.
> If the whole boilerplate is needed in java files I don't see how it
> could be shorted in a pom.xml.
apache policy means that the source of apache poms should have the
complete boilerplate.
> The fact that the pom.xml is a "redistributable" often separate from a
> package does not allow us to add a license header referring to a NOTICE
> or LICENSE file in the same package, as we don't have a "same package".
>
> But I think that this specific issue belongs to legal-discuss.
+1
may even need a policy ruling by the legal committee
- robert
Re: POM licensing
Posted by Stefano Bagnara <ap...@bago.org>.
Steve Loughran ha scritto:
> On 02/10/2007, Guillaume Nodet <gn...@gmail.com> wrote:
>> The solution is to put the copyright below the root element.
>> See http://svn.apache.org/repos/asf/incubator/servicemix/trunk/pom.xml
>> In such cases, the header is kept untouched.
>
>
> Unless we are going to a policy that all POMs in the repos are apache
> licensed, the copyright info should be in XML nodes itself, rather
> than just human-parsed comments.
>
> <pom-copyright licenseuri="http://apache.org/apache/2.0"
> copyrightholder="http://apache.org/" date="2005-2007" />
>
> Or you go up to RDF triples. Maybe dublin core docs cover this, though
> you end up with a bit of the metadata that not enough people will
> write. You could always make the presence of pom copyright info
> mandatory in all new artifacts, I suppose.
>
> -steve
I'm not sure this would work, otherwise we would probably already have
simpler license headers in our java files.
If the whole boilerplate is needed in java files I don't see how it
could be shorted in a pom.xml.
The fact that the pom.xml is a "redistributable" often separate from a
package does not allow us to add a license header referring to a NOTICE
or LICENSE file in the same package, as we don't have a "same package".
But I think that this specific issue belongs to legal-discuss.
Maybe we should summarize the legal issues raised in this topic and
submit them to legal-discuss before going deeper with
technical/procedural solutions to the problems we found.
I will post a summary of the issues I collected in a separate message.
Stefano
Re: POM licensing
Posted by Steve Loughran <st...@gmail.com>.
On 02/10/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> The solution is to put the copyright below the root element.
> See http://svn.apache.org/repos/asf/incubator/servicemix/trunk/pom.xml
> In such cases, the header is kept untouched.
Unless we are going to a policy that all POMs in the repos are apache
licensed, the copyright info should be in XML nodes itself, rather
than just human-parsed comments.
<pom-copyright licenseuri="http://apache.org/apache/2.0"
copyrightholder="http://apache.org/" date="2005-2007" />
Or you go up to RDF triples. Maybe dublin core docs cover this, though
you end up with a bit of the metadata that not enough people will
write. You could always make the presence of pom copyright info
mandatory in all new artifacts, I suppose.
-steve
Re: POM licensing
Posted by Guillaume Nodet <gn...@gmail.com>.
The solution is to put the copyright below the root element.
See http://svn.apache.org/repos/asf/incubator/servicemix/trunk/pom.xml
In such cases, the header is kept untouched.
On 10/1/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Wendy Smoak wrote:
> > On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
> >> many (most?) pom's in the repository lack license information. it's
> >> therefore unclear under what conditions the meta-data can be used or
> >> re-used. this prevents meta-data mining.
> >>
> >> since the respository is hosted on apache hardware, IMHO the meta-data
> >> released through the repository should be explicitly licensed under
> >> ALv2.0.
> >
> > It should be there (assuming it's present in svn). There was a bug in
> > the release plugin that stripped comments:
> > http://jira.codehaus.org/browse/MRELEASE-180
> >
> The bug is still in the current version of the release plugin - the fix
> from MRELEASE-180 only fixes some use cases, but not all. See
>
> http://jira.codehaus.org/browse/MRELEASE-255
>
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: POM licensing
Posted by Carsten Ziegeler <cz...@apache.org>.
Wendy Smoak wrote:
> On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
>> many (most?) pom's in the repository lack license information. it's
>> therefore unclear under what conditions the meta-data can be used or
>> re-used. this prevents meta-data mining.
>>
>> since the respository is hosted on apache hardware, IMHO the meta-data
>> released through the repository should be explicitly licensed under
>> ALv2.0.
>
> It should be there (assuming it's present in svn). There was a bug in
> the release plugin that stripped comments:
> http://jira.codehaus.org/browse/MRELEASE-180
>
The bug is still in the current version of the release plugin - the fix
from MRELEASE-180 only fixes some use cases, but not all. See
http://jira.codehaus.org/browse/MRELEASE-255
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: POM licensing
Posted by Wendy Smoak <ws...@gmail.com>.
On 9/30/07, Robert Burrell Donkin <rd...@apache.org> wrote:
> many (most?) pom's in the repository lack license information. it's
> therefore unclear under what conditions the meta-data can be used or
> re-used. this prevents meta-data mining.
>
> since the respository is hosted on apache hardware, IMHO the meta-data
> released through the repository should be explicitly licensed under
> ALv2.0.
It should be there (assuming it's present in svn). There was a bug in
the release plugin that stripped comments:
http://jira.codehaus.org/browse/MRELEASE-180
--
Wendy