Details

    • Type: Question Question
    • Status: Closed
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      The Apache Lucy Incubator podling is working to pare down its list of
      dependencies, but there are two CPAN distributions which we would like to
      put off replacing for the time being (Parse::RecDescent and JSON::XS).
      These two distributions are both licensed, as is common for CPAN modules,
      under the "same terms as Perl itself". Perl's licensing is here:

      http://dev.perl.org/licenses/

      We do not wish to bundle these CPAN distributions with Lucy, but instead
      specify them as prerequisites. We assert that our usage of the modules in
      question falls under the terms of the Artistic License and not the GPL.

      Lucy interfaces with these modules in three places:

      • At build time (Parse::RecDescent).
      • Within Lucy itself at runtime (JSON::XS).
      • Within sample/cookbook code (Parse::RecDescent).

      We have two questions:

      • Is it acceptable for code released under the Apache License 2.0 to have
        a non-optional dependency on code which is licensed under the Artistic
        License?
      • Is it acceptable to classify these modules as "system dependencies",
        which the user is expected to install?

        Activity

        Hide
        Stefano Bagnara added a comment -

        I don't know the answers, but we talked about the same license in LEGAL-64.

        Show
        Stefano Bagnara added a comment - I don't know the answers, but we talked about the same license in LEGAL-64 .
        Hide
        Marvin Humphrey added a comment -

        Thanks, Stefano, I studied LEGAL-64. Had it been officially resolved and the
        Artistic License been categorized, it may not have been necessary to open this
        issue.

        I think we're in the clear for our usage. We aren't bundling the
        dependencies, so the distribution terms would only apply to derivative works
        of the libraries in question within our codebase. The Artistic License
        version 2.0 goes out of its way to say that basic usage is not enough to
        trigger its provisions:

        http://www.perlfoundation.org/artistic_license_2_0

        (9) Works (including, but not limited to, modules and scripts) that merely
        extend or make use of the Package, do not, by themselves, cause the Package to
        be a Modified Version. In addition, such works are not considered parts of the
        Package itself, and are not subject to the terms of this license.

        The relevant passage within version 1.0 is murkier:

        http://www.perlfoundation.org/artistic_license_1_0

        8. Aggregation of this Package with a commercial distribution is always
        permitted provided that the use of this Package is embedded; that is, when no
        overt attempt is made to make this Package's interfaces visible to the end
        user of the commercial distribution. Such use shall not be construed as a
        distribution of this Package.

        However, the Perl Foundation considers version 2.0 to be mostly a
        clarification of 1.0:

        http://www.perlfoundation.org/artistic_2_0_notes

        The terms of Artistic 2.0 are the same as Artistic 1.0, aside from the added
        patent clause and relicensing clause.

        Basically, all we need is to determine that the portions of Apache Lucy which
        interface with the two CPAN distributions in question are not considered
        "Modified Versions" of those distributions. (This is very different from the
        FSF's interpretation of the GPL – under the GPL, according to the FSF, those
        portions of Lucy would be considered derivative works.) Once we make that
        determination, then we can list those libraries as prerequisites which the
        user must install. Thanks to CPAN, that's not an unreasonable burden.

        Eventually we plan to do away with both dependencies, but that will take time
        and we'd prefer not to have that task block our first release.

        It seems to me that this is different from the use case covered in LEGAL-64.
        I think our usage is more typical; it's very common for CPAN distros to list
        other CPAN distros as prerequisites.

        Show
        Marvin Humphrey added a comment - Thanks, Stefano, I studied LEGAL-64 . Had it been officially resolved and the Artistic License been categorized, it may not have been necessary to open this issue. I think we're in the clear for our usage. We aren't bundling the dependencies, so the distribution terms would only apply to derivative works of the libraries in question within our codebase. The Artistic License version 2.0 goes out of its way to say that basic usage is not enough to trigger its provisions: http://www.perlfoundation.org/artistic_license_2_0 (9) Works (including, but not limited to, modules and scripts) that merely extend or make use of the Package, do not, by themselves, cause the Package to be a Modified Version. In addition, such works are not considered parts of the Package itself, and are not subject to the terms of this license. The relevant passage within version 1.0 is murkier: http://www.perlfoundation.org/artistic_license_1_0 8. Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package's interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package. However, the Perl Foundation considers version 2.0 to be mostly a clarification of 1.0: http://www.perlfoundation.org/artistic_2_0_notes The terms of Artistic 2.0 are the same as Artistic 1.0, aside from the added patent clause and relicensing clause. Basically, all we need is to determine that the portions of Apache Lucy which interface with the two CPAN distributions in question are not considered "Modified Versions" of those distributions. (This is very different from the FSF's interpretation of the GPL – under the GPL, according to the FSF, those portions of Lucy would be considered derivative works.) Once we make that determination, then we can list those libraries as prerequisites which the user must install. Thanks to CPAN, that's not an unreasonable burden. Eventually we plan to do away with both dependencies, but that will take time and we'd prefer not to have that task block our first release. It seems to me that this is different from the use case covered in LEGAL-64 . I think our usage is more typical; it's very common for CPAN distros to list other CPAN distros as prerequisites.
        Hide
        Chris A. Mattmann added a comment -

        Hi All – any resolution on this? Sam? Comments? This is seriously hindering our Lucy Incubator first release and a resolution would help us not have to go through any more effort to side-track these dependencies.

        Cheers,
        Chris

        Show
        Chris A. Mattmann added a comment - Hi All – any resolution on this? Sam? Comments? This is seriously hindering our Lucy Incubator first release and a resolution would help us not have to go through any more effort to side-track these dependencies. Cheers, Chris
        Hide
        Sam Ruby added a comment -

        No concerns about usage at build time. No concerns about usage in cookbook.

        Based on a quick peek at the web site, it is not clear to me that the usage at runtime is from code in Lucy written in Perl. If so, I have no concern about Perl code depending on code hosted in CPAN which is made available under the same license as Perl. If the dependency is other than from code written in Perl, can somebody clarify what the dependency is?

        Show
        Sam Ruby added a comment - No concerns about usage at build time. No concerns about usage in cookbook. Based on a quick peek at the web site, it is not clear to me that the usage at runtime is from code in Lucy written in Perl. If so, I have no concern about Perl code depending on code hosted in CPAN which is made available under the same license as Perl. If the dependency is other than from code written in Perl, can somebody clarify what the dependency is?
        Hide
        Marvin Humphrey added a comment -

        > No concerns about usage at build time. No concerns about usage in cookbook.

        That's great. That resolves questions about our usage of Parse::RecDescent,
        which is the more difficult of the two dependencies to replace.

        > If the dependency is other than from code written in Perl, can somebody
        > clarify what the dependency is?

        At this point, Lucy can only be used via its Perl bindings. Therefore, all
        userland code which depends on Lucy and by proxy on JSON::XS will be Perl
        code.

        Removing Lucy's runtime dependency on JSON::XS is a prerequisite for adding
        other language bindings, so before Lucy publishes public APIs for Python,
        Ruby, or even C, this issue will have been rendered moot.

        Internally, Lucy core code, which is written in C, reads and writes JSON via a
        generic interface defined in
        http://svn.apache.org/viewvc/incubator/lucy/trunk/core/Lucy/Util/Json.cfh?view=markup.
        The implementation behind that interface presently calls back into Perl; the
        actual code utilizing JSON::XS is in
        http://svn.apache.org/viewvc/incubator/lucy/trunk/perl/lib/Lucy.pm?view=markup,
        lines 530-600.

        Eliminating JSON::XS as a dependency will require either changing the
        implementation to use a different library or writing our own parser a la
        https://issues.apache.org/jira/browse/AVRO-58. That's our eventual plan,
        but the current code is very stable and we'd prefer not to mess with it just
        prior to our first release, since screwups will result in index corruption.

        Lucy uses JSON to write index metadata, such as schema files. No part of
        Lucy's runtime usage of JSON is exposed via a public API; the encoding of the
        index files is an implementation detail.

        Show
        Marvin Humphrey added a comment - > No concerns about usage at build time. No concerns about usage in cookbook. That's great. That resolves questions about our usage of Parse::RecDescent, which is the more difficult of the two dependencies to replace. > If the dependency is other than from code written in Perl, can somebody > clarify what the dependency is? At this point, Lucy can only be used via its Perl bindings. Therefore, all userland code which depends on Lucy and by proxy on JSON::XS will be Perl code. Removing Lucy's runtime dependency on JSON::XS is a prerequisite for adding other language bindings, so before Lucy publishes public APIs for Python, Ruby, or even C, this issue will have been rendered moot. Internally, Lucy core code, which is written in C, reads and writes JSON via a generic interface defined in http://svn.apache.org/viewvc/incubator/lucy/trunk/core/Lucy/Util/Json.cfh?view=markup . The implementation behind that interface presently calls back into Perl; the actual code utilizing JSON::XS is in http://svn.apache.org/viewvc/incubator/lucy/trunk/perl/lib/Lucy.pm?view=markup , lines 530-600. Eliminating JSON::XS as a dependency will require either changing the implementation to use a different library or writing our own parser a la https://issues.apache.org/jira/browse/AVRO-58 . That's our eventual plan, but the current code is very stable and we'd prefer not to mess with it just prior to our first release, since screwups will result in index corruption. Lucy uses JSON to write index metadata, such as schema files. No part of Lucy's runtime usage of JSON is exposed via a public API; the encoding of the index files is an implementation detail.
        Hide
        Sam Ruby added a comment -

        > At this point, Lucy can only be used via its Perl bindings. Therefore, all
        > userland code which depends on Lucy and by proxy on JSON::XS will be Perl
        > code.
        >
        > Removing Lucy's runtime dependency on JSON::XS is a prerequisite for adding
        > other language bindings, so before Lucy publishes public APIs for Python,
        > Ruby, or even C, this issue will have been rendered moot.

        I approve of this plan

        Show
        Sam Ruby added a comment - > At this point, Lucy can only be used via its Perl bindings. Therefore, all > userland code which depends on Lucy and by proxy on JSON::XS will be Perl > code. > > Removing Lucy's runtime dependency on JSON::XS is a prerequisite for adding > other language bindings, so before Lucy publishes public APIs for Python, > Ruby, or even C, this issue will have been rendered moot. I approve of this plan
        Hide
        Marvin Humphrey added a comment -

        With the resolution of LUCY-133 and LUCY-134, Lucy svn trunk no longer has any
        non-core Perl dependencies (thought the 0.2 maintenance branch still has
        them). The limited variance discussed in this issue has served its purpose
        and we have no further need to explore the issue of usage under the Artistic
        license 1.0.

        Show
        Marvin Humphrey added a comment - With the resolution of LUCY-133 and LUCY-134 , Lucy svn trunk no longer has any non-core Perl dependencies (thought the 0.2 maintenance branch still has them). The limited variance discussed in this issue has served its purpose and we have no further need to explore the issue of usage under the Artistic license 1.0.

          People

          • Assignee:
            Unassigned
            Reporter:
            Marvin Humphrey
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development