www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <ccust...@apache.org>
Subject Re: More LGPL Questions
Date Sat, 23 Feb 2008 22:00:07 GMT
Comments inline...

On Sat, Feb 23, 2008 at 2:28 PM, Ralph Goers <Ralph.Goers@dslextreme.com>

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

ServiceMix itself does not require the LGPL classes to run.  This scenario
is merely an optional wrapper around ServiceMix core jar files for the
purpose of deploying inside JBoss AS.  So the implementation of the
interfaces is strictly a contract for the purpose of the application server
calling into ServiceMix.

> 2. How is the user notified that LGPL components are used? Can they opt
> out?

This is a fairly high level packaging decision for the user.  A user would
never download the standalone ServiceMix packaging, and then inadvertently
use the LGPL code.  They would choose the packaging that suits their
environment and if necessary we could tell them at that point that the JBoss
deployer package includes code that implements interfaces imported from an
LGPL library I suppose.

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

Like I said, it isn't even part of the project runtime and is only used for
the installation routine, so  there are many other options for installation
and if necessary I think one could disable inclusion of this LGPL binary,
but I am hoping to avoid that if possible.

> Ralph


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