james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [jsieve] Any more TODO before 0.2 release?
Date Wed, 18 Jun 2008 17:18:22 GMT

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.
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.

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.

david jencks

> We don't need the m-r-r-p at all if the LICENSE/NOTICE file that we  
> want to include there does not include depdencies because all of our  
> products (JAMES PMC) do not include non ASF code in the main binary  
> jar. So no need to use a complex autogenerated tuple to simply add 2  
> static simple files.
> I'm still for a single LICENSE/NOTICE including everything (build/ 
> test/runtime dependencies) and used even in the jar only: this makes  
> life less easy for users but I think this is the best "compromise"  
> to be sure we comply to legal requirements and we don't waste our  
> time with plenty of different LICENSE/NOTICE files for each use case.
> Furthermore, from a user perspective I find it more useful to read  
> once single LICENSE/NOTICE and understand what all the dependencies  
> are and what are their license/requirements instead of seeing that  
> the jar alone does not have requirements and then having to manually  
> download the runtime dependencies and check their license one by one.
> Stefano
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message