www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marvin Humphrey (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LEGAL-86) Artistic License / CPAN dependencies
Date Tue, 09 Nov 2010 23:51:08 GMT

    [ https://issues.apache.org/jira/browse/LEGAL-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12930366#action_12930366

Marvin Humphrey commented on LEGAL-86:

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

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:


    (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:


    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:


    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.

> Artistic License / CPAN dependencies
> ------------------------------------
>                 Key: LEGAL-86
>                 URL: https://issues.apache.org/jira/browse/LEGAL-86
>             Project: Legal Discuss
>          Issue Type: Question
>            Reporter: Marvin Humphrey
> 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?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message