I question the distribution of LGPL code with Requests

I'm not sure if this is the right place to discuss licensing issues. If not please point me to the right place.

Requests itself is under an Apache license, while bundled chardet library is under LGPL. I believe those two are incompatible and people that include requests are expecting it to be 100% Apache, while they get a portion of it under LGPL.
Any thoughts on how this could be resolved?


Yeah, this makes me somewhat uncomfortable. My _suspicion_ is that the LGPL doesn't allow what we're doing here, but IANAL. Fundamentally the decision here is with @kennethreitz. If it were me, though, I'd chat with Van Lindberg and see what he says, and then potentially take action to make chardet an optional dependency (like PyOpenSSL), rather than a bundled one.


I'm not a lawyer either. I have raised this before and it has been cleared by certain people though. That said, we do include https://github.com/kennethreitz/requests/blob/master/NOTICE. It's clear to some that requests' source code is Apache, while it includes other non-Apache packages.


LGPL allows re-distribution, which is what we are doing here. The license for the CA Bundle falls under similar territory. The NOTICES file is important (just as important as LICENSE), as it is in any project that has one. 


> LGPL allows re-distribution, which is what we are doing here. 

Right. It's important to understand that things that requests vendors are not modified when vendored. I work on chardet upstream to ensure it's suitable for our vendoring. Likewise @Lukasa and I work on urllib3.

We don't vendor & modify, we simply vendor to redistribute.


And I'm very grateful that it does allow re-distribution. I was previously unaware of this, and was going to attempt to commission a copyleft chardet-like library be written, because this functionality is so core and important. 


As somebody installing the module only via `pip` I was surprised to learn that it bundles some other code under different license than Apache.

A solution for me is to have a private fork of `requests` with `chardet` removed but I found it misleading as https://pypi.python.org/pypi/requests described the license as "Apache". I only found the `NOTICE` file after this discussion.


>  I was surprised to learn that it bundles some other code under different license than Apache.

I'm sorry you were surprised. Most people do thorough research beyond what the license field says on PyPI. NOTICE files are common practice for projects that package other OSS code into their project.

You should also consult a lawyer before haphazardly breaking your dependencies. Projects like OpenStack (that have large corporate adoption) rely on requests without worrying about this.


I've re-titled this since the licenses are _not_ incompatible.


P.S. if you're using a non-ancient version of pip, then you already have Requests (including these vendored packages) installed on your system. 


I don't think the issue is with LGPL but with APL.
https://www.apache.org/legal/resolved.html


The problem we're hitting with chardet is that we bundle our code and dependencies (incl requests) using PyInstaller as a self-contained executable, a.k.a. static linking, and the user cannot "use their own copy of" chardet. This is a problem with LGPL. 

Commenting although this is closed.  APL cannot pull in LGPL.  Is there any movement to remove the LGPL dependency from chardet (or have chardet update their license?)

Hey @pauljamescleary, we haven't had chardet bundled with Requests for a little over a year now. I don't believe there's any intent to change license types on chardet, but that would be something to follow up with their team. We don't have any immediate plans to make further changes in Requests regarding this.

As stated above, none of the maintainers are lawyers, but our usages have been approved by legal teams well-versed in software licensing. I *believe* the specific clause that is worth noting is [LGPL2.1 § 5](https://opensource.org/licenses/LGPL-2.1):

> A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

This topic has been discussed over and over again with the exact same outcome. The topic is resolved.