GNU JavaMail Bright Future
"Conrad T. Pino" <[email protected]> Fri, 25 Oct 2013 19:43:11 -0700
| Newsgroups | gmane.comp.java.classpath.extensions.javamail |
|---|---|
| Message-ID | <[email protected]> |
Hello Chris, The GNU JavaMail maildir provider continues as critical component within web sites where I contribute. Moreover it continues as the latest such provider as: * SourceForge (http://sourceforge.net/projects/javamaildir/files/) project last release predates (2006-01-29) the GNU last release. * The Oracle/Sun implementation still lacks a maildir provider. I see the Help Wanted sign is still hanging out still with the "If you have ever seen Sun's source code for any of the APIs..." http://www.gnu.org/software/classpathx/javamail/javamail.html limitation but as Oracle/Sun open sourced the "JavaMail API Reference Implementation" https://java.net/projects/javamail/pages/Home does such limitation still apply to "GNU General Public License (GPL) v2 with Classpath Exception" licensed code? (CDDL ignored by intent) Since Oracle/Sun did release source code, it also raises question about how this project might interact to (A) minimize duplicate implementation and (B) still insure an open future whereas Free Software Foundation is a reliable licensor, Oracle can change it's practice anytime. IMO, these legal theories apply: 1 upon disclosure by the lawful rights holder, trade secret law is forever moot with respect to the disclosed material, 2 GPL v2 does not explicitly grant an "irrevocable" grant as does GPL v3, 3 once acquired while under GPL v2, can Oracle enjoin further use by then licensed users, Groklaw believes clearly not give GPL v2 as stated: http://www.groklaw.net/article.php?story=2006062204552163 I suggest Point 1 above is sufficient to justify taking down the Sun source code knowledge limitation. I suggest GNU JavaMail Project continue but stand still where Oracle/Sun JavaMail API Reference Implementation overlaps other than keeping existing GNU code compliant with current API specification. I want to contribute towards JavaMail API 1.5 compliance. I want to the study feasibility for light-weight MaildirMessage that defers reading the message body until needed. For memory and process efficiency, we want to read messages in large batches where most are uninteresting and we make that determination predominantly from the headers alone. I want study making the GNU JavaMail Maildir Provider interoperate with the Oracle/Sun JavaMail API Reference Implementation. Best regards, Conrad