Providing user's license choice

We have discussed in a few places over the years how to handle user’s preferences on licenses in their installed environment. Though we often lacked the tooling and sophistication as an ecosystem to handle this. However I think this has changed recently and would like to present a proposal for discussion about how we might do this.

Now that we make heavy usage of SPDX, one way we might solve this is to create some _license_* packages (like _license_MIT or _license_GPL-2.0-or-later). These could live as split packages of a single _license feedstock.

When we go through and hot-fix the repodata to translate license to license_family entries, we could also add a run dependency to each package with the appropriate _license_* dependency. One thing to figure out here would be how we handle custom licenses. Maybe initially we just skip them, but would be good to have a plan for them (do they need to be add to _license_*? could we have _license_other?)

Packages that have particular features that would result in license changes, could split these out as variants and simply set the license metadata based on how this would affect the end package license. It would be up to package maintainers to make sensible choices of features for users and/or PRs from users within this framework.

Users then could add _license_*s they don’t want to Conda’s disallowed_packages. This way users won’t get packages with those licenses they don’t want. Also this could potentially benefit from other Conda solves that use more acceptable licenses.

Would be curious to hear others thoughts on this proposal 🙂

[swails]

Our license metadata is at best incomplete and at worst downright misleading. We likely have packages that are mislabeled and others that are marked as say BSD-3-Clause but have additional non-commercial clauses or the like attached to them.

The packages that I’ve spot-checked seem pretty accurate in their reported licenses (not many, admittedly, and at that focus primarily on popular, common projects). I suspect that the majority of downloads correspond to accurate metadata wrt licenses (if only because the majority of downloads target a correspondingly small number of packages that are well-known, widely used, and therefore more carefully vetted).

But more importantly, I think that even the heavily-legalesed corporate world puts a lot of emphasis on “reasonable good-faith efforts” to maintain compliance. It is almost always intentional license violations that persist after the violations are known that are penalized and very rarely an inadvertent violation that is fixed quickly after discovery. (Note that while IANAL, the company I worked for employed several and they emphasized that it was clear ethical lapses rather than honest mistakes that actually exposed the company to legal risk.)

---

tl;dr - There is still significant value for this effort to companies leveraging conda-forge packages

[jakirkham]

TBH It gives people with full time jobs more justification to maintain packages beyond those strictly necessary on conda forge.

I want to make sure this point doesn’t get lost in the (justifiable) skepticism of us pulling this off. The goal here is to make it easier for other participants to get involved in the ecosystem. This ability to constrain licensing seems to be one of the obstacles and it has come up in discussions with others before ( for example https://github.com/conda-forge/conda-forge.github.io/issues/209 ).

Agree adding a disclaimer is a good idea.