Flask-Bootstrap uses dominate, a GPL3 licensed package

[brianbruggeman]

I really would rather avoid GPL licensed anything within my code dependency chain.

[mbr]

I agree, I usually avoid these as well. However, dominate is licensed under the LGPL, not the GPL. If you are aware of an alternative that is more liberally licensed, I'm all ears though =).

[brianbruggeman]

I'm no lawyer, but I have asked the question about LGPL in a python context of lawyers and of a few vocalists from the Open Source Initiative. Both LGPL and GPL were designed around the context of a binary. And unfortunately, neither license gives you freedom from the derivative works aspect -- and this is important because Python runs as an interpreted code file rather than a binary. Note that this is still very much a grey area and unexplored within the courts, so it's entirely possible that there's no problem.

I looked through the pieces of your code that uses dominate, and I definitely like the simplicity it offers.

I only have a few options at the moment:

• Duplicate pieces of the dominate API that's used within a new package (or set of classes)
• Consider using an xml package that offers a similar API
• Use a templating system like Jinja2

Any thoughts?

[mbr]

Well,

here's my take on it: GPL and LGPL are a pain in the ass. I like the idea behind it and I think I understand the intent - I even support it. If it wasn't for those murky legal issues, probably all of my Software would be LGPL licensed. Because of the huge mess that creates it's not though, but MIT licensed instead.

In my experience, you can run into three kinds of GPL-licensed software. There's the "accidental GPL" because the author didn't know any better or has spent very little time on the issue. Then there's the "intended" LGPL license, which would be my reading ("use the lib as much as you want, if you modify just the lib, share") and your reading, which shall henceforth be dubbed "legalese" LGPL. I'll not discuss actual GPL licensed libraries here, those are much harder to misunderstand ("all your stuff is GPL now") and happen usually because the author has no idea what the license means, is a staunch copyleft supporter or aims to make money from selling GPL exceptions.

It doesn't help that the LGPL is badly written from a Python-perspective ("binaries"). It is also very old and enforcement would probably differ from country to country. For this reason, until this is cleared up, I can only pick an interpretation and stick to it, hoping that someone with clout will clarify at some point. I'm excited for the most recent high profile cases (Ubuntu/ZFS and VMWare in Germany), I don't care for the outcome, I just want to basic clarification.

Further thoughts:

1. Have you checked your or your lawyers interpretation of LGPL regarding Python itself being GPL?
2. If you're using Flask-Bootstrap, there's a good chance you're using Flask-SQLAlchemy, which pulls in SQLAlchemy. You may be using Postgres and one of the major DB drivers for Postgres is psycopg2, which is also LGPL licensed. Have you checked all of your other dependencies?
3. I've been putting off writing a letter to FSF or SFC, asking for clarification. I would really appreciate some insights here, if you are up for it, I would be very grateful.
4. There's also the option of asking the author of the library if he or she really intended for these consequences - sometimes people just checked a "default" somewhere and won't mind changing the license.

All in all it's a very time consuming issue. Right now, I don't think I want to put a lot of effort in changes unless someone can convince me that there is a need due to 3. coming through. I would very much like 4. to happen though.

Regarding your points:

I only have a few options at the moment:

• Duplicate pieces of the dominate API that's used within a new package (or set of classes)

If you are going to reimplement it, please share it as MIT, so I can switch =).

• Consider using an xml package that offers a similar API

Gah. XML.

• Use a templating system like Jinja2

I think that's the most common solution here.

Developing applications under the GPL gives a lot less headaches, that's for sure.

[brianbruggeman]

Most of my open source projects end up being Apache 2.0, because it eliminates some ambiguity that lawyers end up having with MIT and BSD. From a pure business perspective, I am concerned primarily with time because humans are expensive and time to market is critical. So if I don't have to implement something, all the better. And that means when I invest in a library, I'm happy to give back changes to improve the library because I want to foster community growth and leverage their time. I know my perspective is not unique in this regard.

Based on consul, I should avoid all GPL type licenses for Python specific code due to the derivative works issue. Consequently, I won't invest my time in a *GPL licensed software unless I know I can use that software with violating a license... (see psycopg2, postgres and python below for exceptions).

Note that some within OSI believe that any use of a GPL licensed code (i.e. basically all linux boxes) constitutes creating a derivative work. If this interpretation were to stand, then we would likely see a huge problem within the industry (possibly economically catastrophic). So my guess is that we won't, though I could be wrong.

With regards to psycopg2, I can use the dual license option with a ZPL license and possibly BSD licensed (http://initd.org/psycopg/license/). When I use psycopg2, I use those licenses.

When we start to talk about different binaries (i.e. a postgres database vs a python program I wrote running in its own process), then we get into a more succinct delineation between code as an executable vs a shared library binary. LGPL and GPL are fine because they're completely separate processes and my work is not a direct derivative.

With regards to Python, it is licensed under a PSF license (https://www.python.org/download/releases/2.7/license/), which is permissive and explicitly allows for the use of developing (and distributing) proprietary code on top of Python libraries.

I did approach the author of dominate; I'm not under the impression that the license is up for a change. Ideally, we'd see a permissive dual license.

I need to investigate options on my side before I commit to something that relates to Flask-Bootstrap. But you can be assured that if I do go ahead and make something, it won't be GPL based.