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 of
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 distribute
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 license.
I think that the conclusions we can draw from this elongated discussion are:
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
http://java.sun.com/products/javamail/JavaMail-1_2-spec-license.html
http://java.sun.com/products/javamail/
(click on 'Continue' button for more information on the license for redistribution)
So I believe that further discussion on this thread is unlikely to bring any new information without expert legal advice.
For more information, see
http://maven.apache.org/sun-licensing-journey.html
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 allowed."
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.
Alex.
