ansi2html's license now superceedes MPL

[brianbruggeman]

I think this is just an awareness thing. But based on the licensing pytest-html is not longer actually being distributed via MPL and is officially GPL3 due to the addition of ansi2html. Since this is a tool, I'm not sure it really matters, but it would be good to have that identified somewhere.

[RonnyPfannschmidt]

indeed, unless ansi2html is made optional i believe its impossible to avoid infection
furthermore i believe its even necessary to completely rip it out of pytest-html

@davehunt this looks like a massive licensing bummer

@brianbruggeman thanks for bringing this unfortunate issue to attention

[JensTimmerman]

No it does not, since ansi2html is just a dependency and not of the copyrighted code is actually distributed in the pytest-html project the python-html project can still be distributed under MPL.

People using python-html also do not need to agree to the GPL3, GPL only covers distributing the code or binaries, so only people who want to distribute pytest-html without having to agree to the GPL would be somewhat affected, but since the MPL still gives them the rights to patch out the ansi2html dependency they don't really lose any flexibility.

[RonnyPfannschmidt]

@JensTimmerman while IANAL, i noticed it tends to be helpful, in particular for companies that use this to be free of any uncertainties and pitfalls

while a typical python installation by the common tooling has less trouble,
importation is linking and its easy to end up creating a setup that as a whole is suddenly in violation of the GPL

i believe its unfair to down-streams to expose them to that RISK too easy

furthermore i think the stance of "if you got licensing trouble, patch stuff out" is deeply problematic for downstreams,
because it sets them up for mistakes so easily and creates massive friction for upgrade paths, fork maintaining and lots of other unpleasant details

[davehunt]

@brianbruggeman thank you for bringing this to our attention. Would it be acceptable to make the ANSI feature optional? The user would need to install it via something like pip install pytest-html[ansi]. We could then mention in the README, LICENSE, and setup.py file that this feature is licensed by GPL via the ansi2html project.

[RonnyPfannschmidt]

@davehunt the ansi2html is already working on re-licensing to LGPL2+ and it seems it will be completed before the weekend

[brianbruggeman]

@davehunt Yes. I think making it optional should allow for picking a license and updating the README/LICENSE/setup.py will help at least awareness and choice. Thanks for being proactive on this.

@JensTimmerman
As far as I am aware (based on consulting with FSF), LGPL does not actually remove the GPL downstream requirement from Python packages and that's explicitly because Python is an interpreted library and not a binary. Note that the concept of LGPL was originally designed for compiled code which produces a binary, and using the library mechanism, there's a much cleaner cut between proprietary code and non-proprietary code. However, the FSF consultant that we talked to also indicated that it's FSF's belief that if code shared the same memory space, then the *GPL licenses extend to all of that code. So when we talk about having proprietary code to keep the lights on, it becomes a huge problem for our lawyers to accept that we use any form of *GPL code, unless it's a tool and doesn't actually get distributed within a package. I hope that clarifies my position.

[JensTimmerman]

@brianbruggeman I'm sorry for my short sighted answer before, I was thinking about how we distribute python software. We generate rpms and push them to our repository. And push it to pypi and letting people run pip install xx or easy_install xxx or even clone it from github and run python setup.py install

All of these options mean that the dependencies do not get distributed in the rpm or .egg files or git repo, but are downloaded by setuptools or yum at the client side, so we do not distribute GPL'ed code.

Of course I forgot that none of these options just work on the Windows side and that you probably are generating installers which include all dependencies, (or you could be mailing a cd/dvd around which works offline) in that case, yes, you do have an issue.
You would need your installer to do the download instead of distributing the dependency inside the installer, I'm not sure how python's windows installers work at the moment so I can't help there)
And in case you're distributing this inside an embeded system without internet access there hardly is any way around it.

And as you put it, (And as I see it) relicensing of ansi2html to LGPLv2+ would not fix any of these issues?

[brianbruggeman]

@JensTimmerman
In a nutshell, yes. Your example was windows, and mine is actually embedded software where we distribute a full environment with a piece of hardware. And in either case, I think LGPLv2 wouldn't really change anything.

We also asked our FSF consultant about cloud services, which has no true distribution. And the response was similar, though the thought was it's more murky. A product (like an embedded device) is more true to the letter of the law, but a service speaks more to the spirit of the law.

Since the courts really haven't been exercised, this is all just speculation. But as written, most of the lawyers at the companies I've worked at treat *GPL like the plague.

[davehunt]

@brianbruggeman would you mind looking over #97 before I land it and push a new release? I decided not to even have the package as an optional dependency. If it's installed, then it will be used, otherwise it will not.

[davehunt]

This was resolved by #97