You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Robbie Gemmell <ro...@gmail.com> on 2011/09/12 00:51:21 UTC
use of Berkeley DB Java Edition for an optional component
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
Re: use of Berkeley DB Java Edition for an optional component
Posted by Robbie Gemmell <ro...@gmail.com>.
Excellent, thanks Greg.
Robbie
On 12 September 2011 02:26, Greg Stein <gs...@gmail.com> wrote:
> 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 <ro...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: use of Berkeley DB Java Edition for an optional component
Posted by Greg Stein <gs...@gmail.com>.
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 <ro...@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