www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <cliffschm...@gmail.com>
Subject Re: Two weeks left for comments! (was: [Request For Comment] Third-Party Licensing Policy)
Date Wed, 29 Mar 2006 08:02:57 GMT
On 3/24/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> On 3/24/06, Henri Yandell <bayard@apache.org> wrote:
> >
> > Not distribute or automatically include - user has to manually choose to
> > use it.
> >
> > That applies to the NPL, BCL, LGPL, GPL and I think any other licence that
> > doesn't match the category A and B sections.
> One interesting question that was brought up on IRC but doesn't seem
> to have made it to this mailing list was how does that work with
> binary packages?
> I mean we obviously can't release binary packages that include one of
> these licenses, but what about packages that link against them
> (assuming they've been declared as a system library) and include that
> dependency in the package system metadata.  Thus when a user installs
> the package their package management tool would likely prompt them to
> install the dependency, which is under LGPL/GPL/Sleepycat/whatever
> license.  Depending on the tool it's not clear if the license issue
> would be brought to the user's attention or not.
> An example of how this can happen today, take APR-Util packages that
> depend on Berkeley DB.  We don't distribute Berkeley DB code, but and
> APR-Util doesn't try to link against it by default, but we do have
> some binary packages that are linked against BDB.  Is that allowed by
> this policy?
> This is not an overly huge deal for APR-Util, we could just stop
> shipping packages that are linked against BDB.  But what about a
> project where the BDB dependency was less easy to remove.  Say,
> hypothetically, that the Subversion project had tried to move to the
> ASF back before BDB was an optional dependency for a Subversion
> server, if we had been operating under this policy would it have
> required us to forbid them from distributing binary packages linked
> against BDB?

I think the dynamic linking that APR does with BDB is perfectly fine. 
If SVN used to require static linking with BDB to create one big
executable with an embedded DB, then that would have been an example
that the current policy draft would prohibit both distributing in
executable form or distributing the source/object code with
instructions or a build file to force the user to create the same
executable on their machine.

Here's how the applicable part of the policy reads in the current (v0.52) draft:

(from http://people.apache.org/~cliffs/3party.html#options-build-mustnot1)

"YOU MUST NOT distribute build scripts or documentation within an
Apache product with the purpose of causing the default/standard build
of an Apache product to include any part of a prohibited work."

Maybe this needs to be reworded a little.  Let me first say what I was
trying to accomplish with it.  I think it would be a bad idea for us
to decide that on one hand we won't include GPL'd works within an
Apache product, but then distribute a product that require static
linking with a GPL'd work on the user's system to produce a standard
binary.  In other words, standard product binaries, whether
distributed by Apache or built on the user's machine should have the
same applicable licenses.

There's certainly nothing wrong with an Apache product dynamically
using a GPL'd work as a system requirement, nor with the product
depending on the presence of a Microsoft Windows operating system or a
Sun JVM.  The key is to not let the Apache product get confused with
the system requirements it depends on.

So, any thoughts on how to better word the requirement listed above? 
Does it help to talk about static linking with the prohibited work or
embedding the prohibited work inside the product?


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