Changing license

[chardet]

Changing license

[sigmavirus24]

@dan-blanchard I'm 98% certain that only the original author of the code can, regardless of how reachable the original author is. I'm very certain we can't change the license unless we totally rewrite it. I'm also curious why you don't like the LGPL.

[dan-blanchard]

@sigmavirus24 I must admit that I was pretty certain that was the case as well.

In general I prefer MIT/BSD licenses just because they're simpler, and I feel like people are more likely to contribute if there are fewer strings attached.

The only reason I am advocating for MPL in this particular case is that a straight literal port like chardet is usually considered a modification/derivative of the original code. Given the terms of the MPL, it seems to me like chardet should have been required to be released under MPL in the first place, and that the LGPL choice was a legal oversight on Mark's part.

Not that I think Mozilla would be extremely upset about the license being wrong for a port of a part of their code that I doubt they'll even keep around much longer—they somewhat recently imported ICU into their codebase—but you never know.

[sigmavirus24]

I'm fairly certain that the original Mozilla project was LGPL'd honestly. As the original authors/owner of the copyright in that case, they can change their license on that code to whatever (including the MPL). That said, while this code is derivative of that work, they're not the copyright owner and Mark is.

[erikrose]

According to section 3.1 of the MPL (https://www.mozilla.org/MPL/2.0/), software that once falls under the MPL must forever stay under the MPL. Whether this port of chardet is a "derivative work" for copyright purposes I do not know. https://julien.ponge.org/blog/mozilla-public-license-v2-a-good-middleground/ suggests that derivative works themselves needn't necessarily be MPL'd but unmodified code must. I don't know if that's accurate or if a line-for-line port of C++ to Python is considered unmodified.

This is a legal rat's nest for anybody but Mark, and I suspect it's not worth the trouble unless there's a concrete difficulty with the current license.

[dan-blanchard]

This is a legal rat's nest for anybody but Mark, and I suspect it's not worth the trouble unless there's a concrete difficulty with the current license.

Fair enough. I just thought I'd raise the issue.

[johnthagen]

FWIW, https://github.com/Ousret/charset_normalizer seems to be an alternative package that is MIT licensed.

[johnthagen]

@dan-blanchard I see you have been contributing to chardet recently. Any chance this issue could be revisited?

LGPL makes it challenging for including chardet (or any of the many packages that transitively depend on chardet such as requests) inside of a binary due to the restriction that users need to be able to have the ability to swap out the LGPL library for another of their choosing, something infeasible/very tricky for a binary distribution.

This affects users of Pyinstaller, Nuitka, PyOxdizer, etc. that want to package their Python code and dependencies into a stand-alone binary.

[dan-blanchard]

Unfortunately, because the code that chardet was originally based on was LGPL, we don't really have a way to relicense it. Believe me, if we could, I would. There was talk of chardet being added to the standard library, and that was deemed impossible because of being unable to change the license.

[BrettMoan]

@dan-blanchard any chance you could maybe talk to the maintainers of requests to get off of chardet given the inability to change the license?

I know its odd someone, to ask others to not use their code, but such a restriction of chardet prevents development of closed source using one of the most downloaded packages on the pypi. requests and even the python documentation on urllib.requests seem to be overlooking this problem that the LGPL introduces.

Those who work with license scanning software, to ensure their code doesn't contain copy-left linking will eventually see chardet and be confused given that their code doesn't knowingly contain that and will end up down a familiar rabbit hole for many, where they use requests which then leads to the install of chardet all because they followed the plethora of examples to use requests including the quote from urllib.request documentation itself suggesting it.

See also The Requests package is recommended for a higher-level HTTP client interface.
--- https://docs.python.org/3/library/urllib.request.html#module-urllib.request:

Given than that its license prevents it from being included in the standard library, it seems odd that the the standard library documentation is actually recommending a package that has it as a dependency.

[sigmavirus24]

Hi, requests maintainer here. We're not dropping the dependency any time soon. @dan-blanchard you can say we've talked now

[sigmavirus24]

Also, I'm aware of many enterprise companies using requests + chardet with license scanning software. LGPL is a gray area in Python and not nearly as infections as AGPL or the non-open-source licenses like SSPL.

[johnthagen]

I'm curious if there anything in particular about charset_normalizer that makes it unsuitable compared to chardet? It advertises itself as an MIT-licensed alternative. Could migration to that be a solution?

[sigmavirus24]

We (the maintainers) don't have the time to make such a migration with confidence or without the risk of introducing bugs. Regardless, alternative doesn't mean drop-in replacement that doesn't regress behaviour for Requests. Conversations like this tend to take up more of our time given how limited our time is to do work on Requests. This precludes us from exploring other options, making improvements, or doing anything except the bare minimum (researching/fixing security bugs, etc.)

[BrettMoan]

@sigmavirus24 for the maintainers of requests is it a "wont fix" or a "don't have time to fix"?

Curious if the maintainers are opposed to merge requests that attempt to replace chardet, I've seen every conversation regarding this "closed" with the conversation implying a "won't fix".

If its a "don't have time to fix" then people who are invested in this as an issue could attempt to resolve it.

[sigmavirus24]

It's both really