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

["Rob Vesse (Jira)" <ji...@apache.org>]

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

Rob Vesse commented on LEGAL-487:
---------------------------------

I will let someone from the legal committee weigh in on 1/2 but I can give you some guidance on 3 based on discussions and issues of this kind I've seen in the past

Yes an optional feature that requires a dependency with a more restrictive license *must* be an explicit opt-in optional feature.  As far as the definition of optional goes generally the expectation is that said feature must be truly optional i.e. you must be able to function without it and it can't be something that the majority of users are going to want/need.  So you can't call something optional just to get around licensing policy and then have the majority of your user base enable by default because your product is not usable without it.

As for build time/runtime opt-in I think either is fine provided you aren't shipping the LGPL dependency itself as part of your distributions.  Using an optional dependency if available in the runtime environment is accepted standard practise and doesn't conflict with Apache policy AFAIK.  For the runtime route you might still want to put it behind some sort of opt-in feature flag if you really want to cover yourselves.

Of course legal committee members may come along and advise otherwise so you'll still need to wait for them to get official guidance

> 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
(v8.3.4#803005)

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