It is not clearly documented that this template cannot be used in proprietary applications

[BrannanH]

I am relatively new to python so apologies if I have misunderstood anything here. The following captures my understanding of this problem.

This project has a dependency on the requests library, which has a transitive dependency on the chardet library. chardet is licensed under LGPL. This has been flagged with a notice in other azure python packages, for example in azure-storage-python.

Would it be possible to add a similar notice to this project?

It would be preferable to those who would like to use Azure for authentication etc. that this template is updated such that all transitive dependencies use permissive licenses. I appreciate that is not a small piece of work. This is however a problem many will have to solve if they want to use Azure for authentication in a closed-source application they want to distribute.

[rayluo]

Thanks for bringing this topic to our attention. IANAL, an online search yields some opinions (such as this one and that one) suggesting that "your library (app?) can be available under whatever terms you like, as long as the LGPL library is still available under the same terms determined by its original author".

In Python ecosystem, there are tons of apps and libraries depend on requests (thus its chardet transitive dependency). So, it is hard to avoid it. You are probably better off to figure out whether your app can use a transitive LGPL dependency. If the answer is a yes, then you don't need to worry about whether a 3rd-party library has that explicit notice. If the answer is a no, then you will need to do your homework for all your direct and transitive dependencies anyway. Feel free to let us know your research outcome.

[BrannanH]

My interpretation of the LGPL license is that if an application were to use chardet even transitively, the distributor would need to make it possible for any consumer of the application to replace the version of chardet used by the application with any other version. Given the scenario we're discussing is where the application's source code is proprietary, the distributor would not want to release the source code to facilitate rebuilding while including a different version of chardet. If not done at build time this LGPL requirement would mean the option to use a different version of chardet would have to be given to the consumer as runtime configuration.

Supposing the build of the application results in a docker container, my interpretation is that you would need to, for example, expose a variable which defines the path to go and look for chardet files. If that variable is set, go to that location when executing chardet code and execute what is there, otherwise use the chardet files included in the image by default.

This would raise a series of security concerns around introducing a vector for a bad actor to exploit allowing them to inject malicious code at runtime. To me, this conclusion means the answer to "figure out whether your app can use a transitive LGPL dependency" is no. This is why we apply this level of scrutiny to all of our direct and transitive dependencies.

I expect there are a huge number of other companies who have the simultaneous need of license adherence and protection from bad actors who would similarly be excluded from using this template application in its current form. Given this template is here to facilitate faster and easier adoption of the azure identity api, I believe that removing this dependency on requests would therefore open the door to these companies.

I'd also add that doing this 'homework' for each direct and transitive dependency is quite time consuming. If the way forward the maintainers of this library choose to go is to retain the requests dependency, and the associated chardet licensing concern, I believe it would be useful to other potential adopters to have a notice like this one on azure-storage-python so they can very quickly and easily discount it from their options.

[rayluo]

Thanks for your time on providing those details.

1. Looks like your interpretation is largely correct in the part that "application that statically linked against a LGPL library would need to allow users to modify that library" (based on this GNU GPL FAQ). But that does not necessarily mean a proprietary application cannot use LGPL libraries (see also this FAQ and this case study for Java), so, the title of the current github issue "... cannot be used in proprietary applications" seems debatable. It is on proprietary app owner to decide whether LGPL (and its requirements) is suitable for their project.
2. The maintainer of each mid-tier template or library could list the licenses of their direct dependencies, but it is not scalable to also list the licenses of their transitive dependencies, which shall be considered the implementation details of their upstream dependencies anyway.
3. What you (and other proprietary app owners) really want, is a convenient way to help you do your homework to answer, "what licenses are used by my transitive dependences". There shall be these kinds of tools available out there. In Python, there is a pip-licenses.
4. Interestingly, I ran that tool in my requests-included environment, and it does not show chardet at all. Not sure whether they removed that dependency at some point, but again, that is implementation detail to us the downstream components.