www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <bay...@apache.org>
Subject Re: Legal issues in re-bundling some binary dependencies
Date Wed, 12 Mar 2008 21:38:47 GMT
On Wed, Mar 12, 2008 at 11:06 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>
> On Wed, Mar 12, 2008 at 1:19 AM, Henri Yandell <bayard@apache.org> wrote:
>  > On Tue, Mar 11, 2008 at 4:24 PM, Alan Cabrera <adc@toolazydogs.com> wrote:
>  >  >
>  >  >  On Mar 11, 2008, at 2:09 PM, Guillaume Nodet wrote:
>  >  >
>  >  > > ServiceMix 4 is being developed based on OSGi.  OSGi require all the
>  >  >  > jars to be "OSGi bundles", which means that they contain some OSGi
>  >  >  > specific entries in the jar manifest.   Lots of our dependencies are
>  >  >  > not already OSGi bundles, so we need to repackage those so that we
can
>  >  >  > acutally use them.
>  >  >  > The process is to extract / unzip the jar, modify the manifest and
>  >  >  > repackage it under another name.
>  >  >  > I just found that it may be a problem for jars categorized as "binary
>  >  >  > license compatible" with the ASL: I'm mainly thinking about CDDL for
a
>  >  >  > few sun jars that we need, namely jaxb2 spec jar, jaxb2 implementation
>  >  >  > and saaj implementation which are all under CDDL.
>  >  >  > Is my assumption right that such jars can not be modified and
>  >  >  > distributed and that such restrictions does not apply for BSD style,
>  >  >  > public domain, CPL and AL2 ?
>  >  >
>  >  >  The OSGi additions are merely descriptions of the jar in a canonical
>  >  >  form, per OSGi.  They are additions to the jar driven by the contents
>  >  >  of the jar and are not modifications.  To be sure the manifest is
>  >  >  modified but that is part of its raison d'etre; the file is there for
>  >  >  others to also be able to jam in their information in.
>  >
>  >  "Modifications" is described by CDDL (and the MPL family of licenses
>  >  in general iirc) as additions or deletions to a file under the CDDL.
>  >
>  >  So changes to the manifest, if it is under CDDL, are intended to be
>  >  CDDL. And changes to the jar are very arguably intended to be CDDL
>  >  [would depend on whether you argue it's an executable or a zip I
>  >  think].
>  >
>  >
>  >  >  The point in distributing binaries for jars w/ reciprocal licenses,
>  >  >  IIUC, is that there is less exposed surface area of the third-party
>  >  >  work from which a work might be derived.  In this case modifications
>  >  >  by users are not built on top of these OSGi descriptions; they cannot
>  >  >  provide the toe hold that binary distributions are meant to
>  >  >  minimize.  Instead, the OSGi descriptions would change, if at all, to
>  >  >  accurately describe the new jar.
>  >  >
>  >  >  IMO, I think it's kosher.
>  >
>  >  If we are happy producing original content under CDDL, then it would
>  >  be fine. I think in this use case, we should go ahead and allow it,
>  >  adding the use case of:
>  >
>  >  "Insertion of OSGi metadata into CDDL licensed jars is permitted; even
>  >  though that metadata becomes CDDL licensed when it is put in the jar"
>  >
>  >  We should consider adding CPL/EPL/MPL to that use case too.
>  >
>  >  Any thoughts? Is anyone violently opposed to the ASF technically
>  >  creating non AL 2.0 material in this case; and under a license more
>  >  restrictive than AL 2.0?
>
>  "Technically"?  Don't waffle.  :-)
>
>  The need to do this is legitimate.  The carefully scoped use case that
>  you laid out is both pragmatic and not overreaching.  The remaining
>  question I have: how will this be documented?  I would hope that
>  ServiceMix could come up with something that would provoke a "What?
>  Oh, that makes sense." up front instead of a "WTF!!!" much later.

Assuming the PMC are happy with it -
http://wiki.apache.org/legal/ResolvedLegalQuestions :)

As that fills up with data we can organize it accordingly. If we end
up with a policy document, then the abstract of this permission can be
worked into it.

Hen

---------------------------------------------------------------------
DISCLAIMER: Discussions on this list are informational and educational
only.  Statements made on this list are not privileged, do not
constitute legal advice, and do not necessarily reflect the opinions
and policies of the ASF.  See <http://www.apache.org/licenses/> for
official ASF policies and documents.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message