Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I question the distribution of LGPL code with Requests #3389

Closed
gozdal opened this issue Jul 7, 2016 · 14 comments
Closed

I question the distribution of LGPL code with Requests #3389

gozdal opened this issue Jul 7, 2016 · 14 comments

Comments

@gozdal
Copy link

gozdal commented Jul 7, 2016

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?

@Lukasa
Copy link
Member

Lukasa commented Jul 7, 2016

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.

@sigmavirus24
Copy link
Contributor

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.

@kennethreitz
Copy link
Contributor

kennethreitz commented Jul 7, 2016

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.

@sigmavirus24
Copy link
Contributor

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.

@kennethreitz
Copy link
Contributor

kennethreitz commented Jul 7, 2016

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.

@gozdal
Copy link
Author

gozdal commented Jul 7, 2016

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.

@sigmavirus24
Copy link
Contributor

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.

@sigmavirus24 sigmavirus24 changed the title Incompatible licenses for chardet and requests Unexpected distribution of LGPL code with requests Jul 7, 2016
@sigmavirus24
Copy link
Contributor

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

@kennethreitz
Copy link
Contributor

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.

@kennethreitz kennethreitz changed the title Unexpected distribution of LGPL code with requests I question the distribution of LGPL code with Requests Jul 7, 2016
@beders
Copy link

beders commented Oct 17, 2016

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

@ivanstoyanov
Copy link

ivanstoyanov commented Feb 12, 2017

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.

@pauljamescleary
Copy link

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?)

@nateprewitt
Copy link
Member

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:

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.

@psf psf locked as resolved and limited conversation to collaborators Jun 12, 2018
@sigmavirus24
Copy link
Contributor

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants