james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [jsieve] Any more TODO before 0.2 release?
Date Wed, 18 Jun 2008 18:13:58 GMT
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message