www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adar Dembo (Jira)" <j...@apache.org>
Subject [jira] [Resolved] (LEGAL-487) How to resolve a project's non-compliance with ASF third party license policy?
Date Fri, 08 Nov 2019 01:27:00 GMT

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

Adar Dembo resolved LEGAL-487.
    Resolution: Information Provided

OK, since Roman weighed in, I'll go ahead and close this. Thanks again for the feedback.

> How to resolve a project's non-compliance with ASF third party license policy?
> ------------------------------------------------------------------------------
>                 Key: LEGAL-487
>                 URL: https://issues.apache.org/jira/browse/LEGAL-487
>             Project: Legal Discuss
>          Issue Type: Question
>          Components: Policy Question
>            Reporter: Adar Dembo
>            Priority: Major
> In KUDU-2990, we identified that Apache Kudu is currently in non-compliance of the ASF
third party license policy because it distributes an LGPL library, both in source and binary
form. I wanted to get some clarification on a few issues related to that
>  # How urgently must this be addressed? Is it acceptable to address it in time for our
next release?
>  # The first Kudu release to violate the policy was 1.10.0. We're also about to publish
1.11.0; just waiting on an updated website to send the announcement e-mail. Both of these
releases violate the policy. Does anything need to be done to them?
>  # We're currently evaluating various options that all define the functionality needed
by the LGPL library as an "optional" feature in one form or another. Am I correct in thinking
that an optional feature must be opt-in rather than opt-out? And that it may not be in the
default distribution? Do ASF projects offer two distributions, one conformant and one non-conformant?
From browsing past LEGAL tickets it looks like the guidance has been to offer the optional
feature as something to be downloaded at and enabled at runtime, but that's quite complex
for a native project like Kudu. Moreover, our binary distribution is only intended for testing;
our "production" distribution is the source distribution. What's the guidance on how to handle
optional features in that context? A build-time flag that _must be set_ in order to include
the feature (and its non-conformant dependency)?

This message was sent by Atlassian Jira

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

View raw message