[LEGAL-487] How to resolve a project's non-compliance with ASF third party license policy?

• Type: Question
• Status: Resolved
• Priority: Major
• Resolution: Information Provided
• Component/s: Policy Question
• Assignee: Unassigned
• Reporter: Adar Dembo
• Created: 01/Nov/19 07:15
• Updated: 08/Nov/19 01:26
• Resolved: 08/Nov/19 01:26

Description

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

1. How urgently must this be addressed? Is it acceptable to address it in time for our next release?
2. 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?
3. 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)?

Issue Links

• relates to: KUDU-2990 Kudu can't distribute libnuma (dependency of memkind)