www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Barnett" <j...@bea.com>
Subject RE: LGPL-licensed scripting code
Date Tue, 11 Apr 2006 17:29:15 GMT
Hi Don.  IMO there are a couple of issues with the LGPL that are
independent of any nexus to Java, and that could impact any ASF-project
that has any LGPL-covered content or even (arguably) dependencies.

First, the LGPL appears (I say "appears" because it has several
ambiguities) to ascribe the legal status of "derivative work" to any
work you combine (Section 6..."you may also combine or link a 'work that
uses the Library' with the Library"), compile or link (Section 5..."
designed to work with the Library by being compiled or linked with it")
with an LGPL-covered work.  The concept of derivation in copyright law
is not so cut and dried as that presented in the LGPL.  

Licenses like the MPL, CDDL, EPL and CPL, for example, do a much more
Copyright Act consistent job determining whether what you combine with a
covered work is a derivative of the covered work.  It is possible under
these licenses for you to combine, link, compile, etc., your work with a
covered work and not have the whole be a derivative of the covered work.
The LGPL, on the other hand, appears to be categorical and inflexible in
this regard.  If you "combine, compile with or link to" an LGPL-covered
work, the combination is by LGPL definition a derivative.  There are
legal implications when one stipulates to "derivative work" status that
may not be desirable to ASF or to certain classes of downstream ASF
licensees.

Second, the LGPL dictates that for "combined with, compiled with or
linked to works", you must either use the LGPL for your outbound
licensing, or your own license agreement that meets the requirements of
Section 6 of the LGPL.  One such requirement is that you grant an
affirmative right to modify the work and decompile the combined work so
that the user can debug such modifications.  One of the benefits of the
FreeBSD-style ASF license model is that it is friendly to both open
source developers and communities, and to prospective commercial
developers and users.  ASF does not require a commercial distributor of
products incorporating ASF-covered code to allow modification and
decompilation of combination works.  For a proprietary software vendor,
this is pretty critical.  No commercial company wants to affirmatively
permit its commercial competitors to expose its source code for any
reason.  Other requirements are expressed in the alternative, but
generally go to the attribution, pass-through and source code
availability questions, and as a whole are far more intrusive to any
licensee, ASF or downstream, than the ASF equivalents.

I think the LGPL-scripting code situation diagrams as follows:

While WebWork2 may neither link to (whatever that means - it's undefined
in the LGPL and often debated) or compile with (true?) the LGPL-covered
scripting code, pursuant to Section 6 the scripting code is nonetheless
"combined" with WebWork2, so the LGPL would apply to the whole of
WebWork2 and the outbound license for the project would have to comply
with the requirements of Section 6 of the LGPL.  The ASF 2.0 license
does not mandate that licensees "permit modification of the work for the
customer's own use and reverse engineering for debugging such
modifications" as is required by Section 6, or the requirement that a
copy of the LGPL be provided.  Also, the attribution requirements of the
ASF are lighter-weight than the corresponding alternative requirements
in Section 6 of the LGPL.

In the interest of full disclosure, the above is my interpretation.  The
LGPL can reasonably be interpreted in other ways, but I believe the
above interpretation is most defensible in that it covers the various
nuances of derivation in the LGPL, and takes into account the the
flip-flop of terms from "link or compile" in Section 5 to "link or
combine" in Section 6.  IAAL employed by a commercial software vendor,
so my perspective is surely influenced by the context in which I get
open source issues; that is I am asked to evaluate the compatibility of
the inbound open source license with my employer's outbound licensing
models.  Accordingly, I am probably "conservative" when it comes to
interpreting the LGPL.

Regards,

Jim
           

-----Original Message-----
From: Don Brown [mailto:mrdon@apache.org] 
Sent: Tuesday, April 11, 2006 9:36 AM
To: legal-discuss@apache.org
Subject: LGPL-licensed scripting code

As I understand the LGPL issue, Apache's problem with it is FSF isn't
clear on how it applies to Java.  Would this same 
concern affect LGPL-licensed scripting code?

For example, WebWork 2, currently in the Incubator, uses several LGPL
Javascript libraries.  Since the source is always 
distributed (there is no binary), and the linking issue doesn't seem to
come into play, could not Apache distribute this?

TIA,

Don

---------------------------------------------------------------------
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

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---------------------------------------------------------------------
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