David Jencks ha scritto:
On Jun 18, 2008, at 9:55 AM, Stefano Bagnara wrote:
David Jencks ha scritto:
Thinking about the situation a little more....
the normal maven generated artifacts (jar, source, javadoc jars) can
get the m-r-r-p generated legal files as they include what maven
expects from these artifacts
On the other hand, you need to have hardcoded LICENSE and NOTICE
files in svn at the expected checkout root that apply to everything
in the checkout. Since you have the maven repo in the checkout, you
have to include all the legal goo for everything in the repo in those
LICENSE and NOTICE files; thus they will also be suitable for the
distro zip/tar.gzs.
Does that make sense?
This wouldn't solve the binary zip distribution: it includes and
redistribute the runtime dependencies.
We would need another LICENSE/NOTICE tuple for it :-(
I haven't studied the exact contents of all the generated files and I
may not have outlined all the legal requirements as I understand them...
let me try again:
1. an svn checkout must include at the root a LICENSE and NOTICE file
that applies to the entire content of the svn checkout. Here that would
include the bits for the stuff in the svn repo (stage dir). You can't
generate this, it has to be in svn.
I thought this was true only for projects creating the src distribution
by svn exporting the source tree.
2. each artifact distributed from apache must include a LICENSE and
NOTICE file applying to the contents of that artifact.
IIUC since james source doesn't include code that is from elsewhere with
different licensing/notice requirements, any jar/source-jar/javadoc-jar
of james code thus needs the standard boilerplate LICENSE and NOTICE
file; you probably want to include the project name in the NOTICE file;
this is exactly what you get from the m-r-r-p without any additions.
Using m-r-r-p means you don't need to deal with one copy of these files
per maven module, and that if the language changes, maven will fix it
for you when you update plugin versions.
Since IIUC the pmc policy here is that everything that is included in
the binary distros has to be in source or stage, it looks to me like the
required hardcoded-in-svn legal files for (1) would be the legal files
you'd need for the source and binary distros.
No.
We have
jar => no dependencies included (LICENSE&NOTICE-JAR)
source-jar => no dependencies included
javadoc-jar => here m-r-r-p includes the same LICENSE/NOTICE created for
the binary jar: under your reasons this does not seems appropriate
((LICENSE&NOTICE-JAVADOC)
binary-zip => this includes the jar and its *runtime* dependencies, so
it will require (LICENSE&NOTICE-BINZIP)
source-zip => this includes all of the dependencies
(compile/runtime/test) so it will require another tuple
((LICENSE&NOTICE-SRCZIP)
In the james-server project we also create different packages for the
phoenix-deployment, the mailetapi-sdk and the spring-deployment: they
would require 3 more LICENSE&NOTICE tuples.
Are we sure that if I include the bigger LICENSE&NOTICE from the one
aboves in ALL of our packages I'm breaking #2. In fact my LICENSE&NOTICE
from a legal point of view protect us because I'm sure I'm informing the
user about the copyrights/license of what I include. I don't see a
problem in telling him something more about something I don't include.
In most Licenses for product I use I read a lot of boilerplate that does
not apply to the specific product I use, but the licensor simply use the
same license for each product. Some term is clearly out of scope, but I
don't this this make the license invalid. IMHO the same applies to our
use case.
I agree that in a perfect world each artifact would have its own perfect
NOTICE/LICENSE file, but what I want to understand is what the board say
we MUST do and what the board say you SHOULD do that but it is a policy
issue and each PMC is entitled to decide this.
To mantain a LICENSE/NOTICE tuple for each released artifact is a PITA
and IMHO unnecessary waste of time.
So, I'd use m-r-r-p for the normal maven jars and configure the assembly
plugin to include the legal files for (1) in the distros.
I started feeling much more strongly about making the NOTICE files
correct (without extra verbiage) after reading Roy Fieldings comments on
legal-discuss back in january on the LICENSE and NOTICE files and SVN
thread.
You see I was in that thread too with many post about my opinions and
doubt about mixing policies, legal requirements and personal
preferences. I still have the same doubt I had before that thread.
From my understand each one ended up keeping his previous opinion and
we had no new board "rules" from that.
I personally didn't reply to this:
http://markmail.org/message/mrbob6xo7c42bqh3
only because if it is true then I would resign from the PMC because I
don't want to be liable for each commit made by others and we could skip
the release vote process at all because our repository would be always
releasable and we would need to vet each commit in RTC as a written rule
by the board.
No single person will convince me ( :-) ) that a NOTICE file in a random
folder allow me to stop violating IP for a file in another random
folder: either you link them someway or the NOTICE file is useless.
The root folder of a redistributed package is clearly a special place, a
random parent folder in the svn repository is not so special to make you
liable or make you safe IMHO.
I would like to understand what kind of IP we violate bu having this
file there:
http://svn.apache.org/repos/asf/james/server/trunk/stage/javax.mail/jars/mail-1.4.1.jar
if we removed this file:
http://svn.apache.org/repos/asf/james/server/trunk/NOTICE.txt
I doubt there is a law (in any country) telling people that if they
obtain a file from an url then they have to try to request for the
NOTICE.txt file in each parent folder:
http://svn.apache.org/repos/asf/james/server/trunk/stage/javax.mail/jars/NOTICE.txt
http://svn.apache.org/repos/asf/james/server/trunk/stage/javax.mail/NOTICE.txt
http://svn.apache.org/repos/asf/james/server/trunk/stage/NOTICE.txt
http://svn.apache.org/repos/asf/james/server/trunk/NOTICE.txt
until you find one and then you have to take it for good.
BTW I am only one more troll in the repeating NOTICE/LICENSE flame. I
would simply like to have the board publish clear RULES about what ASF
committers HAVE TO do regarding releases and svn, and what
behaviour/solutions are policies to be defined by single PMCs. I would
keep my opinion on what is legally required or not, but I would for sure
follow the board requirements.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
