geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [JavaMail] concerns - it's a legal issue, not a project issue
Date Tue, 19 Aug 2003 12:10:23 GMT
On Tuesday, Aug 19, 2003, at 12:38 Europe/London, James Strachan wrote:

> Danny, I took a quick look at the JavaMail licence and its pretty huge 
> and I"m not too hot at reading big complex licences full of legal 
> speak. Could we redistribute Sun's JavaMail API in binary form as part 
> of the Geronimo project? If so could we also put the jar in the Maven 
> repository to avoid painful user-intervention to get Geronimo to 
> build? (i.e. so that the build process of Geronimo could auto-download 
> Sun's JavaMail API?).
> If we can do the above then I agree creating a clone of the JavaMail 
> API with the various required implementation code to conform to the 
> API might not be a good idea - we might as well just use Sun's API 
> distro. I guess it depends on how we're allowed to reuse Sun's API 
> distro.

Indeed, this is the only reason why creating a JavaMail API is 
necessary. At least this way, we have permission to use it; however, 
that's not to say that we can't use the JavaMail (mailapi.jar) binary 
for redistribution purposes.

Ideally, we need a lawyer who can find out if the license is valid.

In particular:

2. License to Distribute Software. Subject to the terms and conditions 
this Agreement, including, but not limited to Section 3 (Java (TM)
Technology Restrictions) of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license to reproduce and 
the Software in binary code form only.

If this is a non-transferrable license, then the developers can 
distribute JavaMail, but people who build on top of that product 
cannot. So we could not give away Geronimo to someone to build an 
embedded web server, because we would then be (in effect) transferring 
the JavaMail license to that new developer.

These are the kind of clauses I am worried about in the JavaMail 

I think that the conclusions we can draw from this elongated discussion 

o An implementation of the various stores/transports is highly 
desirable/necessary for Geronimo (and perhaps other projects)
o A reimplementation of the API would serve little benefit other than 
to offer the same code under a new license
o No-one really knows (for sure/legally) what the redistribution of 
JavaMail allows and does not allow.

I don't believe that anyone disagrees with these points. However, I 
personally feel that a re-implementation of JavaMail nicely works 
around these issues, whereas Danny feels that the extra maintenance 
overhead of replicating the API is more time-consuming than working out 
the legal issues of JavaMail, and where appropriate, lobbying Sun to 
allow for any legal changes to occur.

I believe the Geronimo PMC/Apache legal should look into the licensing 
issues regarding the (re)distribution of the mailapi.jar file from the 
JavaMail license
(click on 'Continue' button for more information on the license for 

So I believe that further discussion on this thread is unlikely to 
bring any new information without expert legal advice.

For more information, see
which attempts to note Apache's efforts to get Sun to work with the 
licensing. Note that it says that at present that Maven's use of 
JavaMail (which is even less than Geronimo will use it; the former will 
be for interacting with projects for Maven's own use, whereas Geronimo 
is explicitly providing JavaMail for other developers use; there is the 
concept of transferring a license there)
"... Maven's use is in the spirit of the license though not technically 

IMHO this isn't a PMC decision, it's a legal one. Once the legalities 
have been investigated, the PMC can then make the correct decision as 
to which is the preferred way forward.

I am fully aware that should the redistribution of mailapi.jar be 
allowed then this will be the preferable choice. But in the absence of 
this allowance, there is no choice but to re-implement, and that is (as 
I see it) the current position.


View raw message