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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
