Recipe is reporting the wrong license

[bryan-hunt]

Solution to issue cannot be found in the documentation.

• [X] I checked the documentation.

Issue

The recipe is calling out jbig as a dependency. This builds libtiff for the native platform and will link to the jbig library - libtiff does not use dlopen to access the jbig library. However, JBIG is a GPL2 licensed library with no exceptions:

Public licence(sk): You can use JBIG-KIT free of charge under the conditions of the [GNU General Public Licence](http://www.fsf.org/licenses/licenses.html#GPL). [Linking](http://www.fsf.org/licenses/gpl-faq.html#LinkingWithGPL) JBIG-KIT statically or dynamically with other modules is making a combined work based on JBIG-KIT. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

Source: https://www.cl.cam.ac.uk/~mgk25/jbigkit/

Since the recipe is providing jbig in the host & run requirements per the above the GPL license supersedes the libtiff license.

In my research I could not locate a GPL exception for libtiff so it looks like the options are:

• Remove jbig
• Update the license in this recipe
• Update the recipe to provide multiple packages with and without jbig (and correspondingly with and without gpl)

Installed packages

libtiff

Environment info

Any

[jakirkham]

This has come up in prior discussions. Most notably issue ( https://github.com/conda-forge/conda-forge.github.io/issues/1065 ). Though there are others ( https://github.com/conda-forge/conda-forge.github.io/issues/209 ) ( https://github.com/conda-forge/conda-forge.github.io/issues/1608 ). Searching will likely bring up even more threads.

The gist is conda-forge is not really in a position to provide legal advice on how different packages' licenses interact and what obligations end users are under in how they are used. So conda-forge has decided to merely convey the information library authors provide us in the different packages as accurately as possible and ensure the end user gets all of this information. Though conda-forge can't promise that there are no inaccuracies. What end users do with that information is up to them.

Thus when users create an environment it would contain all packages requested (and their dependencies) with relevant metadata. AFAICT it looks like jbig contains its license info. So this would be part of this environment (as would be the case for any other packages). This SO answer proposes one way one might inspect license metadata of an environment (not saying this is the "right" or only way to do this).

There has been discussion about how to provide users better tools to inspect, constrain, or otherwise work with environment's license metadata (as noted in some of the threads linked above). More discussion along those lines would be welcome. Building different variants of packages that include and exclude different dependencies can also make sense (though ideally this would fit in a cohesive model that can be rolled out over all of conda-forge to be most useful).

[bryan-hunt]

I agree that is unreasonable to audit everything - but from a pragmatic approach each recipe is individually maintained and it is seems a reasonable approach to verify that the package's license is compatible with the licenses of the immediate dependencies. If every node in the tree does their due diligence no further problem exists.

For example this library was compliant for 4.2.0 but is not compliant for 4.3.0 so it would extremely unreasonable if I were to go to Pillow and say "hey guys guess what - you have to pin libtiff=4.2.0 in your recipe because you are now GPL because openjpeg is using libtiff and neither of them are propagating the correctly". But GPL was written a specific way and we just can't ignore that because it is inconvenient to us. I think one of the comments you linked here is roughly the same perspective: https://github.com/conda-forge/conda-forge.github.io/issues/1065#issuecomment-631056603

If every recipe maintainer checks that the immediate dependencies have compatible licenses before they sign off on the PR that adds the dependency then people can make informed decisions at that stage.

[hmaarrfk]

I don't want to restart the debate GPL/non-gpl debate.

We are "working on it" on pull request #75.

TLDR, software tools are not exactly built to be modular in the sense of GPL/non-gpl. Some software packages assume that the end user will simply recompile everything. Some software has to be entirely recompiled along with all downstream software.