classpathx-javamail
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Classpathx-javamail] GNU JavaMail Bright Future


From: Conrad T. Pino
Subject: [Classpathx-javamail] GNU JavaMail Bright Future
Date: Fri, 25 Oct 2013 19:43:11 -0700

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]