[jira] [Closed] (LEGAL-99) Question around use of Berkeley DB Java Edition for an optional component

["Robbie Gemmell (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LEGAL-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robbie Gemmell closed LEGAL-99.
-------------------------------

    Resolution: Fixed

Closing out, answered by Greg Stein after posting the message over on the legal-discuss mailing list.

> Question around use of Berkeley DB Java Edition for an optional component
> -------------------------------------------------------------------------
>
>                 Key: LEGAL-99
>                 URL: https://issues.apache.org/jira/browse/LEGAL-99
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Robbie Gemmell
>
> 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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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