Petals BC SOAP

Java Mail API is packaged twice

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 4.0.7
  • Fix Version/s: 4.0.8, 4.1
  • Component/s: None
  • Security Level: Public
  • Description:

    The mail API is packaged twice into the component JBI archive:

    • mail-1.4.jar
    • geronimo-javamail_1.4_spec-1.5.jar

    Remove mail-1.4.jar because of the licence (prefer Apache licence instead of CDDL)

  • Environment:
    -

Activity

Hide
Adrien Ruffie added a comment - Mon, 19 Dec 2011 - 14:35:14 +0100

Thank Laurent, therefore we don't need to change anything ?

Show
Adrien Ruffie added a comment - Mon, 19 Dec 2011 - 14:35:14 +0100 Thank Laurent, therefore we don't need to change anything ?
Hide
Laurent Lacôte added a comment - Mon, 19 Dec 2011 - 11:46:13 +0100

Hi all.
Marc told me about this discussion, which is about a library that is dynamically linked to Petals at runtime, if I don't misunderstand.
In the CDDL, the point 3.5 allows distribution of executable form under any license, as long as user's rights on the library (code and executable) stay unharmed. As the LGPL is also an open source license, rights are kept.
Also, the definition of "covered software" clearly restricts its scope to reuse or modification of code ("files that contain"), so a plain runtime link has good chances to fall outside this scope (although no legal document/court decision decided this once and for all yet).
On the LGPL side, the article 6 permits the distribution of such a package (Petals + third party software) in executable form, under terms of our choice, as long as existing user rights are kept.

I found this page, that told that most source code was under CDDL and/or GPLv2 with CLasspat. But this source didn't seem very reliable.

I then checked the Oracle Development License which tells that it doesn't limit the rights granted under and open source license. I downloaded the component (javamail-1.4.4.jar), checked the license of every component, all were plain CDDL (except dsn.jar which had no license.txt).

So, unless I missed something, I don't see any incompatibility of linking this library with Petals.

Show
Laurent Lacôte added a comment - Mon, 19 Dec 2011 - 11:46:13 +0100 Hi all. Marc told me about this discussion, which is about a library that is dynamically linked to Petals at runtime, if I don't misunderstand. In the CDDL, the point 3.5 allows distribution of executable form under any license, as long as user's rights on the library (code and executable) stay unharmed. As the LGPL is also an open source license, rights are kept. Also, the definition of "covered software" clearly restricts its scope to reuse or modification of code ("files that contain"), so a plain runtime link has good chances to fall outside this scope (although no legal document/court decision decided this once and for all yet). On the LGPL side, the article 6 permits the distribution of such a package (Petals + third party software) in executable form, under terms of our choice, as long as existing user rights are kept. I found this page, that told that most source code was under CDDL and/or GPLv2 with CLasspat. But this source didn't seem very reliable. I then checked the Oracle Development License which tells that it doesn't limit the rights granted under and open source license. I downloaded the component (javamail-1.4.4.jar), checked the license of every component, all were plain CDDL (except dsn.jar which had no license.txt). So, unless I missed something, I don't see any incompatibility of linking this library with Petals.
Hide
mjambert added a comment - Thu, 15 Dec 2011 - 12:18:03 +0100

This mention is necessary to be compliant with GPL v2.0.
AFAIK, this is not the license under which petals is distributed... These questions are not necessarily simple. No offense but I prefer relying on Laurent on this. I'll ask him to comment on the issue this afternoon.

Show
mjambert added a comment - Thu, 15 Dec 2011 - 12:18:03 +0100 This mention is necessary to be compliant with GPL v2.0. AFAIK, this is not the license under which petals is distributed... These questions are not necessarily simple. No offense but I prefer relying on Laurent on this. I'll ask him to comment on the issue this afternoon.
Hide
Christophe DENEUX added a comment - Thu, 15 Dec 2011 - 12:01:23 +0100

Each SUN licence must be checked to be sure that we are authorized to redistribute the SUN artifact. If the SUN licence does not include the "Classpath exception" we can'nt distribute the artifact. That's why I prefer Apache licence than SUN licence.

Show
Christophe DENEUX added a comment - Thu, 15 Dec 2011 - 12:01:23 +0100 Each SUN licence must be checked to be sure that we are authorized to redistribute the SUN artifact. If the SUN licence does not include the "Classpath exception" we can'nt distribute the artifact. That's why I prefer Apache licence than SUN licence.
Hide
mjambert added a comment - Thu, 15 Dec 2011 - 11:42:15 +0100

Who stated that we should prefer Apache licence to CDDL ? As far as I remember, Laurent said there was no problem with CDDL, and personally I would rather thrust Sun more than Apache to implement their spec correctly.

Thus, Could you elaborate on your "prefer Apache licence instead of CDDL".

Show
mjambert added a comment - Thu, 15 Dec 2011 - 11:42:15 +0100 Who stated that we should prefer Apache licence to CDDL ? As far as I remember, Laurent said there was no problem with CDDL, and personally I would rather thrust Sun more than Apache to implement their spec correctly. Thus, Could you elaborate on your "prefer Apache licence instead of CDDL".
Hide
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 11:00:14 +0100

Into the trunk geronimo library has been replaced by javax.mail -> mail-1.4.4.jar because javax.mail was already taken

Show
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 11:00:14 +0100 Into the trunk geronimo library has been replaced by javax.mail -> mail-1.4.4.jar because javax.mail was already taken
Hide
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 09:47:49 +0100

bad copy/cut isn't StAX API but mail API -> StAX API is for http://jira.petalslink.com/browse/PETALSBCSOAP-90 issue

Show
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 09:47:49 +0100 bad copy/cut isn't StAX API but mail API -> StAX API is for http://jira.petalslink.com/browse/PETALSBCSOAP-90 issue
Hide
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 09:40:47 +0100

The library isn't duplicate in trunk

Show
Adrien Ruffie added a comment - Thu, 15 Dec 2011 - 09:40:47 +0100 The library isn't duplicate in trunk
Hide
Christophe DENEUX added a comment - Wed, 21 Sep 2011 - 11:06:14 +0200

To merge in trunk

Show
Christophe DENEUX added a comment - Wed, 21 Sep 2011 - 11:06:14 +0200 To merge in trunk
Hide
Christophe DENEUX added a comment - Wed, 21 Sep 2011 - 11:06:04 +0200

Fix in branch petals-entreprise-3.1.x

Show
Christophe DENEUX added a comment - Wed, 21 Sep 2011 - 11:06:04 +0200 Fix in branch petals-entreprise-3.1.x

People

Dates

  • Created:
    Wed, 21 Sep 2011 - 10:39:16 +0200
    Updated:
    Thu, 16 Feb 2012 - 17:06:27 +0100
    Resolved:
    Thu, 15 Dec 2011 - 09:44:28 +0100