You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/03/26 11:07:17 UTC
[jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Robert Burrell Donkin ha scritto:
> looks good
>
> only possible issue are those PITA poms without license headers in the
> stage directory :-/
IIRC the issue has been raised [1] in legal-discuss and in repository
lists but we had no solution to the fact that most poms in the maven
repository have no license headers.
For jSieve you found that we had false dependencies and worked out a
good solution that allowed us to remove the whole stage folder (that I
repeat we simply introduced to satisfy a request by Noel to not use
remote repositories to retrieve dependencies during a build). I'm not
sure this can be done for jSPF.
I can raise the issue again on legal discuss but I don't think it is
good to stop releasing because of this issue while all of other PMC are
releasing. Given the current answers we have on the topic I'm not even
sure that the jSieve solution is ok: is it ok for an ASF product to
require remote inclusion of artifacts (POM/metadata) under an unknown
license?
Either the ASF board take a position on the maven repository poms/xmls
or IMHO we can *temporarily* ignore the issue as everyone else is doing.
Maybe you, Noel, Danny or other more experienced ASF members are more
entitled in understanding the entity of this issue and ask the Board to
take this issue into consideration and give us an answer about what to do.
Stefano
[1]
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200710.mbox/%3C19775822.2379651191325380332.JavaMail.root@elysia.void.it%3E
[2]
http://www.mail-archive.com/server-dev@james.apache.org/msg15788.html
http://www.mail-archive.com/server-dev@james.apache.org/msg15805.html
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 2:02 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> So, what to do if junit.pom is under an unacceptable license? Should we
>> create our own pom including almost the same informations and using the
>> same groupId/artifactId ? Should we instead use different
>> groupId/artifactIds
>
> i'd be happy not ship poms and let maven download any meta-data it
> needs. but i don't really understand why we need to shop poms so i'm
> probably missing something important...
I would be happy too. I don't have any special preference. I like to
have the stage in the distribution, but I'm also happy with no stage
folder at all. I introduced the stage folder as you see it now because
JAMES PMC required to have a distribution that could be built offline.
I just want a solution that allow me to release jspf: I don't care of
what we ship in addition to the main jar.
>> >> 2) What licenses should we allow for pom.xml in order to make *legal*
>> >> the current use of the central maven repository?
>> >
>> > again, this question is too broad and open ended: any number of
>> > licenses could be created to achieve this goal.
>> >
>> > apache policy is clear on this point: artifacts distributed from
>> > apache should be under the apache license.
>>
>> I still don't understand if maven central is an ASF resource or not. It
>> includes many non apache licensed products and many poms with unknown
>> license.
>
> if isn't hosted by apache on apache hardware then it isn't an apache
> resource. AIUI the maven central repository is an offshore resource
> used by maven rather than an apache resource.
Then maybe the main asf pom should not include central as the main
repository, but some ASF specific repository that only include known
artifacts that we know we can safely use in our projects.
Unfortunately I understood that the use of the ASF repository
(http://people.apache.org/repo/m2-ibiblio-rsync-repository/) is discouraged.
How can ASF improve this?
>> Furthermore many ASF products include 3rd party artifacts: the 3rd party
>> documents and the category A/B classification is exaclty for this, isn't it?
>>
>> If we find that junit.pom is a CPL licensed file we could include it as
>> long as we don't alter it, right?
>
> possibly: xml documents are the subject of some controversy.
> personally speaking, i'm reasonably happy including them but this is
> not a consensus opinion.
This is my opinion too. Unfortunately I guess the junit.pom has not been
created by the junit authors and is unlikely a CPL artifact.
>> >> 3) Can the license for the pom.xml be described in the xml itself or we
>> >> need the whole license header like the one we would prepend to any other
>> >> xml file? The pom.xml is often a redistributable "as is", without being
>> >> included in a package: does this need a special "license header" ?
>> >
>> > again, too broad and open ended
>> >
>> > a license header is just legal boiler plate that effectively describes
>> > the license for the document
>>
>> All this legal stuff is boring: everything is too broad and open ended ;-)
>>
>> I really don't know how to make this question more specific: if JAMES is
>> going to distribute a pom.xml for james as a standalone artifact (and
>> not as part of a zip/package) what kind of header should we use?
>
> answer: the standard apache boilerplate text
>
>> The "standard ALv2" header is not ok IMHO because it make references to
>> files that will not be there. IMHO a reference in the xml to an URL
>> including the license or the full ALv2 LICENSE file are better solutions
>> but IANAL, yet ;-)
>
> the only file which isn't there is the NOTICE and that's not a big problem
ok.
>> >> The technical/procedural issues for the repository management are:
>> >>
>> >> A) How to tweak the current procedures to avoid publishing of new
>> >> pom.xml without a license or without an acceptable license (BSD, MIT,
>> >> ASL, W3C..., depending on answers about #2 above)
>> >
>> > upload to the apache maven repository should be reasonably covered by
>> > CCLAs, CLAs and JIRA but the audit trial is lacking and so it is
>> > impossible to demonstrate that it's covered
>> >
>> > IMO the maven repository@apache should be under version control
>>
>> Let's make a step back: "apache maven repository" is the repository
>> where we only place ASF products and that is rsynced to central, right?
>
> yes
>
>> The repository I was referring to is instead this one:
>> http://repo1.maven.org/maven2/
>
> this is not an apache repository
So this seems the main issue.
Let's say we can't use the junit.pom because it is in central but we
don't know its license. At the same time we can use (and redistribute)
the junit jar because CPL is declared compatible by the ASF 3rd party
policy.
Either we are able to replace the pom in central with one created by us,
or we are able to create a new pom+jar in central under a different
groupId/artifactId or we are unable to use the "maven way" to ship junit
based products (I guess 99% of maven2 projects use that junit.pom during
the build).
>> >> B) How to deal with the current poms not having a license.
>> >
>> > IMO asking uploaders to add a license header would not be unreasonable
>>
>> For new uploads this could be enforced by rejecting any file without a
>> license: but what we can do to fix the current "mess"? There are
>> thousands poms without license informations (like the junit one we are
>> using in jspf): how can we fix this? Remove all of them from central?
>> Who is responsible for repo1.maven.org/maven2/ ?
>
> AIUI maven.org is not an apache repository. i'm not involved with the
> admin of maven.org so i don't know for sure.
Do you think we should care of this? Maven is an ASF product and use
that repository as the "central". Is this an issue we should care of?
>> Who is sued by the author of junit.pom if this file had all right
>> reserved and repo1.maven.org is redistributing it?
>
> AIUI it's the US, so the basic rule is sue everybody involved and let
> the courts sort out liability. in practice (though) a takedown notice
> would be issued and the contentious IP removed from the site and the
> original uploder persued.
It is not clear who "the original uploader" is here. I guess both who
uploaded to MAVENUPLOAD JIRA and who published the file to
repo1.maven.org have their responsibilities, but more likely the second one.
I think this very person (and if I'm not wrong he is an ASF member, too,
so easier to contact) should be made aware of this responsibility he
takes by publishing content under unknown copyright/license. Maybe this
responsibility is the key to a real solution.
>> >> C) What to do when a pom is already published in a 3rd party repository
>> >> under an incompatible license: we cannot copy it, and probably is not a
>> >> good practice to create another pom with the same artifactId/groupId but
>> >> with different informations.
>> >
>> > either create a new clean pom or accept that we can't ship a pom for
>> > that artifact
>>
>> clean pom make sense: same artifactId/groupId or different one?
>> Most time a pom is really simple and contains basic informations:
>> creating a new pom with the same artifactId/groupId will OFTEN result in
>> a file identical to the original one.
>> In our specific case junit pom is really simple: excluding the
>> "<description>" tag I think that everything else would be created
>> exactly as is in a new pom. They are simply metadata that we write using
>> a standard format.
>> I can create a new pom for junit.
>> The main issue is the artifactId/groupId issue: if we reuse the same
>> artifactId/groupId then we end up with different poms for the same
>> identifier and maven will not be happy with this. At the same time if we
>> use different artifactId/groupId we end up with many duplicates and
>> big issues in manually managing transitive dependencies by replacing
>> "origianl" artifactId/groupId with our "fairly licensed"
>> artifactId/groupIds.
>>
>> Is my doubt clear?
>
> yes
>
> we need to ship those transitive dependencies so this isn't such a worry to me
I don't understand.
I add another info: every pom used is installed in the local repository
by maven, so it is important that a given
groupId:artifactId:version:specifier identificator always results in the
same pom or a pom with identical informations to the one published in
the central repository (that is what maven declare as official by using
it by default).
So if we ship our own junit.pom using the same artifactId/groupId but
with different dependencies (in this case there are no dependencies, but
I'd like to better analyze anyway this scenario anyway) we will probably
brake other maven2 builds (no good)
>> >> D) How to "evangelize" projects to make sure that future pom.xml (and
>> >> other resources like site.xml) includes the license header (e.g: make
>> >> sure maven plugins bugs are solved ASAP and high priority)
>> >
>> > step up and code the required changes...?
>>
>> I don't have (currently) enough knowledge of the maven internals to
>> manage this. My main concern is that my impression is that the maven
>> core team is not aware of this specific issues and they simply are
>> scared of everyone in the ASF telling their own interpretation of what
>> maven have to do or not.
>> If the ASF as a whole could *summarize* what are the minimal "required"
>> steps to make maven usage *legal* and compliant to ASF policies I bet
>> they would be happy to prove that maven can fix this in few changes.
>
> different organisations see legal risk in different ways. apache is a
> long way towards the conservation end of the spectrum: we try to avoid
> legal action by operating clearly and transparently in a lawful and
> ethical manner.
>
> it's a tradeoff. in order to protect release managers at apache, time,
> effort, rules and paperwork are required. apache is often rightly
> criticised for being slow and unagile. this is the price paid. it's
> fine for people to start stuff offshore in a more agile environment:
> the risks are probably minimal or at least it's a reasonably tradeoff.
>
> - robert
I clearly understand this, but this doesn't change my opinion about ASF
as a whole should help maven (an ASF product used by many ASF projects)
to be able to make releases protecting ASF committers.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 2:02 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >>
> >>> apache has access to lawyers but the question needs to be clear and
> >> > one of legality not policy
> >>
> >> Here is the summary I wrote to legal-discuss and repository lists the
> >> past october. I already referenced it in previous mail but maybe a
> >> copy&paste is more explicit:
> >>
> >> --------------------------------------------------------------
> >> "legal issues" summary is:
> >>
> >> 1) Are the "simplest" pom.xml (artifactId+groupId+license
> >> information+dependencies) copyrightable?
> >
> > this is a poor question: too broad and open ended. the correct answer
> > is it depends
> >
> > under US copyright, IMHO many simple pom.xml cannot be copyrightable.
> > however, the only way to be sure would be to test it in court.
> > avoiding court is a major apache aim.
>
> So, what to do if junit.pom is under an unacceptable license? Should we
> create our own pom including almost the same informations and using the
> same groupId/artifactId ? Should we instead use different
> groupId/artifactIds
i'd be happy not ship poms and let maven download any meta-data it
needs. but i don't really understand why we need to shop poms so i'm
probably missing something important...
> >> 2) What licenses should we allow for pom.xml in order to make *legal*
> >> the current use of the central maven repository?
> >
> > again, this question is too broad and open ended: any number of
> > licenses could be created to achieve this goal.
> >
> > apache policy is clear on this point: artifacts distributed from
> > apache should be under the apache license.
>
> I still don't understand if maven central is an ASF resource or not. It
> includes many non apache licensed products and many poms with unknown
> license.
if isn't hosted by apache on apache hardware then it isn't an apache
resource. AIUI the maven central repository is an offshore resource
used by maven rather than an apache resource.
> Furthermore many ASF products include 3rd party artifacts: the 3rd party
> documents and the category A/B classification is exaclty for this, isn't it?
>
> If we find that junit.pom is a CPL licensed file we could include it as
> long as we don't alter it, right?
possibly: xml documents are the subject of some controversy.
personally speaking, i'm reasonably happy including them but this is
not a consensus opinion.
> >> 3) Can the license for the pom.xml be described in the xml itself or we
> >> need the whole license header like the one we would prepend to any other
> >> xml file? The pom.xml is often a redistributable "as is", without being
> >> included in a package: does this need a special "license header" ?
> >
> > again, too broad and open ended
> >
> > a license header is just legal boiler plate that effectively describes
> > the license for the document
>
> All this legal stuff is boring: everything is too broad and open ended ;-)
>
> I really don't know how to make this question more specific: if JAMES is
> going to distribute a pom.xml for james as a standalone artifact (and
> not as part of a zip/package) what kind of header should we use?
answer: the standard apache boilerplate text
> The "standard ALv2" header is not ok IMHO because it make references to
> files that will not be there. IMHO a reference in the xml to an URL
> including the license or the full ALv2 LICENSE file are better solutions
> but IANAL, yet ;-)
the only file which isn't there is the NOTICE and that's not a big problem
> >> The technical/procedural issues for the repository management are:
> >>
> >> A) How to tweak the current procedures to avoid publishing of new
> >> pom.xml without a license or without an acceptable license (BSD, MIT,
> >> ASL, W3C..., depending on answers about #2 above)
> >
> > upload to the apache maven repository should be reasonably covered by
> > CCLAs, CLAs and JIRA but the audit trial is lacking and so it is
> > impossible to demonstrate that it's covered
> >
> > IMO the maven repository@apache should be under version control
>
> Let's make a step back: "apache maven repository" is the repository
> where we only place ASF products and that is rsynced to central, right?
yes
> The repository I was referring to is instead this one:
> http://repo1.maven.org/maven2/
this is not an apache repository
> >> B) How to deal with the current poms not having a license.
> >
> > IMO asking uploaders to add a license header would not be unreasonable
>
> For new uploads this could be enforced by rejecting any file without a
> license: but what we can do to fix the current "mess"? There are
> thousands poms without license informations (like the junit one we are
> using in jspf): how can we fix this? Remove all of them from central?
> Who is responsible for repo1.maven.org/maven2/ ?
AIUI maven.org is not an apache repository. i'm not involved with the
admin of maven.org so i don't know for sure.
> Who is sued by the author of junit.pom if this file had all right
> reserved and repo1.maven.org is redistributing it?
AIUI it's the US, so the basic rule is sue everybody involved and let
the courts sort out liability. in practice (though) a takedown notice
would be issued and the contentious IP removed from the site and the
original uploder persued.
> >> C) What to do when a pom is already published in a 3rd party repository
> >> under an incompatible license: we cannot copy it, and probably is not a
> >> good practice to create another pom with the same artifactId/groupId but
> >> with different informations.
> >
> > either create a new clean pom or accept that we can't ship a pom for
> > that artifact
>
> clean pom make sense: same artifactId/groupId or different one?
> Most time a pom is really simple and contains basic informations:
> creating a new pom with the same artifactId/groupId will OFTEN result in
> a file identical to the original one.
> In our specific case junit pom is really simple: excluding the
> "<description>" tag I think that everything else would be created
> exactly as is in a new pom. They are simply metadata that we write using
> a standard format.
> I can create a new pom for junit.
> The main issue is the artifactId/groupId issue: if we reuse the same
> artifactId/groupId then we end up with different poms for the same
> identifier and maven will not be happy with this. At the same time if we
> use different artifactId/groupId we end up with many duplicates and
> big issues in manually managing transitive dependencies by replacing
> "origianl" artifactId/groupId with our "fairly licensed"
> artifactId/groupIds.
>
> Is my doubt clear?
yes
we need to ship those transitive dependencies so this isn't such a worry to me
> >> D) How to "evangelize" projects to make sure that future pom.xml (and
> >> other resources like site.xml) includes the license header (e.g: make
> >> sure maven plugins bugs are solved ASAP and high priority)
> >
> > step up and code the required changes...?
>
> I don't have (currently) enough knowledge of the maven internals to
> manage this. My main concern is that my impression is that the maven
> core team is not aware of this specific issues and they simply are
> scared of everyone in the ASF telling their own interpretation of what
> maven have to do or not.
> If the ASF as a whole could *summarize* what are the minimal "required"
> steps to make maven usage *legal* and compliant to ASF policies I bet
> they would be happy to prove that maven can fix this in few changes.
different organisations see legal risk in different ways. apache is a
long way towards the conservation end of the spectrum: we try to avoid
legal action by operating clearly and transparently in a lawful and
ethical manner.
it's a tradeoff. in order to protect release managers at apache, time,
effort, rules and paperwork are required. apache is often rightly
criticised for being slow and unagile. this is the price paid. it's
fine for people to start stuff offshore in a more agile environment:
the risks are probably minimal or at least it's a reasonably tradeoff.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>
>>> apache has access to lawyers but the question needs to be clear and
>> > one of legality not policy
>>
>> Here is the summary I wrote to legal-discuss and repository lists the
>> past october. I already referenced it in previous mail but maybe a
>> copy&paste is more explicit:
>>
>> --------------------------------------------------------------
>> "legal issues" summary is:
>>
>> 1) Are the "simplest" pom.xml (artifactId+groupId+license
>> information+dependencies) copyrightable?
>
> this is a poor question: too broad and open ended. the correct answer
> is it depends
>
> under US copyright, IMHO many simple pom.xml cannot be copyrightable.
> however, the only way to be sure would be to test it in court.
> avoiding court is a major apache aim.
So, what to do if junit.pom is under an unacceptable license? Should we
create our own pom including almost the same informations and using the
same groupId/artifactId ? Should we instead use different
groupId/artifactIds
>> 2) What licenses should we allow for pom.xml in order to make *legal*
>> the current use of the central maven repository?
>
> again, this question is too broad and open ended: any number of
> licenses could be created to achieve this goal.
>
> apache policy is clear on this point: artifacts distributed from
> apache should be under the apache license.
I still don't understand if maven central is an ASF resource or not. It
includes many non apache licensed products and many poms with unknown
license.
Furthermore many ASF products include 3rd party artifacts: the 3rd party
documents and the category A/B classification is exaclty for this, isn't it?
If we find that junit.pom is a CPL licensed file we could include it as
long as we don't alter it, right?
>> 3) Can the license for the pom.xml be described in the xml itself or we
>> need the whole license header like the one we would prepend to any other
>> xml file? The pom.xml is often a redistributable "as is", without being
>> included in a package: does this need a special "license header" ?
>
> again, too broad and open ended
>
> a license header is just legal boiler plate that effectively describes
> the license for the document
All this legal stuff is boring: everything is too broad and open ended ;-)
I really don't know how to make this question more specific: if JAMES is
going to distribute a pom.xml for james as a standalone artifact (and
not as part of a zip/package) what kind of header should we use?
The "standard ALv2" header is not ok IMHO because it make references to
files that will not be there. IMHO a reference in the xml to an URL
including the license or the full ALv2 LICENSE file are better solutions
but IANAL, yet ;-)
>> The technical/procedural issues for the repository management are:
>>
>> A) How to tweak the current procedures to avoid publishing of new
>> pom.xml without a license or without an acceptable license (BSD, MIT,
>> ASL, W3C..., depending on answers about #2 above)
>
> upload to the apache maven repository should be reasonably covered by
> CCLAs, CLAs and JIRA but the audit trial is lacking and so it is
> impossible to demonstrate that it's covered
>
> IMO the maven repository@apache should be under version control
Let's make a step back: "apache maven repository" is the repository
where we only place ASF products and that is rsynced to central, right?
The repository I was referring to is instead this one:
http://repo1.maven.org/maven2/
>> B) How to deal with the current poms not having a license.
>
> IMO asking uploaders to add a license header would not be unreasonable
For new uploads this could be enforced by rejecting any file without a
license: but what we can do to fix the current "mess"? There are
thousands poms without license informations (like the junit one we are
using in jspf): how can we fix this? Remove all of them from central?
Who is responsible for repo1.maven.org/maven2/ ?
Who is sued by the author of junit.pom if this file had all right
reserved and repo1.maven.org is redistributing it?
>> C) What to do when a pom is already published in a 3rd party repository
>> under an incompatible license: we cannot copy it, and probably is not a
>> good practice to create another pom with the same artifactId/groupId but
>> with different informations.
>
> either create a new clean pom or accept that we can't ship a pom for
> that artifact
clean pom make sense: same artifactId/groupId or different one?
Most time a pom is really simple and contains basic informations:
creating a new pom with the same artifactId/groupId will OFTEN result in
a file identical to the original one.
In our specific case junit pom is really simple: excluding the
"<description>" tag I think that everything else would be created
exactly as is in a new pom. They are simply metadata that we write using
a standard format.
I can create a new pom for junit.
The main issue is the artifactId/groupId issue: if we reuse the same
artifactId/groupId then we end up with different poms for the same
identifier and maven will not be happy with this. At the same time if we
use different artifactId/groupId we end up with many duplicates and
big issues in manually managing transitive dependencies by replacing
"origianl" artifactId/groupId with our "fairly licensed"
artifactId/groupIds.
Is my doubt clear?
>> D) How to "evangelize" projects to make sure that future pom.xml (and
>> other resources like site.xml) includes the license header (e.g: make
>> sure maven plugins bugs are solved ASAP and high priority)
>
> step up and code the required changes...?
I don't have (currently) enough knowledge of the maven internals to
manage this. My main concern is that my impression is that the maven
core team is not aware of this specific issues and they simply are
scared of everyone in the ASF telling their own interpretation of what
maven have to do or not.
If the ASF as a whole could *summarize* what are the minimal "required"
steps to make maven usage *legal* and compliant to ASF policies I bet
they would be happy to prove that maven can fix this in few changes.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> > apache has access to lawyers but the question needs to be clear and
> > one of legality not policy
>
> Here is the summary I wrote to legal-discuss and repository lists the
> past october. I already referenced it in previous mail but maybe a
> copy&paste is more explicit:
>
> --------------------------------------------------------------
> "legal issues" summary is:
>
> 1) Are the "simplest" pom.xml (artifactId+groupId+license
> information+dependencies) copyrightable?
this is a poor question: too broad and open ended. the correct answer
is it depends
under US copyright, IMHO many simple pom.xml cannot be copyrightable.
however, the only way to be sure would be to test it in court.
avoiding court is a major apache aim.
> 2) What licenses should we allow for pom.xml in order to make *legal*
> the current use of the central maven repository?
again, this question is too broad and open ended: any number of
licenses could be created to achieve this goal.
apache policy is clear on this point: artifacts distributed from
apache should be under the apache license.
> 3) Can the license for the pom.xml be described in the xml itself or we
> need the whole license header like the one we would prepend to any other
> xml file? The pom.xml is often a redistributable "as is", without being
> included in a package: does this need a special "license header" ?
again, too broad and open ended
a license header is just legal boiler plate that effectively describes
the license for the document
> The technical/procedural issues for the repository management are:
>
> A) How to tweak the current procedures to avoid publishing of new
> pom.xml without a license or without an acceptable license (BSD, MIT,
> ASL, W3C..., depending on answers about #2 above)
upload to the apache maven repository should be reasonably covered by
CCLAs, CLAs and JIRA but the audit trial is lacking and so it is
impossible to demonstrate that it's covered
IMO the maven repository@apache should be under version control
> B) How to deal with the current poms not having a license.
IMO asking uploaders to add a license header would not be unreasonable
> C) What to do when a pom is already published in a 3rd party repository
> under an incompatible license: we cannot copy it, and probably is not a
> good practice to create another pom with the same artifactId/groupId but
> with different informations.
either create a new clean pom or accept that we can't ship a pom for
that artifact
> D) How to "evangelize" projects to make sure that future pom.xml (and
> other resources like site.xml) includes the license header (e.g: make
> sure maven plugins bugs are solved ASAP and high priority)
step up and code the required changes...?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> you can post but not subscribe to legal-private but i recommend
> legal-discuss as your first port of call
Danny can take any legal issues that need attention to legal-internal.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 6:19 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Sat, Mar 29, 2008 at 4:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> >> BTW, what are the "committee lists" ? server-dev@james ? private@james ?
> >> legal-discuss ? repository ?
> >
> > in addition to the project management committees, there are a number
> > of other official committees for example the legal committee. these
> > have associated mailing lists. in the case of legal, these are legal
> > discuss and legal private.
>
> So, what address should I use in this case ? legal-discuss?
> I guess I can't see legal-private.
you can post but not subscribe to legal-private but i recommend
legal-discuss as your first port of call
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 4:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> BTW, what are the "committee lists" ? server-dev@james ? private@james ?
>> legal-discuss ? repository ?
>
> in addition to the project management committees, there are a number
> of other official committees for example the legal committee. these
> have associated mailing lists. in the case of legal, these are legal
> discuss and legal private.
So, what address should I use in this case ? legal-discuss?
I guess I can't see legal-private.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 4:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
>
> > On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > <snip>
> >
> >> My opinion is that the whole issue should be an HIGH priority for the
> >> ASF but I'm not entitled in spamming the lists to give this more
> >> visibility. Maybe you or another *member* would be taken in better
> >> consideration.
> >
> > stefano - you misunderstand the difference between the PPMCer and
> > member role. henri has posted a good diagam here:
> > http://blog.generationjava.com/roller/bayard/entry/821
> >
> > this is an issue for JAMES and the JAMES PPMC not the membership.
> > you're on the PPMC and have every right to push this issue forward.
> > you are absolutely entitled to repeatedly post on committee lists
> > until someone gives you an answer. if the committees aren't listening
> > after a reasonable attempt to raise the visibility of the issue then
> > you should ask the board to look into it for you.
> >
> > - robert
>
> Thank you for the procedure explanation (I think I understood what is a
> PMC member and what is an ASF member.. and I think that a member has a
> real legal role inside the ASF while a PMC member only has a role given
> by the ASF itself and not by the law. That's why I say that a member
> would be taken in better consideration. I don't know specific US laws,
> but I know how foundations works here).
that's not quite right. PMC members have official legal status within
apache and can act on behalf of apache. the members own apache.
> BTW, what are the "committee lists" ? server-dev@james ? private@james ?
> legal-discuss ? repository ?
in addition to the project management committees, there are a number
of other official committees for example the legal committee. these
have associated mailing lists. in the case of legal, these are legal
discuss and legal private.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
>
> <snip>
>
>> My opinion is that the whole issue should be an HIGH priority for the
>> ASF but I'm not entitled in spamming the lists to give this more
>> visibility. Maybe you or another *member* would be taken in better
>> consideration.
>
> stefano - you misunderstand the difference between the PPMCer and
> member role. henri has posted a good diagam here:
> http://blog.generationjava.com/roller/bayard/entry/821
>
> this is an issue for JAMES and the JAMES PPMC not the membership.
> you're on the PPMC and have every right to push this issue forward.
> you are absolutely entitled to repeatedly post on committee lists
> until someone gives you an answer. if the committees aren't listening
> after a reasonable attempt to raise the visibility of the issue then
> you should ask the board to look into it for you.
>
> - robert
Thank you for the procedure explanation (I think I understood what is a
PMC member and what is an ASF member.. and I think that a member has a
real legal role inside the ASF while a PMC member only has a role given
by the ASF itself and not by the law. That's why I say that a member
would be taken in better consideration. I don't know specific US laws,
but I know how foundations works here).
BTW, what are the "committee lists" ? server-dev@james ? private@james ?
legal-discuss ? repository ?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Mar 28, 2008 at 11:40 AM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> My opinion is that the whole issue should be an HIGH priority for the
> ASF but I'm not entitled in spamming the lists to give this more
> visibility. Maybe you or another *member* would be taken in better
> consideration.
stefano - you misunderstand the difference between the PPMCer and
member role. henri has posted a good diagam here:
http://blog.generationjava.com/roller/bayard/entry/821
this is an issue for JAMES and the JAMES PPMC not the membership.
you're on the PPMC and have every right to push this issue forward.
you are absolutely entitled to repeatedly post on committee lists
until someone gives you an answer. if the committees aren't listening
after a reasonable attempt to raise the visibility of the issue then
you should ask the board to look into it for you.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> apache has access to lawyers but the question needs to be clear and
> one of legality not policy
Here is the summary I wrote to legal-discuss and repository lists the
past october. I already referenced it in previous mail but maybe a
copy&paste is more explicit:
--------------------------------------------------------------
"legal issues" summary is:
1) Are the "simplest" pom.xml (artifactId+groupId+license
information+dependencies) copyrightable?
2) What licenses should we allow for pom.xml in order to make *legal*
the current use of the central maven repository?
3) Can the license for the pom.xml be described in the xml itself or we
need the whole license header like the one we would prepend to any other
xml file? The pom.xml is often a redistributable "as is", without being
included in a package: does this need a special "license header" ?
The technical/procedural issues for the repository management are:
A) How to tweak the current procedures to avoid publishing of new
pom.xml without a license or without an acceptable license (BSD, MIT,
ASL, W3C..., depending on answers about #2 above)
B) How to deal with the current poms not having a license.
C) What to do when a pom is already published in a 3rd party repository
under an incompatible license: we cannot copy it, and probably is not a
good practice to create another pom with the same artifactId/groupId but
with different informations.
D) How to "evangelize" projects to make sure that future pom.xml (and
other resources like site.xml) includes the license header (e.g: make
sure maven plugins bugs are solved ASAP and high priority)
Stefano
------------------------------------------------------------------
My opinion is that the whole issue should be an HIGH priority for the
ASF but I'm not entitled in spamming the lists to give this more
visibility. Maybe you or another *member* would be taken in better
consideration.
I can give more details on each of the questions described above, if needed.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> i see no reason why maven shouldn't be used for development and online
> builds. if no one beats me to it, i should be able to knock up an ant
> script for offline builds (though it might be next week).
I fixed the minor issues (jar versions) in the current build.xml and I
tested it can build the jar and run tests.
I didn't test if it creates a redistributable jar (NOTICE/LICENSE
stuff), but it is not our main build tool, so I would say this should
not be an issue.
I also created an "original" version of junit-3.8.1.pom that should fix
our issues.
Comparing my result with the original one there are minor differences
that should not break any maven build (even if it will possibly alter
maven results like licenses reports, and other reports using the
different metadata).
<sad>I would have liked much more to find a real solution to the
"maven+stage folder" issue, but this seems too difficult and after this
long thread I don't see a clear path to fix this.</sad>
The only other m2 based product we ship is mime4j and its dependencies
are similar to jspf, so we can apply the same solution to mime4j too and
we can delay to the next year the maven+stage issue. In mime4j it will
be much more difficult to add the ant tool because we use much more
plugins (javacc/jjtree) so I would probably go for the use of my
junit-3.8.1.pom
BTW now that I created an alternative pom, updated the build.xml and
updated every other missing license header issue I'll leave to someone
else the next step.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Mar 31, 2008 at 9:08 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Mon, Mar 31, 2008 at 8:48 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
> > On Mon, Mar 31, 2008 at 7:53 PM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> > why not just use an ant script for offline builds?
>
> +1
>
> the website generation aspect excluded, I don't get it why removing
> maven is not already discussed as an obvious option here.
> if we find that maven causes us non-technical problems - and this
> thread is definitively proving this - , we are free to not use it.
i have no problem with maven as the main build tool but offline builds
are not the primary use case for maven
> I downloaded the 0.9.5er source distribution today and it does not
> build with ant, only maven. it downloads a ridiculous large number of
> jars for very little effect. I remember that I +1'ed maven usage for
> building the site. but (hereby also answering a prev question asked on
> this thread) the rest should work with ant and offline, please. :-)
i see no reason why maven shouldn't be used for development and online
builds. if no one beats me to it, i should be able to knock up an ant
script for offline builds (though it might be next week).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [jSPF] poms, copyright, license, again... (Was: [VOTE]jSPF-0.9.6)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I don't get it why removing maven is not already discussed as an obvious
option here.
+1
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE]
jSPF-0.9.6)
Posted by Norman Maurer <no...@apache.org>.
Am Dienstag, den 01.04.2008, 01:14 +0200 schrieb Stefano Bagnara:
> Bernd Fondermann ha scritto:
> >> why not just use an ant script for offline builds?
> >
> > +1
> >
> > the website generation aspect excluded, I don't get it why removing
> > maven is not already discussed as an obvious option here.
> > if we find that maven causes us non-technical problems - and this
> > thread is definitively proving this - , we are free to not use it.
> > I downloaded the 0.9.5er source distribution today and it does not
> > build with ant, only maven. it downloads a ridiculous large number of
> > jars for very little effect. I remember that I +1'ed maven usage for
> > building the site. but (hereby also answering a prev question asked on
> > this thread) the rest should work with ant and offline, please. :-)
> >
> > Thanks,
> >
> > Bernd
>
> The main build tool for jSPF has always been maven. The build.xml that
> was there has been requested by someone and it was created automatically
> by maven. I was against it because I know the ant plugin for maven was
> not so good and the resulting build.xml was to be maintained (and as you
> see it doesn't work). BTW it was intended as a facility for people not
> having maven and not as *the* build tool for jSPF. I just updated the
> dependency versions inside that file so it should work now. Having to
> update the build.xml manually each time we change the pom.xml is a PITA
> (we're going to forget this at each release): any better option?
>
> Other products we ships use ant as their build tool, but jSPF always
> used maven, since the first checkin. IIRC we didn't had the vote you are
> referring about using maven for the website build and ant for the source
> build for jSPF.
>
> Here is my -0 for moving to ant as the main build tool for jSPF. This
> move would simply increase the complexity of managing jSPF lifecycle for me.
>
> Stefano
>
-0 from me too...
Cheers
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
>> why not just use an ant script for offline builds?
>
> +1
>
> the website generation aspect excluded, I don't get it why removing
> maven is not already discussed as an obvious option here.
> if we find that maven causes us non-technical problems - and this
> thread is definitively proving this - , we are free to not use it.
> I downloaded the 0.9.5er source distribution today and it does not
> build with ant, only maven. it downloads a ridiculous large number of
> jars for very little effect. I remember that I +1'ed maven usage for
> building the site. but (hereby also answering a prev question asked on
> this thread) the rest should work with ant and offline, please. :-)
>
> Thanks,
>
> Bernd
The main build tool for jSPF has always been maven. The build.xml that
was there has been requested by someone and it was created automatically
by maven. I was against it because I know the ant plugin for maven was
not so good and the resulting build.xml was to be maintained (and as you
see it doesn't work). BTW it was intended as a facility for people not
having maven and not as *the* build tool for jSPF. I just updated the
dependency versions inside that file so it should work now. Having to
update the build.xml manually each time we change the pom.xml is a PITA
(we're going to forget this at each release): any better option?
Other products we ships use ant as their build tool, but jSPF always
used maven, since the first checkin. IIRC we didn't had the vote you are
referring about using maven for the website build and ant for the source
build for jSPF.
Here is my -0 for moving to ant as the main build tool for jSPF. This
move would simply increase the complexity of managing jSPF lifecycle for me.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, Mar 31, 2008 at 8:48 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
>
> On Mon, Mar 31, 2008 at 7:53 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > Robert Burrell Donkin ha scritto:
> > > On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > >> >> The funny thing is that all of this thread is about a "stupid" pom that
> > >> >> even my father could write as is if I explain him the pom
> > >> >> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
> > >> >> scare me: the fact that we don't have a clear way to rewrite this
> > >> >> f***ing xml from scratch and release jSPF-0.9.7.
> > >
> > > under US copyright law, only the expression and not the facts would
> > > have been copyrightable. if it were me, i would have simply created a
> > > clean room implementation and been done with it.
> > >
> > > or just deleted the pom altogether
> >
> > My main concern is being diligent in not creating further problems to
> > maven users, so I would like to avoid the creation of metadata different
> > from the one published in central.
> >
> > This mean that I would not like to create a new junit.pom with the same
> > groupId/artifactId but with different data (in this very specific case
> > the pom we can create from scratch is almost identical to the original
> > one so we could even take this way).
> >
> > Also, removing the pom means that maven tries to download it but if it
> > is disconnected or it is ran in offline mode then it will create an
> > "empty" pom including only the artifactId/groupId/version stuff. Again
> > this would be different but for this very specific case (junit.pom) it
> > would work.
> >
> > In both case the risk is that we place a different junit.pom: if some
> > other m2 based project used by our users depends on license data,
> > description or other stuff declared in the junit.pom we are likely to
> > break their build.
>
> IMHO this is a maven issue: it should really mark any poms it creates
> and then download replacements once on line again
>
>
> > Another "hack" could be renaming junit-3.8.1.jar to myjunit-3.8.1.jar or
> > junit-3.8.1-custom.jar, declare our dependency on that specific jar and
> > declare a dependency exclusion for every other depedency depending on
> > junit. This would place a custom artifact in the build process/local
> > repository but would not break other builds. (something tells me we
> > already made this analysis for jsieve, before you found the alternative
> > solution).
> >
> > Maybe we should ask to maven lists what is better to do (IIRC I already
> > asked this in past, receiving no answers...).
>
> why not just use an ant script for offline builds?
+1
the website generation aspect excluded, I don't get it why removing
maven is not already discussed as an obvious option here.
if we find that maven causes us non-technical problems - and this
thread is definitively proving this - , we are free to not use it.
I downloaded the 0.9.5er source distribution today and it does not
build with ant, only maven. it downloads a ridiculous large number of
jars for very little effect. I remember that I +1'ed maven usage for
building the site. but (hereby also answering a prev question asked on
this thread) the rest should work with ant and offline, please. :-)
Thanks,
Bernd
PS: the website links downloadunstable.cgi and points to a beta build.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Mar 31, 2008 at 7:53 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> >> >> The funny thing is that all of this thread is about a "stupid" pom that
> >> >> even my father could write as is if I explain him the pom
> >> >> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
> >> >> scare me: the fact that we don't have a clear way to rewrite this
> >> >> f***ing xml from scratch and release jSPF-0.9.7.
> >
> > under US copyright law, only the expression and not the facts would
> > have been copyrightable. if it were me, i would have simply created a
> > clean room implementation and been done with it.
> >
> > or just deleted the pom altogether
>
> My main concern is being diligent in not creating further problems to
> maven users, so I would like to avoid the creation of metadata different
> from the one published in central.
>
> This mean that I would not like to create a new junit.pom with the same
> groupId/artifactId but with different data (in this very specific case
> the pom we can create from scratch is almost identical to the original
> one so we could even take this way).
>
> Also, removing the pom means that maven tries to download it but if it
> is disconnected or it is ran in offline mode then it will create an
> "empty" pom including only the artifactId/groupId/version stuff. Again
> this would be different but for this very specific case (junit.pom) it
> would work.
>
> In both case the risk is that we place a different junit.pom: if some
> other m2 based project used by our users depends on license data,
> description or other stuff declared in the junit.pom we are likely to
> break their build.
IMHO this is a maven issue: it should really mark any poms it creates
and then download replacements once on line again
> Another "hack" could be renaming junit-3.8.1.jar to myjunit-3.8.1.jar or
> junit-3.8.1-custom.jar, declare our dependency on that specific jar and
> declare a dependency exclusion for every other depedency depending on
> junit. This would place a custom artifact in the build process/local
> repository but would not break other builds. (something tells me we
> already made this analysis for jsieve, before you found the alternative
> solution).
>
> Maybe we should ask to maven lists what is better to do (IIRC I already
> asked this in past, receiving no answers...).
why not just use an ant script for offline builds?
> >> You may have noticed that we only get 2 +1 ;-)
> >> So I'd like to know what exactly we have to do to get the 3rd +1, either
> >> by you or by someone of the other PMC members!
> >
> > i count +1s from yourself danny and norman: that should be sufficient
> >
> > - robert
>
> I think Danny voted +0, the "thank goodness one +1!" was a reply to my
> +1 and not a vote, I guess :-(
no, you're right
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> The funny thing is that all of this thread is about a "stupid" pom that
>> >> even my father could write as is if I explain him the pom
>> >> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
>> >> scare me: the fact that we don't have a clear way to rewrite this
>> >> f***ing xml from scratch and release jSPF-0.9.7.
>
> under US copyright law, only the expression and not the facts would
> have been copyrightable. if it were me, i would have simply created a
> clean room implementation and been done with it.
>
> or just deleted the pom altogether
My main concern is being diligent in not creating further problems to
maven users, so I would like to avoid the creation of metadata different
from the one published in central.
This mean that I would not like to create a new junit.pom with the same
groupId/artifactId but with different data (in this very specific case
the pom we can create from scratch is almost identical to the original
one so we could even take this way).
Also, removing the pom means that maven tries to download it but if it
is disconnected or it is ran in offline mode then it will create an
"empty" pom including only the artifactId/groupId/version stuff. Again
this would be different but for this very specific case (junit.pom) it
would work.
In both case the risk is that we place a different junit.pom: if some
other m2 based project used by our users depends on license data,
description or other stuff declared in the junit.pom we are likely to
break their build.
Another "hack" could be renaming junit-3.8.1.jar to myjunit-3.8.1.jar or
junit-3.8.1-custom.jar, declare our dependency on that specific jar and
declare a dependency exclusion for every other depedency depending on
junit. This would place a custom artifact in the build process/local
repository but would not break other builds. (something tells me we
already made this analysis for jsieve, before you found the alternative
solution).
Maybe we should ask to maven lists what is better to do (IIRC I already
asked this in past, receiving no answers...).
>> You may have noticed that we only get 2 +1 ;-)
>> So I'd like to know what exactly we have to do to get the 3rd +1, either
>> by you or by someone of the other PMC members!
>
> i count +1s from yourself danny and norman: that should be sufficient
>
> - robert
I think Danny voted +0, the "thank goodness one +1!" was a reply to my
+1 and not a vote, I guess :-(
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Mar 31, 2008 at 2:05 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Mon, Mar 31, 2008 at 12:43 AM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> >> I clearly understand that downloading an artifact from a website as part
> >> of an automated process is DIFFERENT (for the US law, for many other
> >> jurisdictions, for the ASF policies, and for everything else) from
> >> redistributing the same artifact as part of another product.
> >>
> >> My point is that if you don't know what the license is I don't see why
> >> downloading automatically is *THE* right choice. I understand that the
> >> legal complications of redistributing are bigger than the one of
> >> automatically download, but the fact is that we don't know the license,
> >> so there are even minimal possibilities that also the automatic download
> >> is not allowed by the license we don't know.
> >
> > ok
> >
> > i'm going to assume that we're talking about the automatic download
> > which happen when maven builds the project.
> >
> > i am not concerned by the automatic download because i trust the maven
> > team to act responsibly enough to allow me to use their application in
> > good faith. though the public audit trail is not clear and so i cannot
> > independently verify this faith, i am in a similar position with most
> > of the software i use.
> >
> > maven is not tied to a single repository. if the people running the
> > central repository end up having a problem with the IP of the
> > documents they distribute then this is a problem for them and not me.
> > apache does not run the repository and so i don't believe that this is
> > an issue that need concern the members. i trust that the people who do
> > run the central repository understand enough US law to ensure that
> > they are not taking too many risky. IMHO this is not an unreasonable
> > assumption.
>
> This is clear.
>
> If I understand it correctly you say that we didn't add central in our
> redistributable because central is something "hardcoded" in maven, so
> what it automatically download is a concern of maven project and the
> maven users and not a problem for us. In fact we simply declare a
> dependency in our pom.xml and do not declare a way to retrieve that
> dependency.
yes
> Would you think the same if we had to declare the central repository url
> in our pom?
i'm not sure but i think that it would come down to ethics. i have no
reason to believe that the central repository distributes artifacts
without rights, i just have no ability to audit that claim.
> If I understand your statement you also say that "*they* are not taking
> too many risky" (by redistributing that pom via central) but you
> wouldn't take the same risks by redistributing the pom as part of our
> release, right?
were i to act for myself alone, then i think that this risk is
reasonable. under current US law, there is very little realistic
chance of prosecution providing that you respond in a timely fashion
to requests to remove material.
> >> The funny thing is that all of this thread is about a "stupid" pom that
> >> even my father could write as is if I explain him the pom
> >> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
> >> scare me: the fact that we don't have a clear way to rewrite this
> >> f***ing xml from scratch and release jSPF-0.9.7.
under US copyright law, only the expression and not the facts would
have been copyrightable. if it were me, i would have simply created a
clean room implementation and been done with it.
or just deleted the pom altogether
> >> For the record the other funny thing is that I don't need a jSPF release
> >> and I don't use jSPF in any of my projects. My involvement in jSPF
> >> started mainly because I had problems releasing JAMES Server and need a
> >> way to work together Norman to better understand his skills and try to
> >> help him joining the JAMES project.
> >
> > note that i didn't -1 the release: if i thought that it posed a
> > significant danger then i would have done so
> >
> > i audit a lot of releases and have my own policies. i will not +1 a
> > release unless i am convinced that the IP is know and fully audited.
> > this is different from -1ing a release that i consider to be actively
> > dangerous. other people judge things differently.
>
> You may have noticed that we only get 2 +1 ;-)
> So I'd like to know what exactly we have to do to get the 3rd +1, either
> by you or by someone of the other PMC members!
i count +1s from yourself danny and norman: that should be sufficient
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Mar 31, 2008 at 12:43 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> I'm sorry for the long messages, my poor english bring me to write the
>> same thing multiple time with the hope the message is transmitted.
>
> the english used in this area is particularly tough since it contains
> a lot of nuance but i'm not sure i can simplify without losing
> accuracy
It was a critic to *my* english. Your verbosity was ok ;-)
>> I clearly understand that downloading an artifact from a website as part
>> of an automated process is DIFFERENT (for the US law, for many other
>> jurisdictions, for the ASF policies, and for everything else) from
>> redistributing the same artifact as part of another product.
>>
>> My point is that if you don't know what the license is I don't see why
>> downloading automatically is *THE* right choice. I understand that the
>> legal complications of redistributing are bigger than the one of
>> automatically download, but the fact is that we don't know the license,
>> so there are even minimal possibilities that also the automatic download
>> is not allowed by the license we don't know.
>
> ok
>
> i'm going to assume that we're talking about the automatic download
> which happen when maven builds the project.
>
> i am not concerned by the automatic download because i trust the maven
> team to act responsibly enough to allow me to use their application in
> good faith. though the public audit trail is not clear and so i cannot
> independently verify this faith, i am in a similar position with most
> of the software i use.
>
> maven is not tied to a single repository. if the people running the
> central repository end up having a problem with the IP of the
> documents they distribute then this is a problem for them and not me.
> apache does not run the repository and so i don't believe that this is
> an issue that need concern the members. i trust that the people who do
> run the central repository understand enough US law to ensure that
> they are not taking too many risky. IMHO this is not an unreasonable
> assumption.
This is clear.
If I understand it correctly you say that we didn't add central in our
redistributable because central is something "hardcoded" in maven, so
what it automatically download is a concern of maven project and the
maven users and not a problem for us. In fact we simply declare a
dependency in our pom.xml and do not declare a way to retrieve that
dependency.
Would you think the same if we had to declare the central repository url
in our pom?
If I understand your statement you also say that "*they* are not taking
too many risky" (by redistributing that pom via central) but you
wouldn't take the same risks by redistributing the pom as part of our
release, right?
>> The funny thing is that all of this thread is about a "stupid" pom that
>> even my father could write as is if I explain him the pom
>> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
>> scare me: the fact that we don't have a clear way to rewrite this
>> f***ing xml from scratch and release jSPF-0.9.7.
>>
>> For the record the other funny thing is that I don't need a jSPF release
>> and I don't use jSPF in any of my projects. My involvement in jSPF
>> started mainly because I had problems releasing JAMES Server and need a
>> way to work together Norman to better understand his skills and try to
>> help him joining the JAMES project.
>
> note that i didn't -1 the release: if i thought that it posed a
> significant danger then i would have done so
>
> i audit a lot of releases and have my own policies. i will not +1 a
> release unless i am convinced that the IP is know and fully audited.
> this is different from -1ing a release that i consider to be actively
> dangerous. other people judge things differently.
You may have noticed that we only get 2 +1 ;-)
So I'd like to know what exactly we have to do to get the 3rd +1, either
by you or by someone of the other PMC members!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Mar 31, 2008 at 12:43 AM, Stefano Bagnara <ap...@bago.org> wrote:
> I understood that we are not understanding each other, too!
>
> I'm sorry for the long messages, my poor english bring me to write the
> same thing multiple time with the hope the message is transmitted.
the english used in this area is particularly tough since it contains
a lot of nuance but i'm not sure i can simplify without losing
accuracy
> I clearly understand that downloading an artifact from a website as part
> of an automated process is DIFFERENT (for the US law, for many other
> jurisdictions, for the ASF policies, and for everything else) from
> redistributing the same artifact as part of another product.
>
> My point is that if you don't know what the license is I don't see why
> downloading automatically is *THE* right choice. I understand that the
> legal complications of redistributing are bigger than the one of
> automatically download, but the fact is that we don't know the license,
> so there are even minimal possibilities that also the automatic download
> is not allowed by the license we don't know.
ok
i'm going to assume that we're talking about the automatic download
which happen when maven builds the project.
i am not concerned by the automatic download because i trust the maven
team to act responsibly enough to allow me to use their application in
good faith. though the public audit trail is not clear and so i cannot
independently verify this faith, i am in a similar position with most
of the software i use.
maven is not tied to a single repository. if the people running the
central repository end up having a problem with the IP of the
documents they distribute then this is a problem for them and not me.
apache does not run the repository and so i don't believe that this is
an issue that need concern the members. i trust that the people who do
run the central repository understand enough US law to ensure that
they are not taking too many risky. IMHO this is not an unreasonable
assumption.
> The funny thing is that all of this thread is about a "stupid" pom that
> even my father could write as is if I explain him the pom
> semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
> scare me: the fact that we don't have a clear way to rewrite this
> f***ing xml from scratch and release jSPF-0.9.7.
>
> For the record the other funny thing is that I don't need a jSPF release
> and I don't use jSPF in any of my projects. My involvement in jSPF
> started mainly because I had problems releasing JAMES Server and need a
> way to work together Norman to better understand his skills and try to
> help him joining the JAMES project.
note that i didn't -1 the release: if i thought that it posed a
significant danger then i would have done so
i audit a lot of releases and have my own policies. i will not +1 a
release unless i am convinced that the IP is know and fully audited.
this is different from -1ing a release that i consider to be actively
dangerous. other people judge things differently.
> I thank you for everything you wrote in reply to my messages: it is
> always interesting to me to discuss corner cases. What I find
> frustrating is that my english is not as good as my italian otherwise we
> could have written much less and have a conclusion about what to do with
> jSPF, now.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Mar 30, 2008 at 4:56 PM, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>> On Sun, Mar 30, 2008 at 4:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >
>> > Robert Burrell Donkin ha scritto:
>> > > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> > >> Robert Burrell Donkin ha scritto:
>> > >> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> > >> >> Robert Burrell Donkin ha scritto:
>> > >> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> > >> >>
>> > >> >>>> I checked MAVENUPLOAD and the first reference about junit is:
>> > >> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> > >> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> > >> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
>> > >> >> >> was under the CPL then probably that user was not entitled in altering
>> > >> >> >> the content and submit it to the ASF and the ASF should not have
>> > >> >> >> uploaded it to central (is this right?).
>> > >> >> >
>> > >> >> > codehaus is not apache. any source use from codehaus needs to come in
>> > >> >> > via the incubator IP clearance.
>> > >> >> >
>> > >> >> > - robert
>> > >> >>
>> > >> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
>> > >> >> in central by the ASF ;-) . Or at least this is what maven tells to the
>> > >> >> world:
>> > >> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> > >> >>
>> > >> >> I can also confirm that I have successfully created a pom for dnsjava,
>> > >> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
>> > >> >> maven central repository.
>> > >> >>
>> > >> >> I just repeat that MOST projects in ASF are using the poms included in
>> > >> >> central and this is a big issue that is being mostly ignored,
>> > >> >> unfortunately. That is why I think the PPMC are not being diligent and
>> > >> >> the board should help spreading this issue and coordinate all the PPMCs
>> > >> >> to find a common solution to this issue.
>> > >> >
>> > >> > using artifacts from the maven repository does not worry me:
>> > >> > distributing artifacts does
>> > >> >
>> > >> > - robert
>> > >>
>> > >> I understand this, but I didn't understand why.
>> > >> If that file is under an acceptable license then we can use and
>> > >> redistribute it, otherwise we can't use and redistribute it IMO.
>> > >
>> > > you can opinion all you like but you're wrong
>> > >
>> > > use and distribution are two distinct and different concepts and
>> > > rights under copyright law. it is perfectly possible to create
>> > > licenses which allow use but not distribution and vice versa.
>> > >
>> > > - robert
>> >
>> > Sorry. I can accept your opinion but I don't think I'm wrong and you're
>> > right ;-)
>>
>> if you're interested in open source and the law then you really should
>> try to get to more conferences: you might learn something
>>
>>
>> > What I say is that if you DON'T KNOW THE LICENSE the ALL RIGHTS ARE
>> > RESERVED. This means you can't redistribute it and you can't
>> > automatically download it as part of an automated process.
>>
>> no: you're wrong
>>
>> if you don't knowingly possess an explicit license then this means
>> exactly and only that: you don't knowingly possess an explicit
>> license. you may still have rights to use or distribute that artifact:
>> you may have an implied license, the artifact might contain an
>> embedded license, a public license may be available (which you don't
>> know about or that you haven't bothered to download) or your legal
>> system may grant fair use rights. AIUI there are some jurisdictions
>> (for example, the UK) which may in theory imply that you need to
>> possess an actual license but in practice this is unenforcable.
>
> apologies, re-reading this thread i see that i've become a little
> personal. i just find it very frustrating and this is a very long
> thread that seems to be going nowhere. i've tried to explain where
> there are big differences between distribution and use under copyright
> law and in apache policy but i haven't really succeeded.
>
> - robert
ops, sorry.. I read this message after the previous reply.
I understood that we are not understanding each other, too!
I'm sorry for the long messages, my poor english bring me to write the
same thing multiple time with the hope the message is transmitted.
I clearly understand that downloading an artifact from a website as part
of an automated process is DIFFERENT (for the US law, for many other
jurisdictions, for the ASF policies, and for everything else) from
redistributing the same artifact as part of another product.
My point is that if you don't know what the license is I don't see why
downloading automatically is *THE* right choice. I understand that the
legal complications of redistributing are bigger than the one of
automatically download, but the fact is that we don't know the license,
so there are even minimal possibilities that also the automatic download
is not allowed by the license we don't know.
The funny thing is that all of this thread is about a "stupid" pom that
even my father could write as is if I explain him the pom
semantic+syntax and I tell him to describe junit-3.8.1.jar. This is what
scare me: the fact that we don't have a clear way to rewrite this
f***ing xml from scratch and release jSPF-0.9.7.
For the record the other funny thing is that I don't need a jSPF release
and I don't use jSPF in any of my projects. My involvement in jSPF
started mainly because I had problems releasing JAMES Server and need a
way to work together Norman to better understand his skills and try to
help him joining the JAMES project.
I thank you for everything you wrote in reply to my messages: it is
always interesting to me to discuss corner cases. What I find
frustrating is that my english is not as good as my italian otherwise we
could have written much less and have a conclusion about what to do with
jSPF, now.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 30, 2008 at 4:56 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
>
> On Sun, Mar 30, 2008 at 4:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >
> > Robert Burrell Donkin ha scritto:
> > > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > >> Robert Burrell Donkin ha scritto:
> > >> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
> > >> >> Robert Burrell Donkin ha scritto:
> > >> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> > >> >>
> > >> >>>> I checked MAVENUPLOAD and the first reference about junit is:
> > >> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
> > >> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
> > >> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
> > >> >> >> was under the CPL then probably that user was not entitled in altering
> > >> >> >> the content and submit it to the ASF and the ASF should not have
> > >> >> >> uploaded it to central (is this right?).
> > >> >> >
> > >> >> > codehaus is not apache. any source use from codehaus needs to come in
> > >> >> > via the incubator IP clearance.
> > >> >> >
> > >> >> > - robert
> > >> >>
> > >> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
> > >> >> in central by the ASF ;-) . Or at least this is what maven tells to the
> > >> >> world:
> > >> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> > >> >>
> > >> >> I can also confirm that I have successfully created a pom for dnsjava,
> > >> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
> > >> >> maven central repository.
> > >> >>
> > >> >> I just repeat that MOST projects in ASF are using the poms included in
> > >> >> central and this is a big issue that is being mostly ignored,
> > >> >> unfortunately. That is why I think the PPMC are not being diligent and
> > >> >> the board should help spreading this issue and coordinate all the PPMCs
> > >> >> to find a common solution to this issue.
> > >> >
> > >> > using artifacts from the maven repository does not worry me:
> > >> > distributing artifacts does
> > >> >
> > >> > - robert
> > >>
> > >> I understand this, but I didn't understand why.
> > >> If that file is under an acceptable license then we can use and
> > >> redistribute it, otherwise we can't use and redistribute it IMO.
> > >
> > > you can opinion all you like but you're wrong
> > >
> > > use and distribution are two distinct and different concepts and
> > > rights under copyright law. it is perfectly possible to create
> > > licenses which allow use but not distribution and vice versa.
> > >
> > > - robert
> >
> > Sorry. I can accept your opinion but I don't think I'm wrong and you're
> > right ;-)
>
> if you're interested in open source and the law then you really should
> try to get to more conferences: you might learn something
>
>
> > What I say is that if you DON'T KNOW THE LICENSE the ALL RIGHTS ARE
> > RESERVED. This means you can't redistribute it and you can't
> > automatically download it as part of an automated process.
>
> no: you're wrong
>
> if you don't knowingly possess an explicit license then this means
> exactly and only that: you don't knowingly possess an explicit
> license. you may still have rights to use or distribute that artifact:
> you may have an implied license, the artifact might contain an
> embedded license, a public license may be available (which you don't
> know about or that you haven't bothered to download) or your legal
> system may grant fair use rights. AIUI there are some jurisdictions
> (for example, the UK) which may in theory imply that you need to
> possess an actual license but in practice this is unenforcable.
apologies, re-reading this thread i see that i've become a little
personal. i just find it very frustrating and this is a very long
thread that seems to be going nowhere. i've tried to explain where
there are big differences between distribution and use under copyright
law and in apache policy but i haven't really succeeded.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Mar 30, 2008 at 4:12 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> Robert Burrell Donkin ha scritto:
>
> <snip>
>
>> >> I understand this, but I didn't understand why.
>> >> If that file is under an acceptable license then we can use and
>> >> redistribute it, otherwise we can't use and redistribute it IMO.
>> >
>> > you can opinion all you like but you're wrong
>> >
>> > use and distribution are two distinct and different concepts and
>> > rights under copyright law. it is perfectly possible to create
>> > licenses which allow use but not distribution and vice versa.
>> >
>> > - robert
>>
>> Furthermore, I wrote *acceptable*. And this means that I think that if
>> the artifact is, for example, an ALv2, BSD, MIT, W3C Software we are
>> allowed to do BOTH. I also think that the CPL (junit license) would be
>> ok, if the junit.pom was under that license.
>>
>> So you probably simply missed my "acceptable" word, otherwise tell me
>> why I'm wrong wrt the above licenses.
>
> if you intended to talk about apache policy then rules for use and
> distribution are different: for example, httpd may use GNU linux when
> it runs but we do not allow GNU linux to be distributed with HTTPD.
>
> if you intended to talk about the law, see above
>
> - robert
It is not important if rules for download and distribution are different
unless we don't have rules for download and distributions of files under
an unknown license. The 3rd party document doesn't tell what category is
"unknown license" and does not tell us what category "All rights
reserved, you can't even read this license, if you read this license
then you are a dead man" belongs to ;-)
If we find that the pom is under the ALv2, BSD, MIT, W3C Software or CPL
can we automatically download from the central? Can we include it "as
is" as part of an ASF release?
Talking about other licenses you already told that there may be licenses
that allow remote download but not redistribution and vice versa, so I
don't get the GNU linux sentence meaning.
The fact is that we don't know the license, so there are many cases:
1) The copyright holder have reserved all rights and he was not who
uploaded the file to central (so probably the file should not be there)
2) The copyright holder have reserver all rights and he was the original
uploader of the file to central.
3) The copyright holder have a assigned a specific license to his work
but forgot to add a reference to the license.
3a) The license allow us to remotely download the artifact AND to
redistribute it, but ASF policies tell us to not do this.
3b) The license allow us to remotely download the artifact AND to
redistribute it AND ASF policy allow us to do both.
3c) The license allow us to remotely download the artifact BUT NOT to
redistribute it.
3d) The license allow us to redistribute it BUT NOT to remotely
download it as part of an automated process.
Did I forget some case?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 30, 2008 at 4:12 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> Robert Burrell Donkin ha scritto:
> > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
<snip>
> >> I understand this, but I didn't understand why.
> >> If that file is under an acceptable license then we can use and
> >> redistribute it, otherwise we can't use and redistribute it IMO.
> >
> > you can opinion all you like but you're wrong
> >
> > use and distribution are two distinct and different concepts and
> > rights under copyright law. it is perfectly possible to create
> > licenses which allow use but not distribution and vice versa.
> >
> > - robert
>
> Furthermore, I wrote *acceptable*. And this means that I think that if
> the artifact is, for example, an ALv2, BSD, MIT, W3C Software we are
> allowed to do BOTH. I also think that the CPL (junit license) would be
> ok, if the junit.pom was under that license.
>
> So you probably simply missed my "acceptable" word, otherwise tell me
> why I'm wrong wrt the above licenses.
if you intended to talk about apache policy then rules for use and
distribution are different: for example, httpd may use GNU linux when
it runs but we do not allow GNU linux to be distributed with HTTPD.
if you intended to talk about the law, see above
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sun, Mar 30, 2008 at 4:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> Robert Burrell Donkin ha scritto:
>> >> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> >> Robert Burrell Donkin ha scritto:
>> >> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> >>
>> >> >>>> I checked MAVENUPLOAD and the first reference about junit is:
>> >> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> >> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> >> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
>> >> >> >> was under the CPL then probably that user was not entitled in altering
>> >> >> >> the content and submit it to the ASF and the ASF should not have
>> >> >> >> uploaded it to central (is this right?).
>> >> >> >
>> >> >> > codehaus is not apache. any source use from codehaus needs to come in
>> >> >> > via the incubator IP clearance.
>> >> >> >
>> >> >> > - robert
>> >> >>
>> >> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
>> >> >> in central by the ASF ;-) . Or at least this is what maven tells to the
>> >> >> world:
>> >> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> >> >>
>> >> >> I can also confirm that I have successfully created a pom for dnsjava,
>> >> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
>> >> >> maven central repository.
>> >> >>
>> >> >> I just repeat that MOST projects in ASF are using the poms included in
>> >> >> central and this is a big issue that is being mostly ignored,
>> >> >> unfortunately. That is why I think the PPMC are not being diligent and
>> >> >> the board should help spreading this issue and coordinate all the PPMCs
>> >> >> to find a common solution to this issue.
>> >> >
>> >> > using artifacts from the maven repository does not worry me:
>> >> > distributing artifacts does
>> >> >
>> >> > - robert
>> >>
>> >> I understand this, but I didn't understand why.
>> >> If that file is under an acceptable license then we can use and
>> >> redistribute it, otherwise we can't use and redistribute it IMO.
>> >
>> > you can opinion all you like but you're wrong
>> >
>> > use and distribution are two distinct and different concepts and
>> > rights under copyright law. it is perfectly possible to create
>> > licenses which allow use but not distribution and vice versa.
>> >
>> > - robert
>>
>> Sorry. I can accept your opinion but I don't think I'm wrong and you're
>> right ;-)
>
> if you're interested in open source and the law then you really should
> try to get to more conferences: you might learn something
There are many ways to learn ;-)
>> What I say is that if you DON'T KNOW THE LICENSE the ALL RIGHTS ARE
>> RESERVED. This means you can't redistribute it and you can't
>> automatically download it as part of an automated process.
>
> no: you're wrong
>
> if you don't knowingly possess an explicit license then this means
> exactly and only that: you don't knowingly possess an explicit
> license. you may still have rights to use or distribute that artifact:
> you may have an implied license, the artifact might contain an
> embedded license, a public license may be available (which you don't
> know about or that you haven't bothered to download) or your legal
> system may grant fair use rights. AIUI there are some jurisdictions
> (for example, the UK) which may in theory imply that you need to
> possess an actual license but in practice this is unenforcable.
>
> - robert
Sorry Robert but it seems this discussion is too difficult. Maybe my
english is not good enough because I'm under the impression you don't
understand what I know and what I'm trying to say.
The ASF is always conservative about what to do and what policy to use.
This is why I understood that when we don't know what is the license (so
this means that it *could* *be* all rights reserved) the ASF take the
more strict case, so tell us to avoid using it.
Given that we have no legal power to analyze what exactly we can do
under all right reserved in any given country then the result is that we
can't do anything.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Mar 30, 2008 at 4:09 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> Robert Burrell Donkin ha scritto:
> > On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> >> Robert Burrell Donkin ha scritto:
> >> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >> >>
> >> >>>> I checked MAVENUPLOAD and the first reference about junit is:
> >> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
> >> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
> >> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
> >> >> >> was under the CPL then probably that user was not entitled in altering
> >> >> >> the content and submit it to the ASF and the ASF should not have
> >> >> >> uploaded it to central (is this right?).
> >> >> >
> >> >> > codehaus is not apache. any source use from codehaus needs to come in
> >> >> > via the incubator IP clearance.
> >> >> >
> >> >> > - robert
> >> >>
> >> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
> >> >> in central by the ASF ;-) . Or at least this is what maven tells to the
> >> >> world:
> >> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> >> >>
> >> >> I can also confirm that I have successfully created a pom for dnsjava,
> >> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
> >> >> maven central repository.
> >> >>
> >> >> I just repeat that MOST projects in ASF are using the poms included in
> >> >> central and this is a big issue that is being mostly ignored,
> >> >> unfortunately. That is why I think the PPMC are not being diligent and
> >> >> the board should help spreading this issue and coordinate all the PPMCs
> >> >> to find a common solution to this issue.
> >> >
> >> > using artifacts from the maven repository does not worry me:
> >> > distributing artifacts does
> >> >
> >> > - robert
> >>
> >> I understand this, but I didn't understand why.
> >> If that file is under an acceptable license then we can use and
> >> redistribute it, otherwise we can't use and redistribute it IMO.
> >
> > you can opinion all you like but you're wrong
> >
> > use and distribution are two distinct and different concepts and
> > rights under copyright law. it is perfectly possible to create
> > licenses which allow use but not distribution and vice versa.
> >
> > - robert
>
> Sorry. I can accept your opinion but I don't think I'm wrong and you're
> right ;-)
if you're interested in open source and the law then you really should
try to get to more conferences: you might learn something
> What I say is that if you DON'T KNOW THE LICENSE the ALL RIGHTS ARE
> RESERVED. This means you can't redistribute it and you can't
> automatically download it as part of an automated process.
no: you're wrong
if you don't knowingly possess an explicit license then this means
exactly and only that: you don't knowingly possess an explicit
license. you may still have rights to use or distribute that artifact:
you may have an implied license, the artifact might contain an
embedded license, a public license may be available (which you don't
know about or that you haven't bothered to download) or your legal
system may grant fair use rights. AIUI there are some jurisdictions
(for example, the UK) which may in theory imply that you need to
possess an actual license but in practice this is unenforcable.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> Robert Burrell Donkin ha scritto:
>> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> >>
>> >>>> I checked MAVENUPLOAD and the first reference about junit is:
>> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
>> >> >> was under the CPL then probably that user was not entitled in altering
>> >> >> the content and submit it to the ASF and the ASF should not have
>> >> >> uploaded it to central (is this right?).
>> >> >
>> >> > codehaus is not apache. any source use from codehaus needs to come in
>> >> > via the incubator IP clearance.
>> >> >
>> >> > - robert
>> >>
>> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
>> >> in central by the ASF ;-) . Or at least this is what maven tells to the
>> >> world:
>> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> >>
>> >> I can also confirm that I have successfully created a pom for dnsjava,
>> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
>> >> maven central repository.
>> >>
>> >> I just repeat that MOST projects in ASF are using the poms included in
>> >> central and this is a big issue that is being mostly ignored,
>> >> unfortunately. That is why I think the PPMC are not being diligent and
>> >> the board should help spreading this issue and coordinate all the PPMCs
>> >> to find a common solution to this issue.
>> >
>> > using artifacts from the maven repository does not worry me:
>> > distributing artifacts does
>> >
>> > - robert
>>
>> I understand this, but I didn't understand why.
>> If that file is under an acceptable license then we can use and
>> redistribute it, otherwise we can't use and redistribute it IMO.
>
> you can opinion all you like but you're wrong
>
> use and distribution are two distinct and different concepts and
> rights under copyright law. it is perfectly possible to create
> licenses which allow use but not distribution and vice versa.
>
> - robert
Sorry. I can accept your opinion but I don't think I'm wrong and you're
right ;-)
What I say is that if you DON'T KNOW THE LICENSE the ALL RIGHTS ARE
RESERVED. This means you can't redistribute it and you can't
automatically download it as part of an automated process.
I know it is possible to create license to say everything: I can also
create a license that allow you to redistribute my stuff in a package
but not to publish a part of it on a website and allow people to
automatically download it.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> >> Robert Burrell Donkin ha scritto:
>> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> >>
>> >>>> I checked MAVENUPLOAD and the first reference about junit is:
>> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
>> >> >> was under the CPL then probably that user was not entitled in altering
>> >> >> the content and submit it to the ASF and the ASF should not have
>> >> >> uploaded it to central (is this right?).
>> >> >
>> >> > codehaus is not apache. any source use from codehaus needs to come in
>> >> > via the incubator IP clearance.
>> >> >
>> >> > - robert
>> >>
>> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
>> >> in central by the ASF ;-) . Or at least this is what maven tells to the
>> >> world:
>> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> >>
>> >> I can also confirm that I have successfully created a pom for dnsjava,
>> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
>> >> maven central repository.
>> >>
>> >> I just repeat that MOST projects in ASF are using the poms included in
>> >> central and this is a big issue that is being mostly ignored,
>> >> unfortunately. That is why I think the PPMC are not being diligent and
>> >> the board should help spreading this issue and coordinate all the PPMCs
>> >> to find a common solution to this issue.
>> >
>> > using artifacts from the maven repository does not worry me:
>> > distributing artifacts does
>> >
>> > - robert
>>
>> I understand this, but I didn't understand why.
>> If that file is under an acceptable license then we can use and
>> redistribute it, otherwise we can't use and redistribute it IMO.
>
> you can opinion all you like but you're wrong
>
> use and distribution are two distinct and different concepts and
> rights under copyright law. it is perfectly possible to create
> licenses which allow use but not distribution and vice versa.
>
> - robert
Furthermore, I wrote *acceptable*. And this means that I think that if
the artifact is, for example, an ALv2, BSD, MIT, W3C Software we are
allowed to do BOTH. I also think that the CPL (junit license) would be
ok, if the junit.pom was under that license.
So you probably simply missed my "acceptable" word, otherwise tell me
why I'm wrong wrt the above licenses.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 5:25 PM, Stefano Bagnara <ap...@bago.org> wrote:
>
> Robert Burrell Donkin ha scritto:
> > On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
> >> Robert Burrell Donkin ha scritto:
> >> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> >>
> >>>> I checked MAVENUPLOAD and the first reference about junit is:
> >> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
> >> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
> >> >> and updated it.. so this doesn't help for now. IF the original junit pom
> >> >> was under the CPL then probably that user was not entitled in altering
> >> >> the content and submit it to the ASF and the ASF should not have
> >> >> uploaded it to central (is this right?).
> >> >
> >> > codehaus is not apache. any source use from codehaus needs to come in
> >> > via the incubator IP clearance.
> >> >
> >> > - robert
> >>
> >> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
> >> in central by the ASF ;-) . Or at least this is what maven tells to the
> >> world:
> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> >>
> >> I can also confirm that I have successfully created a pom for dnsjava,
> >> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
> >> maven central repository.
> >>
> >> I just repeat that MOST projects in ASF are using the poms included in
> >> central and this is a big issue that is being mostly ignored,
> >> unfortunately. That is why I think the PPMC are not being diligent and
> >> the board should help spreading this issue and coordinate all the PPMCs
> >> to find a common solution to this issue.
> >
> > using artifacts from the maven repository does not worry me:
> > distributing artifacts does
> >
> > - robert
>
> I understand this, but I didn't understand why.
> If that file is under an acceptable license then we can use and
> redistribute it, otherwise we can't use and redistribute it IMO.
you can opinion all you like but you're wrong
use and distribution are two distinct and different concepts and
rights under copyright law. it is perfectly possible to create
licenses which allow use but not distribution and vice versa.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>>> I checked MAVENUPLOAD and the first reference about junit is:
>> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> >> and updated it.. so this doesn't help for now. IF the original junit pom
>> >> was under the CPL then probably that user was not entitled in altering
>> >> the content and submit it to the ASF and the ASF should not have
>> >> uploaded it to central (is this right?).
>> >
>> > codehaus is not apache. any source use from codehaus needs to come in
>> > via the incubator IP clearance.
>> >
>> > - robert
>>
>> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
>> in central by the ASF ;-) . Or at least this is what maven tells to the
>> world:
>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>
>> I can also confirm that I have successfully created a pom for dnsjava,
>> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
>> maven central repository.
>>
>> I just repeat that MOST projects in ASF are using the poms included in
>> central and this is a big issue that is being mostly ignored,
>> unfortunately. That is why I think the PPMC are not being diligent and
>> the board should help spreading this issue and coordinate all the PPMCs
>> to find a common solution to this issue.
>
> using artifacts from the maven repository does not worry me:
> distributing artifacts does
>
> - robert
I understand this, but I didn't understand why.
If that file is under an acceptable license then we can use and
redistribute it, otherwise we can't use and redistribute it IMO.
BTW, you are more experienced in this and your idea give me a solution,
so I won't fight this ;-)
Noel, Bernd and everyone else: will you oppose a change to jspf to
remove the stage folder so that offline builds will no more be available
but we don't need to ship this pom?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 1:40 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>
> >> I checked MAVENUPLOAD and the first reference about junit is:
> >> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
> >> And it is about junit 4.1: the submitter say he took the pom from 4.0
> >> and updated it.. so this doesn't help for now. IF the original junit pom
> >> was under the CPL then probably that user was not entitled in altering
> >> the content and submit it to the ASF and the ASF should not have
> >> uploaded it to central (is this right?).
> >
> > codehaus is not apache. any source use from codehaus needs to come in
> > via the incubator IP clearance.
> >
> > - robert
>
> Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
> in central by the ASF ;-) . Or at least this is what maven tells to the
> world:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> I can also confirm that I have successfully created a pom for dnsjava,
> uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
> maven central repository.
>
> I just repeat that MOST projects in ASF are using the poms included in
> central and this is a big issue that is being mostly ignored,
> unfortunately. That is why I think the PPMC are not being diligent and
> the board should help spreading this issue and coordinate all the PPMCs
> to find a common solution to this issue.
using artifacts from the maven repository does not worry me:
distributing artifacts does
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> I checked MAVENUPLOAD and the first reference about junit is:
>> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
>> And it is about junit 4.1: the submitter say he took the pom from 4.0
>> and updated it.. so this doesn't help for now. IF the original junit pom
>> was under the CPL then probably that user was not entitled in altering
>> the content and submit it to the ASF and the ASF should not have
>> uploaded it to central (is this right?).
>
> codehaus is not apache. any source use from codehaus needs to come in
> via the incubator IP clearance.
>
> - robert
Hey... MAVENUPLOAD at codehaus is *THE* *WAY* artifacts use to be placed
in central by the ASF ;-) . Or at least this is what maven tells to the
world:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I can also confirm that I have successfully created a pom for dnsjava,
uploaded it to codehaus MAVENUPLOAD JIRA and someone published it to the
maven central repository.
I just repeat that MOST projects in ASF are using the poms included in
central and this is a big issue that is being mostly ignored,
unfortunately. That is why I think the PPMC are not being diligent and
the board should help spreading this issue and coordinate all the PPMCs
to find a common solution to this issue.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Sat, Mar 29, 2008 at 2:14 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>>> I understand that there is difference between downloading and
>> >> distributing, but this difference IMHO exists when the license is known
>> >> and the license itself make a difference (most licenses do). I don't
>> >> agree that by downloading and *using* files under an unknown license you
>> >> make "fair use" and it is ok
>> >
>> > copyright law distinguishes between these two cases (downloading and
>> > distributing). copying works is often only arguably illegal.
>> > distributing a copy without a license to do so is clearly illegal.
>> >
>> > for example, in order to view a web page, a local copy must be made.
>> > few web pages explicitly license this copying. however, in most
>> > jurisdictions this act would be covered by the fair use of the implied
>> > license. this is very different from distributing the same page for
>> > example by hosting a complete copy on your website.
>>
>> There are IMHO 2 important differences:
>>
>> 1) We are downloading the file from maven central, that is not where the
>> copyright holder published it (or at least we don't know this and we are
>> trying to understand who is the copyright holder and what rights he
>> grants to us).
>
> do you know that the copyright holder didn't publish it there? most
> maven poms are uploader by the copyright holder. do you know that the
> uploaded doesn't posses a license to distribute the pom?
No we don't know who was the uploader (this is what we are trying to
understand), so we can't assume that the uploader was the copyright
holder. I also don't think that codehaus MAVENUPLOAD is too specific
about what kind of pom you can upload there. They only talk about
technical issues and never about legal issues.
> i'm happy to act in good faith. even though the central repository
> lacks embedded licenses, i trust that the administrators have obtained
> the required permissions. if not they my defense would be that i acted
> in good faith believing that maven had secured the appropriate
> licenses. i think i have reasonable cause for believing that.
What I don't understand is why you would use this as your defense and
this is not the same if that pom is included in our distribution. IMHO
the "good faith" is the same, here.. only the use we make is different,
isn't it?
>> 2) Downloading a webpage for browsing is much more clear as "fair use"
>> than automatically download metadata as part of an automated project. I
>> can browse google as fair use, but I'm not sure I can create
>> applications scraping google results without referencing google as part
>> of an automated software. In fact they provides API with a much more
>> limited license to do that. If I write a tool that query Amazon via AWS
>> I can only make 1 query per second as per their license. If I write a
>> tool that simply browse their website and do thousands of query per
>> seconds to do the same things I would do with their API I don't think
>> this would be taken as "fair use".
>
> AIUI fair use is simply the description given to the rights grant
> under the US constitution. temporary local copies for personal use are
> ok provided that you have rights to copy once. when someone places a
> page on the internet with the obvious aim of encouraging people to
> read it then they are granting an implied license. this in turn
> entitles people to their constitutional rights to make temporary
> copies for personal use.
>
> AIUI additional legislation was inacted to criminalize large scale
> automatic querying since it was not clearly covered by standard
> copyright
>
> - robert
"personal use" is key in your explanation. I don't think our
distributions are only intended for personal use. ASF is business
friendly and our products are likely to be used professionally and for
business and not for personal use.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Mar 29, 2008 at 2:14 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>
> >> I understand that there is difference between downloading and
> >> distributing, but this difference IMHO exists when the license is known
> >> and the license itself make a difference (most licenses do). I don't
> >> agree that by downloading and *using* files under an unknown license you
> >> make "fair use" and it is ok
> >
> > copyright law distinguishes between these two cases (downloading and
> > distributing). copying works is often only arguably illegal.
> > distributing a copy without a license to do so is clearly illegal.
> >
> > for example, in order to view a web page, a local copy must be made.
> > few web pages explicitly license this copying. however, in most
> > jurisdictions this act would be covered by the fair use of the implied
> > license. this is very different from distributing the same page for
> > example by hosting a complete copy on your website.
>
> There are IMHO 2 important differences:
>
> 1) We are downloading the file from maven central, that is not where the
> copyright holder published it (or at least we don't know this and we are
> trying to understand who is the copyright holder and what rights he
> grants to us).
do you know that the copyright holder didn't publish it there? most
maven poms are uploader by the copyright holder. do you know that the
uploaded doesn't posses a license to distribute the pom?
i'm happy to act in good faith. even though the central repository
lacks embedded licenses, i trust that the administrators have obtained
the required permissions. if not they my defense would be that i acted
in good faith believing that maven had secured the appropriate
licenses. i think i have reasonable cause for believing that.
> 2) Downloading a webpage for browsing is much more clear as "fair use"
> than automatically download metadata as part of an automated project. I
> can browse google as fair use, but I'm not sure I can create
> applications scraping google results without referencing google as part
> of an automated software. In fact they provides API with a much more
> limited license to do that. If I write a tool that query Amazon via AWS
> I can only make 1 query per second as per their license. If I write a
> tool that simply browse their website and do thousands of query per
> seconds to do the same things I would do with their API I don't think
> this would be taken as "fair use".
AIUI fair use is simply the description given to the rights grant
under the US constitution. temporary local copies for personal use are
ok provided that you have rights to copy once. when someone places a
page on the internet with the obvious aim of encouraging people to
read it then they are granting an implied license. this in turn
entitles people to their constitutional rights to make temporary
copies for personal use.
AIUI additional legislation was inacted to criminalize large scale
automatic querying since it was not clearly covered by standard
copyright
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> I understand that there is difference between downloading and
>> distributing, but this difference IMHO exists when the license is known
>> and the license itself make a difference (most licenses do). I don't
>> agree that by downloading and *using* files under an unknown license you
>> make "fair use" and it is ok
>
> copyright law distinguishes between these two cases (downloading and
> distributing). copying works is often only arguably illegal.
> distributing a copy without a license to do so is clearly illegal.
>
> for example, in order to view a web page, a local copy must be made.
> few web pages explicitly license this copying. however, in most
> jurisdictions this act would be covered by the fair use of the implied
> license. this is very different from distributing the same page for
> example by hosting a complete copy on your website.
There are IMHO 2 important differences:
1) We are downloading the file from maven central, that is not where the
copyright holder published it (or at least we don't know this and we are
trying to understand who is the copyright holder and what rights he
grants to us).
2) Downloading a webpage for browsing is much more clear as "fair use"
than automatically download metadata as part of an automated project. I
can browse google as fair use, but I'm not sure I can create
applications scraping google results without referencing google as part
of an automated software. In fact they provides API with a much more
limited license to do that. If I write a tool that query Amazon via AWS
I can only make 1 query per second as per their license. If I write a
tool that simply browse their website and do thousands of query per
seconds to do the same things I would do with their API I don't think
this would be taken as "fair use".
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Mar 28, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>
> > the substantial issue is not dependency but distribution. maven may
> > download documents of unknown provenance at runtime but this is very
> > different from distributing such a document.
> >
> > AIUI the download is likely to be covered by fair use and if an
> > infringement occurs then it is the original uploader who is at fault.
> > by distributing such an artifact, US law makes apache responsible for
> > ensuring that we have the required license. we know that we lack the
> > license. this is risky from a copyright perspective.
>
> I understand that there is difference between downloading and
> distributing, but this difference IMHO exists when the license is known
> and the license itself make a difference (most licenses do). I don't
> agree that by downloading and *using* files under an unknown license you
> make "fair use" and it is ok
copyright law distinguishes between these two cases (downloading and
distributing). copying works is often only arguably illegal.
distributing a copy without a license to do so is clearly illegal.
for example, in order to view a web page, a local copy must be made.
few web pages explicitly license this copying. however, in most
jurisdictions this act would be covered by the fair use of the implied
license. this is very different from distributing the same page for
example by hosting a complete copy on your website.
> (and you told me once that we can't do
> *anything* with a file with an unknown license, don't you remember?
this is apache policy not a general legal requirement. it's a good
policy since it reduces friction by ensure that our users are supplied
with the license automatically and allows public auditing.
> we
> was talking about NOTICE/LICENSE file in our repository and what people
> can do with files downloaded from a website if they don't find the
> license/copyright statements: you told me they have no rights unless
> they find a file giving them some right).
that paraphrasing isn't right: your rights depend on the jurisdiction.
in the USA (for example) the constitution contains gaurantees about
your right to copy. some jurisdications may grant you an implied
license based on the actions of the other party.
however, by default now all documents are covered by copyright
(whether it's stated or not) and have all rights reserved. it's no
longer necessary for the document to contain a license and copyright
notice for the author to be able to enforce copyright.
> Otherwise everyone would sell proprietary projects that simply download
> their GPL dependencies at the first run.
this might be lawful (but unethical). the GPL contains clever legal
arguments intended to prevent this but these remain untested in court.
> If someone upload a non redistributable, non usable copyrighted file to
> MAVENUPLOAD, someone else put it in central and you use it via remote
> downloading during your build *my* *opinion* is that every of the 3
> actors involved are wrong and cannot do what they do because they all
> distribute or use a file for which they don't have rights.
i can't speak for those involve with the maven external repository.
just because the document does not contain an embedded license does
not contain a license does not mean that a license does not exist for
that document. at apache, we ask for embedded licenses since this
makes it much easier to understand. it may well be that the process is
sound but just hard to audit.
it's reasonable to act in good faith. if someone claims to have the
required copyright and grants an appropriate license (for example by
filling in a JIRA) then the rest are acting perfectly reasonably.
> BTW, my opinion doesn't matter as I'm not a lawyer.
lawyers are unlikely to give public opinions on anything as general as this
> BUT, our specific issue is the pom.xml for junit, so I prefer to solve
> this very specific issue now, and then try to solve the more generic
> issue just after as everyone of our maven based projects include the
> stage folder and redistribute poms downloaded from central or even
> java.net repository. Every other problematic pom has been tracked down
> now (I also updated the license headers for the files I wrote myself).
>
> I guess that the pom.xml for junit has been uploaded to central by some
> ASF committer either direclty or uploaded via JIRA: how can we track
> down this?
>
> I checked MAVENUPLOAD and the first reference about junit is:
> http://jira.codehaus.org/browse/MAVENUPLOAD-1168
> And it is about junit 4.1: the submitter say he took the pom from 4.0
> and updated it.. so this doesn't help for now. IF the original junit pom
> was under the CPL then probably that user was not entitled in altering
> the content and submit it to the ASF and the ASF should not have
> uploaded it to central (is this right?).
codehaus is not apache. any source use from codehaus needs to come in
via the incubator IP clearance.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> the substantial issue is not dependency but distribution. maven may
> download documents of unknown provenance at runtime but this is very
> different from distributing such a document.
>
> AIUI the download is likely to be covered by fair use and if an
> infringement occurs then it is the original uploader who is at fault.
> by distributing such an artifact, US law makes apache responsible for
> ensuring that we have the required license. we know that we lack the
> license. this is risky from a copyright perspective.
I understand that there is difference between downloading and
distributing, but this difference IMHO exists when the license is known
and the license itself make a difference (most licenses do). I don't
agree that by downloading and *using* files under an unknown license you
make "fair use" and it is ok (and you told me once that we can't do
*anything* with a file with an unknown license, don't you remember? we
was talking about NOTICE/LICENSE file in our repository and what people
can do with files downloaded from a website if they don't find the
license/copyright statements: you told me they have no rights unless
they find a file giving them some right).
Otherwise everyone would sell proprietary projects that simply download
their GPL dependencies at the first run.
If someone upload a non redistributable, non usable copyrighted file to
MAVENUPLOAD, someone else put it in central and you use it via remote
downloading during your build *my* *opinion* is that every of the 3
actors involved are wrong and cannot do what they do because they all
distribute or use a file for which they don't have rights.
BTW, my opinion doesn't matter as I'm not a lawyer. What I would like to
see is something about downloading vs distributing in the current 3rd
party document. I never read something similar to day.
BUT, our specific issue is the pom.xml for junit, so I prefer to solve
this very specific issue now, and then try to solve the more generic
issue just after as everyone of our maven based projects include the
stage folder and redistribute poms downloaded from central or even
java.net repository. Every other problematic pom has been tracked down
now (I also updated the license headers for the files I wrote myself).
I guess that the pom.xml for junit has been uploaded to central by some
ASF committer either direclty or uploaded via JIRA: how can we track
down this?
I checked MAVENUPLOAD and the first reference about junit is:
http://jira.codehaus.org/browse/MAVENUPLOAD-1168
And it is about junit 4.1: the submitter say he took the pom from 4.0
and updated it.. so this doesn't help for now. IF the original junit pom
was under the CPL then probably that user was not entitled in altering
the content and submit it to the ASF and the ASF should not have
uploaded it to central (is this right?).
----------------------------------------------------
How can we better check the provenance of that file?
----------------------------------------------------
*If* we find the provenance of that file then I think that jspf can be
released as is without repackaging. The next release will have better
header, but the current release include files we can redistribute.
>> We (JAMES PMC) have already very big problems in making 1 release in 1
>> year I don't think we can afford also to be the first to solve general
>> ASF issues.
>
> each project is self-organising and responsible to the members for the
> conduct of it's project alone
Yes, and this may be one of our problems ;-)
Or maybe every other PMC should be so diligent and every other PMC
should stop releasing ;-) [joking]
>> All the messages I wrote in past about licensing/copyrights and legal
>> stuff prove that I'm keen to solve them and when they have not been
>> solved is because no one gave clear answers to the questions I made. I
>> cannot pay a lawyer to have answers.
>
> apache has access to lawyers but the question needs to be clear and
> one of legality not policy
Right. That's why I would like to understand what are the ASF policies
restrictions and then understand if we need to make questions to the
lawyers (I always read the 3rd party wiki and legal-discuss messages to
try to stay up to date but this is not enough.
Here are some included now:
- YOU MAY ALSO include a feature within an Apache product that allows
the user to explicitly choose to download an optional third-party
add-on, as long as that feature also alerts the user of the associated
license. (so it should be anyone a excluded licence, but a license must
exists, and it should be optional, and it should be asked to the user)
- YOU MAY reference a prohibited work (e.g. with text or hyperlinks)
from an apache.org web page or identify the work as a system requirement
for the proper operation of the Apache product. (we are entitled to
reference prohibited work, but this doesn't tell we can make maven to
download it)
There are 6 issues in my old message. Even if I can discuss for years
this thing, I think I cannot do anything "propositive" until we have the
answers to that.
>> So my only alternative is to stop
>> releasing. Sad, but I can accept this, now.
>
> IMHO that's not necessary: there are usually ways around these issues
Any suggestion?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 27, 2008 at 10:03 AM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
> I'm not against the stage folder. I would prefer to see a better support
> from maven to the stage folder (currently is the best hack I found to
> satisfy our strict requirements) but I can live with the current
> approach. I just want a SOLUTION to this release/pom issue. I'm tired
> that we are the only ASF project that everytime has issues in releasing
> using maven. This is disappointing.
JAMES is an old project and some people here remember when maven
kicked off. maven has had problems with release compliance along the
way but it has a good track record of solving issues like these given
time.
> If maven is not suitable to make ASF releases (every maven2 based ASF
> projects depends on junit and remotely download junit.pom under an
> unkown license from central when you build it) then I think this should
> be taken into high priority in the ASF board discussions and some clear
> policy written and maybe the maven PMC should be suggested to stop
> releasing while they don't fix this critical issue.
the substantial issue is not dependency but distribution. maven may
download documents of unknown provenance at runtime but this is very
different from distributing such a document.
AIUI the download is likely to be covered by fair use and if an
infringement occurs then it is the original uploader who is at fault.
by distributing such an artifact, US law makes apache responsible for
ensuring that we have the required license. we know that we lack the
license. this is risky from a copyright perspective.
> We (JAMES PMC) have already very big problems in making 1 release in 1
> year I don't think we can afford also to be the first to solve general
> ASF issues.
each project is self-organising and responsible to the members for the
conduct of it's project alone
> All the messages I wrote in past about licensing/copyrights and legal
> stuff prove that I'm keen to solve them and when they have not been
> solved is because no one gave clear answers to the questions I made. I
> cannot pay a lawyer to have answers.
apache has access to lawyers but the question needs to be clear and
one of legality not policy
> So my only alternative is to stop
> releasing. Sad, but I can accept this, now.
IMHO that's not necessary: there are usually ways around these issues
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Wed, Mar 26, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> For jSieve you found that we had false dependencies and worked out a
>> good solution that allowed us to remove the whole stage folder (that I
>> repeat we simply introduced to satisfy a request by Noel to not use
>> remote repositories to retrieve dependencies during a build).
>
> Noel raised this issue, but I absolutely agree that projects should be
> self-containing and not depend on contents of remote repositories.
> This is not a nuisance and not to satisfy a single person, but to
> solve an issue.
>
> BTW, at my current customer's site, access to standard maven
> repositories is blocked. This renders a great part of modern open
> source projects useless. Great! (James source distribution included.
> It does not ship the stage directory while svn access is blocked, too,
> of course.)
>
> Bernd
I'm not against the stage folder. I would prefer to see a better support
from maven to the stage folder (currently is the best hack I found to
satisfy our strict requirements) but I can live with the current
approach. I just want a SOLUTION to this release/pom issue. I'm tired
that we are the only ASF project that everytime has issues in releasing
using maven. This is disappointing.
If maven is not suitable to make ASF releases (every maven2 based ASF
projects depends on junit and remotely download junit.pom under an
unkown license from central when you build it) then I think this should
be taken into high priority in the ASF board discussions and some clear
policy written and maybe the maven PMC should be suggested to stop
releasing while they don't fix this critical issue.
We (JAMES PMC) have already very big problems in making 1 release in 1
year I don't think we can afford also to be the first to solve general
ASF issues.
All the messages I wrote in past about licensing/copyrights and legal
stuff prove that I'm keen to solve them and when they have not been
solved is because no one gave clear answers to the questions I made. I
cannot pay a lawyer to have answers. So my only alternative is to stop
releasing. Sad, but I can accept this, now.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Mar 26, 2008 at 11:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>
> For jSieve you found that we had false dependencies and worked out a
> good solution that allowed us to remove the whole stage folder (that I
> repeat we simply introduced to satisfy a request by Noel to not use
> remote repositories to retrieve dependencies during a build).
Noel raised this issue, but I absolutely agree that projects should be
self-containing and not depend on contents of remote repositories.
This is not a nuisance and not to satisfy a single person, but to
solve an issue.
BTW, at my current customer's site, access to standard maven
repositories is blocked. This renders a great part of modern open
source projects useless. Great! (James source distribution included.
It does not ship the stage directory while svn access is blocked, too,
of course.)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Wed, Mar 26, 2008 at 10:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>> > looks good
>> >
>> > only possible issue are those PITA poms without license headers in the
>> > stage directory :-/
>>
>> IIRC the issue has been raised [1] in legal-discuss and in repository
>> lists but we had no solution to the fact that most poms in the maven
>> repository have no license headers.
>
> the real problem is the complete lack of auditable process involved:
> there's no way to track down who did what when
Hi Robert, you are right. Here are the details:
files in stage\org.apache.james have been created by us. poms include
the ALv2 header while xmls dont because of maven issues during deploying
to the repository (and we used the deployed ones).
stage\org.jvyaml\poms\jvyaml-0.2.1.pom has been created by me.
stage\uk.nominet\poms\dnsjnio-0.9.9.pom has been created by me.
stage\commons-cli\poms\commons-cli-1.1.pom has been downloaded from central.
stage\dnsjava\poms\dnsjava-2.0.5.pom has been created by me
stage\junit\poms\junit-3.8.1.pom has been downloaded from central.
stage\log4j\poms\log4j-1.2.14.pom has been downloaded from central.
I think we can assume that log4j and commmons-cli have been created by
ASF committers and even if they don't include a license header they are
intended under the ALv2 by their respective projects, but this is not clear.
The main issue is the junit pom: it doesn't contain a license header and
is not from ASF, and AFAIK there is nothing in the process to upload a
file to central that make it clear that the file will have to be
redistributable and compatible with given licenses. Once it is clear
this we will also know whether we can include it in our distribution or
we can only use it via remote download by maven or we can't do anything
with it.
>> For jSieve you found that we had false dependencies and worked out a
>> good solution that allowed us to remove the whole stage folder (that I
>> repeat we simply introduced to satisfy a request by Noel to not use
>> remote repositories to retrieve dependencies during a build). I'm not
>> sure this can be done for jSPF.
>>
>> I can raise the issue again on legal discuss but I don't think it is
>> good to stop releasing because of this issue while all of other PMC are
>> releasing.
>
> the members delegate supervision of each project to it's PMC. the
> JAMES PPMC is responsible for it's releases. in addition, i'm unaware
> of any other projects that ship staging repositories in the way that
> JAMES does.
I thought the problem is the unknown license for poms in the central
repository for maven. MOST m2 based ASF projects declare dependencies on
poms that have no license on central and during the build this very poms
are automatically download (without user notice) and used for the
building process. I thought that this is not allowed if you don't know
what the license/copyright for that files is and because there is no
policy declared by "central" on what people can do with what they
download from that server.
We also include them in the package, but I think this is a secondary
issue: first it should be made clear what people can do with that files,
don't you think?
>> Given the current answers we have on the topic I'm not even
>> sure that the jSieve solution is ok: is it ok for an ASF product to
>> require remote inclusion of artifacts (POM/metadata) under an unknown
>> license?
>
> distributing documents of unknown provenance within a release is
> clearly and simply unacceptable
>
> jsieve does not do this. a user may download temporary POMs without
> licenses but maven does this all the time anyway. jsieve has an ant
> build and anyone who wants to avoid this problem can use that instead.
You are right on jSieve. But I'm interested in the generic maven
solution: most ASF projects make use of poms from central. MANY poms in
central have unknown procenance. I think this is an issue the board
should take care of, because PPMCs don't seem to give enough importance
to this, RIGHT?
I don't understand why most policy/legal issues are raised when JAMES
PMC makes a release (and we only do 1 release per year) while other PMCs
release daily under the "same rules" and they are not vetoed.
>> Either the ASF board take a position on the maven repository poms/xmls
>> or IMHO we can *temporarily* ignore the issue as everyone else is doing.
>
> i'm on the legal committee so that's hard for me to ignore the issue
This is very good that you are in the legal committee. Please help us
having a definitive answer (and publish them in some ASF policy page) on
the questions:
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200710.mbox/%3C19775822.2379651191325380332.JavaMail.root@elysia.void.it%3E
This will help a lot.
>> Maybe you, Noel, Danny or other more experienced ASF members are more
>> entitled in understanding the entity of this issue and ask the Board to
>> take this issue into consideration and give us an answer about what to do.
>
> no experience is requried to take this to the board, anyone on the
> PPMC can do ot. indeed, it would probably be better if you did it.
I did this with repository and legal-discuss and I had no answer. I
understood that the PMC Chair is the best candidate to bring issues to
the Board. I'll make sure (by pinging Danny) that this issue is included
in our next report. OK?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jSPF] poms, copyright, license, again... (Was: [VOTE] jSPF-0.9.6)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Mar 26, 2008 at 10:07 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > looks good
> >
> > only possible issue are those PITA poms without license headers in the
> > stage directory :-/
>
> IIRC the issue has been raised [1] in legal-discuss and in repository
> lists but we had no solution to the fact that most poms in the maven
> repository have no license headers.
the real problem is the complete lack of auditable process involved:
there's no way to track down who did what when
> For jSieve you found that we had false dependencies and worked out a
> good solution that allowed us to remove the whole stage folder (that I
> repeat we simply introduced to satisfy a request by Noel to not use
> remote repositories to retrieve dependencies during a build). I'm not
> sure this can be done for jSPF.
>
> I can raise the issue again on legal discuss but I don't think it is
> good to stop releasing because of this issue while all of other PMC are
> releasing.
the members delegate supervision of each project to it's PMC. the
JAMES PPMC is responsible for it's releases. in addition, i'm unaware
of any other projects that ship staging repositories in the way that
JAMES does.
> Given the current answers we have on the topic I'm not even
> sure that the jSieve solution is ok: is it ok for an ASF product to
> require remote inclusion of artifacts (POM/metadata) under an unknown
> license?
distributing documents of unknown provenance within a release is
clearly and simply unacceptable
jsieve does not do this. a user may download temporary POMs without
licenses but maven does this all the time anyway. jsieve has an ant
build and anyone who wants to avoid this problem can use that instead.
> Either the ASF board take a position on the maven repository poms/xmls
> or IMHO we can *temporarily* ignore the issue as everyone else is doing.
i'm on the legal committee so that's hard for me to ignore the issue
> Maybe you, Noel, Danny or other more experienced ASF members are more
> entitled in understanding the entity of this issue and ask the Board to
> take this issue into consideration and give us an answer about what to do.
no experience is requried to take this to the board, anyone on the
PPMC can do ot. indeed, it would probably be better if you did it.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org