Closed BrannanH closed 6 months ago
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.
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.
Thanks for your time on providing those details.
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.
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 thechardet
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.