geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: Geronimo 2.0 License and Notice Files
Date Thu, 12 Jul 2007 09:46:05 GMT

On Jul 11, 2007, at 10:08 PM, Matt Hogstrom wrote:

> On Jul 11, 2007, at 12:24 PM, Kevan Miller wrote:
>> If some people could review, that would be great.
> on the Active-IO question there is some coding work to be done.   

Ya. I've started looking into this...

> All of the OpenEJB mods should be AL 2.0 but it sounds like there  
> is some work to do in OEJB.  I'll ping the list.

Yes. Would certainly be fixed before OpenEJB could be released. I'm  
planning on fixing when I have a few minutes...

>> Next steps and pseudo-random license trivia:
>> Many jar archives included by Geronimo do not include LICENSE or  
>> NOTICE files. In most cases, I've tracked down the appropriate  
>> LICENSE information for the resource, and included a url for the  
>> LICENSE file. I haven't always done this. So, some work still  
>> remains. Most/all of this remaining work involves Apache projects.  
>> So, I don't invision a big problem. In some of the cases, the work  
>> is not chasing down the license information, but insuring that  
>> appropriate LICENSE/NOTICE files are generated in the original jar  
>> archive (e.g. OpenEJB).
> For the rather long list of jars that don't have any embedded files  
> is there a recommendation ?  Unlikely we'll get them fixed.

We don't need to insure that all jar files contain license/notice  
information. That's not our job -- it's the responsibility of the  
individual projects. One exception might be any jar files which we  
are generating (e.g. Tomcat).

Apache's current policy is that all released artifacts need to  
include LICENSE/NOTICE files. Jar files used to be bundled in a  
binary distribution. The binary distribution would contain any  
LICENSE/NOTICE files, but lots of times the jar files did not. Now-a- 
days, jar files should be treated as separately "released" artifacts  
-- they're placed individually in maven repos, etc. So, most projects  
put LICENSE/NOTICE information into jar files, also.

Since we embed so many projects, I must say that this practice is  
great. To gather license/notice information, we just need to crack  
open the jars and aggregate the license/notice information. For jars  
that don't self-document their license, we need to obtain the license/ 
notice information for the jars we're using. I think that I've done  
this for all non-apache jar files. We need to do the same research  
for the apache jars.

I'll take this opportunity to point out what I think is good practice  
-- jar files should contain license/notice information specific to  
the jar file (i.e. they should not re-use the project-wide license/ 
notice files). Worst case is those projects (myfaces is an example)  
who have something like the following in their NOTICE file:

See the file LICENSE.txt
See licenses for accompanying products in the "/licenses" subdirectory.

where there is no "/licenses" subdirectory in the jar. So, we're  
still forced to download source or the entire binary to obtain the  
necessary information...

>> We currently include all of our LICENSE information in a single  
>> root LICENSE.txt file. Some Apache projects include a licenses/  
>> directory, instead. This directory includes all of the non-ASL  
>> licenses for the project. Although it's probably a bit more work,  
>> I personally prefer a single file. However, this is a debatable  
>> point. If others have an opinion, they are welcome to voice it.
> One file would be my preference.
>> The root LICENSE.txt and NOTICE.txt files (by "root" I mean the  
>> license/notice file in the bottom level directory of our source  
>> and binary distributions) contain the license info for the entire  
>> assembly.
>> We don't currently have different license/notice files that are  
>> specific to our Jetty/Tomcat CXF/Axis distributions. Nor do we  
>> attempt to generate license/notice files specific to our minimal  
>> assemblies. So current course and speed, our root license/notice  
>> files will be a superset of all of our various assemblies. This  
>> seems fine, to me. If anyone sees a problem with this, speak now...
> Perhaps a comment that this assembly includes some or all of ....

That sounds like a good approach...


>> Once all of the data in the google spreadsheet is complete, and  
>> we've had a chance to review. I'll plan on generating new  
>> LICENSE.txt, NOTICE.txt, and DISCLAIMER.txt files for our 2.0  
>> release. I'd guess this will be towards the end of the week/over  
>> the weekend. If anyone else is interested in grabbing a shovel and  
>> pitching in, let me know...
>> --kevan

View raw message