www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: More LGPL Questions
Date Sat, 23 Feb 2008 21:28:07 GMT

First, let me make it quite clear that this is just my opinion based on 
following many of the discussions on this over the last couple of years.

See below

Chris Custine wrote:
> I know there have been many discussions about LGPL code here recently, 
> but after reading the thread archive and 
> http://people.apache.org/~rubys/3party.html 
> <http://people.apache.org/%7Erubys/3party.html> I would still like to 
> pass two issues to this mailing list for review.
> Scenario #1: 
> For Apache ServiceMix, I am interested in moving the packaging code 
> for the JBoss SAR package of ServiceMix from codehaus to the actual 
> ServiceMix SVN and build process.  To do this would mean maintaining 
> code at Apache that imports certain JBoss Java packages from jar files 
> that are available via the maven central repository.  During the build 
> process, the JBoss jar file would be downloaded and used in the build 
> process via imports and implementing several interfaces from the 
> package, but we would not distribute the jar file, nor would we 
> directly use any source from JBoss.  Obviously JBoss is LGPL, so the 
> question is whether *any* of the following are acceptable:
> 1).  Maintaining said code at Apache.
> 2).  Distributing binary packages that includes such code (if we leave 
> the code at codehaus).
> 3).  Allowing users to download the source and build the packages 
> themselves.

You left off some pieces of information that are critical for me.
1. Does ServiceMix require the LGPL classes to run. If not, then 
ServiceMix might as well be LGPL. If the requirement for LGPL applies to 
something optional I view this as OK (but that is just my opinion).
2. How is the user notified that LGPL components are used? Can they opt out?

> Scenario #2:
> Another issue I am researching is the potential usage of the 
> OpenInstaller[1]  project for building binary installers for end 
> users.  OpenInstaller generates Java based installers from descriptor 
> files and therefore wraps several third party jar files for the 
> installer routines along with the product binaries that you are 
> installing.  The OpenInstaller code itself is CDDL 1.0, but in 
> researching all of the dependencies it appears to include a single 
> LGPL jar file that is used for text based installers.  So clearly the 
> LGPL code is not directly used by the Apache project nor would we 
> distribute it as a core part of the project, but the LGPL jar file 
> would be pulled in during the process of creating the installer 
> package and *may* be used by a user during the install process.  
> However, the functionality of the LGPL file is only used to transfer 
> the project binaries during the installation and is not part of the 
> functionality of the Apache project.  I think it is trivial to short 
> circuit and prevent this LGPL dependency from being included in the 
> generated installation routines, but the functionality may be useful 
> if we can use it.

Again, if the functionality is optional I see no conflict with 
3party.html. Just provide notice of how the LGPL piece can be enabled or 

Another way to look at this problem isn't whether Apache is distributing 
an LGPL'd jar (clearly, that isn't OK) but whether the end user of the 
Apache project would be forced to distribute an LGPL'd jar even if they 
don't want to.  In my opinion, that would not be acceptable.


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

View raw message