www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: use of Berkeley DB Java Edition for an optional component
Date Mon, 12 Sep 2011 01:26:53 GMT
Given that BDB is not *required* to make Qpid useful, then it is
clearly optional (ie. Qpid works with the Apache-licensed Apache
Derby). And if a *user* chooses an option to use the BDB adapter and
work against the BDB code... that is their choice. You're totally
fine.

Qpid should not ship with the third-party (Cat X) libraries/jars. The
source tarball can be used to build against them.

Your closing three points are all valid, and an allowable solution
[here at the ASF] for these types of dependencies.

Cheers,
-g

On Sun, Sep 11, 2011 at 18:51, Robbie Gemmell <robbie.gemmell@gmail.com> wrote:
> I posted the below on JIRA at
> https://issues.apache.org/jira/browse/LEGAL-99 but haven't got any
> responses yet. Any thoughts out here on the mailing list?
>
> Thanks,
> Robbie
> ========
>
> Hi. I am wondering whether I have appropriately interpreted the
> options for use of a Category X dependency, based on reading of the
> Legal FAQ [1] and to an extent the draft Third Party Licensing Policy
> page [2].
>
> Qpid has [persistent] stores to hold configuration and message data,
> with 3 current implementations (Memory, Derby, and BDB) of the
> interfaces. The last of these depends on Bekeley DB Java Edition which
> is under the Sleepycat licence [3] and is listed as Category X at [2].
> As a result this store implementation has always been hosted elsewhere
> and recently I began looking into moving it to Apache Extras. Having
> done so however I am instead left with the impression that, given how
> we already use it, it would actually be possible to move the code into
> the ASF repo.
>
> My reading of the (incredibly short) Sleepycat licence suggests the
> restriction it imposes that makes BDB a Category X dependency is
> associated with the restrictions on the inclusion of BDB itself in a
> distribution (something that ASF policy would always prohibit us from
> doing) that also forces distribution of code for both BDB as well as
> the product using it, and that merely using the BDB classes/interfaces
> in our store code doesn't place licence restriction on that code
> (which is currently licenced as Apache Licence v2.0).
>
> Based on this and reading of all the linked pages, it seems to me that
> the following should be possible:
> - Our BDBStore code lives in the ASF repo as the glue code for an
> optional component that is not compiled by the build process by
> default, and is not referred to by the configuration the project ships
> (which would continue to use the Memory or Derby based implementations
> as we do presently).
> - Targets are added to our Ant based build to allow downloading the
> BDB jar (with warning that it is Sleepycat licenced) and building the
> BDBStore module.
> - Documentation is added to describe how users would update their
> configuration to use the optional component, and where to download the
> necessary BDB dependency it requires (again with warning it is
> Sleepycat licenced).
>
> IANAL though, so is my reasoning sound? During my searching I also
> came across instances of other Apache projects which currently are or
> have previously been doing roughly the same thing (using Maven builds)
> with BDB JE as I describe above, which hopefully suggests it is, but
> can somebody humour me?
>
> Thanks,
> Robbie
>
> [1] http://www.apache.org/legal/resolved.html#optional
> [2] http://www.apache.org/legal/3party.html#options
> [3] http://www.oracle.com/technetwork/database/berkeleydb/downloads/jeoslicense-086837.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message