MySQLClient and it's GPL license

I was wondering whether the Django docs should be updated so as not to recommend the use of MySQLClient or at least be updated to contain a warning that the library should only be used when creating GPL projects.

Despite being widely used, and having a few closed tickets on the subject, that library is still using a GPL2 license with strong copyleft.

The MySQL Connector/Python, whilst being GPL2 based, does include the additional exception to allow it to be used in non-GPL projects - License — MySQL Connector/Python X DevAPI Reference 8.0.31 documentation

It does look like the maintainers tried to add clauses to bring it more inline LGPLs and the Oracle version to allow for the copyleft to only trigger based on modifications of the code itself but it falls short of actually stating that from what I can see.

Do we have any copyright lawyers in on the forum who can better clarify it as it’s a library that tends to be flagged up by OSS license checks and by recommending it more people are probably using it in projects where they really shouldn’t be.

I am not a lawyer.

But what makes you think that the GPL License would have an effect on any Django code you are writing?

Most people would not be including or distributing this library with their project. (I don’t think I’ve ever distributed it with anything I’ve ever done. I always rely upon the distro to provide it.)

So the issue is the “work based on the Program” reference which is used. “Work based on the Program” includes anything that uses the code directly. If the code executes separately, E.G calling it via an API/sockets then it’s deemed not part of the same program and is fine.

By using “import” you’ve including the code in the programs execution and so it becomes part of the program as it becomes a “derivative of work” under copyright law and thus becomes part of the same program. Thus even though you install the package separately by using the code it your own becomes GPL.

It’s the big issue with GPL, GPL2 and GPL3. LGPL tends to exclude that and some GPL released packages will include exceptions but in the case of mysqlclient it doesn’t appear to.

A handy tool for running a project through licensing checks is to use https://fossa.com/. It’s far from perfect and can bring up false-positives but generally it does highlight packages of concern which can then have their license files actually checked. I was playing about with one using mysqlclient when I noticed it was GPL so I had a started to look further into what was actually in their license file

I am not a lawyer. What I’ve written here is not to be construed as legal advice. Nor am I presenting this information as legal opinion as provided by a lawyer.

I strongly suggest anyone consult a lawyer if they’re really concerned about it.

From the license:

… a “work based on the Program” means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another
language. …

[emphasis added]

also from the license:

You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program,

[emphasis added]

Your interpretation of :

does not appear anywhere within the license, nor can I find any reputable source expressing such an opinion. In fact, it directly contradicted by the GNU GPL FAQ and paragraph 0 as quoted below.

Additionally, from the license:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

Also:

You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.

Again, you are not performing any of the activities here regarding that library, nor is the functionality of your program dependent upon that library.

If a different library were provided that supports the same API, your program would not need to change. (“independent and separate works”)

Finally, from paragraph 0:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

And again, this makes it explicitly clear that only these three categories cause the license to apply. Since I’m not performing any of these activities, I’m not worried about it.

You’ve actually quoted the parts that raises my concern

“You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program

This states that it forms a “work based on the Program” thus it becomes the program.

Then the last part you quote states:

“The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program”.

Well since it’s already established that forms a work based on the Program than means that other activities do apply.

This part of the GPL FAQ also states you can’t use GPL with proprietary, non-GPL code, other than at “arms length” Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation

Again this goes back to the issue of the definition of the “single program” which is the “work based on the program”.

That’s only a partial quote. You keep ignoring the part that says you may modify your copy … thus forming a work. There’s no modification being performed.

Nope. You’ve not shown anything like this at all.

You are not incorporating the GPL-covered code in your program. Please read that entire paragraph and you will see that your interpretation is making assumptions and drawing conclusions that aren’t present either in the license or in this FAQ.

From further down in the same paragraph:

The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs.

No such combination is occurring. You are not combining these programs nor are you distributing them together.

You are also continuing to ignore the paragraph 0 clause that identifies under what conditions this license applies.

You really do need to consult with a lawyer who is familiar with copyright law in general and the GPL in particular.

My interpretation of other parts just suggestion that sections around modification isn’t relevant due to calling the Django calling the functions/classes within the project and that constituting a derivative of work.

I am going to get it checked by a IP lawyer as I need it for a project but in the past all the software lawyers I’ve spoken with directly or indirectly through clients have always recommended avoiding anything with GPL licenses due to copyleft unless their project was itself for release under GPL.

Once I hear back from them I’ll post an update, I was just wondering if anyone had come across it before specifically for that library.

Interesting topic :slight_smile: First off I am not a lawyer (then again I am not based in the US so that statement might not be needed at all) and secondly, and more importantly, I am not speaking as a member of the technical board – I usually don’t unless I make it explicitly clear but on this topic it is better to be explicit.

As far as I understand the GPL it is basically toothless when accessed over the network. So while the usage of a GPL library might make the derivative work a GPL product you can still provide it as a service over the network without getting in conflict with the GPL (after all this is what the AGPL is there to fix). Given that the main purpose of Django is accessibility over the network, I don’t see much gain in extra documentation. Adding documentation to that regard also feels like going down a slippery slope because we’d like to provide some advice without taking on any legal responsibility.

In the end it is up to the end user to ensure that the final combination of libraries is in line with their intended license.

Cheers,
Florian

Unfortunately, that was the common and accepted principle among most corporate lawyers 25 - 30 years ago. It took a long time for (a) the GPL to be tested in court and (b) for corporate law to start to understand it, the implications, and its effects on software development within corporations.

I’d say there are probably still more than a few IP lawyers who aren’t familiar with the legal implications of Open Source licenses - those who don’t understand software to the degree necessary to really understand development. I’ve worked with more than a few over the years.

1 Like

mysqlclient is not accessed over the network, it’s the library inside your Python process that talks to MySQL (over the network).

Personally, I’m not concerned with using mysqlclient in Django projects, or recommending other clients to do so. I think it has a GPL license because it uses the GPL C library provided by Oracle, perhaps even borrowing some code.

That said, I have written up how to patch in pymysql, which has an MIT license. I believe the maintainers are reticent to relicense mysqlclient to non-GPL because they’ve developed pymysql as a C-free MIT alternative.

It would be good to see Django officially support pymysql. We could maybe add a second MySQL backend that uses it, rather than relying on the pymysql’s install_as_MySQLdb().

1 Like

Yes, but using a GPL library in your project makes the derivative work GPL which would mean that you have to opensource your Django project if it weren’t for the loophole. I assume this is also why checkers usually flag GPL stuff.

Only if you “distribute” it. Running your code on your server creates no such requirement.

Hi @KenWhitesell, yes this is what I ment by “if it weren’t for the loophole”. I call it a loophole because the GPL people clearly didn’t mean it that way and tried to fix it with the AGPL.

Sorry, I was actually referring to my earlier comment regarding paragraph 0 of the GPL v2 license where it clearly states:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, …

If you are not doing any one of those three specific activities (“copying”, “distribution”, “modification”) of the licensed code, then the restrictions in the license do not apply.

To contend otherwise is to imply that if I write a program that runs a bash script as part of its processing, I would need to release my project under the GPL license.

Unless someone can provide either case law precedent or a legal opinion stating otherwise, I do not see where any such requirement would apply.

I’ve found more articles on the subject from legal folk or referencing advise from legal cases whilst waiting to hear back from the legal team so I wanted to post an update as this does help clarify when cases could become more questionable.

The below is a summary from the articles/posts I will link to below.

  1. The key clause of concern to GPL is the “statically linked” reference.
  2. A non GPL application calling/using a GPL app where the GPL app runs separately (triggering a bash script, running as a subprocess, via TCP or socket connection etc) means the call is not statically linked and therefore the program trigger it can’t be claimed as a “derived piece of work”. GPL does not apply
  3. In Python using “import” we are using “runtime linking” and that’s a more complicated situation. At this point it’s partly down to how the GPL code is used alongside country specific laws.
    3a. If you subclass a class from a library that is released under GPL where the class is NOT highly specialised, i.e. it’s generic, then the subclass DOES NOT have to retain the GPL license. GPL does not apply. This is because copyright claims over generic work are harder to win.
    3b. If you subclass a class from a library that is released under GPL where the class is highly specialised then the subclass may need to retain the GPL license. But even then it may not be classified as a derivative as it depends on “market demand”. This is the area where specific legal advice is key. GPL may need to apply - speak to legal
    3c. If you call classes/functions/code that are released under GPL without modifying/extending them in anyway and you have not distributed that application with your non-GPL application then GPL does not apply as per Paragraph 0 than Ken refers to. GPL does not apply

If you compile bundle GPL code with your code, potentially as an exe for example, then it’s a different matter.

References

  1. This is a good archived article on law.washington.edu regarding GPL and derivative works - Derivative Works < Law < Software Pluralism. It covers Object Oriented System, sub-classing and how “derivative works” may be claimed or not claimed giving examples of Java’s Object class.
  2. Australian Case - GPL did not apply - python and gpl
  3. French Case - GPL rejected due to France’s lack of copyright laws - French judge rules GPL license to be inapplicable in French copyright court – The HFT Guy

TLDR;
It appears that there’s a very specific case where GPL may be claimed and it’s very much around modifying, including extending via subclasses, GPL code where the GPL code is highly specialised.

So it’s all good :slight_smile:

Disclaimer

I am not a lawyer and what I’ve written above is not to be construed as legal advice. Nor am I presenting this information as legal opinion as provided by a lawyer. It is simply a summary

1 Like