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

Licensing issue #105

Closed
merlijn-sebrechts opened this issue Jul 10, 2018 · 3 comments
Closed

Licensing issue #105

merlijn-sebrechts opened this issue Jul 10, 2018 · 3 comments

Comments

@merlijn-sebrechts
Copy link

merlijn-sebrechts commented Jul 10, 2018

Hi, I'm part of the community effort to create a new Ubuntu theme and we're really interested in this theme.

We'd like to include this theme in Ubuntu's "default Gnome" session to better support Qt applications and we're thinking of using this theme as the basis for Qt support for our own Communitheme but we're a bit hesitant about the license of the theme engine code, specifically that it's GPLv2 instead of LGPLv2.

Since this theme engine's code gets linked to every Qt application in order to theme it, the application and the theme become a "combined work", which means that the application needs to be GPLv2 compatible. We can't control which applications a user will run, so the theme engine will probably be linked to proprietary applications. This means that we will be infringing on your rights by using this theme. For this reason, most theme engines use LGPL instead of GPL:

I included a detailed explanation of the issues below. It's important to fully comply with the GPL, even inside of the FLOSS community. Sadly, this means that we cannot use this theme in Ubuntu while it is licensed GPL. Are you open to change the license to LGPLv2?

Detailed explanation

This explanation references the GPL FAQ section from the GNU website. I tried to include as much info as possible, let me know if you have further questions.

If you want your program to link against a library not covered by the system library exception, you need to provide permission to do that.

and further

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?

Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. See also: What does it mean to say a license is “compatible with the GPL”?

source

A theme engine is a library that themes an application so all applications it themes need to be GPL compatible.

What about the system library exception?

The system library exception only works in one way: a GPL application is allowed to link to a proprietary system library. However, this exception does not work the other way around.

Most system libraries either use the GNU Lesser GPL, or use the GNU GPL plus an exception permitting linking the library with anything. These libraries can be used in nonfree programs; but in the case of the Lesser GPL, it does have some requirements you must follow.
Some [system] libraries are released under the GNU GPL alone; you must use a GPL-compatible license to use those libraries. But these are normally the more specialized libraries, and you would not have had anything much like them on another platform, so you probably won't find yourself wanting to use these libraries for simple porting.

source

But the theme engine is dynamically linked.

The copyleft text of the GPL applies to all software linked to a GPL work, even dynamically linked software.

Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

source

Isn't a theme engine a separate application from the app it themes?

A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.

To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between [distributing] and “incorporating” the GPL-covered software is partly a matter of substance and partly form. 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. So the GPL has to cover the whole thing.

source: I'd like to incorporate GPL-covered software in my proprietary system.

The theme engine runs as part of the same process of the application and the app is linked to it just like it is linked to the GTK or Qt toolkit and just like it is linked to any system library. They do not communicate at an arms length, they are very much intertwined. As a result, the theme engine is "incorporated" into the application.

What about the themes themselves?

The Q&A clearly states that an interpreter and the interpreted application are two separate programs. So a nonfree program is allowed to use a CSS or SVG theme, as long as the license of the theme engine is compatible with the application.

If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?

When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone.

@MartinBriza
Copy link
Collaborator

Hello Merlijn,
I'm now on a train so I don't have too much time to investigate, however I'll summarize what's the core of the problem: Adwaita-Qt is not an original theme, it's based on Breeze by KDE, that is GPL, not LGPL, which makes it a derivative work and I cannot change the license unless Breeze changes it. I'll do some research when I come back home to make sure about this.
Personally, I'm definitely not opposed to changing the license but it depends on the other authors.

@KAMiKAZOW
Copy link

the theme engine is "incorporated" into the application.

Unless an application explicitly bundles this theme engine (kinda how Krita bundles home-grown themes in addition to system themes), I see this as a mere aggregation. See also https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#MereAggregation

To quote: "If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." – Qt applications are not not designed to run with this engine, therefore their authors have not designed to combine applications and theme.

According to Canonical shipping GPLed Linux kernel and CDDLed ZFS is also totally OK and nobody sued them over that.

@merlijn-sebrechts
Copy link
Author

merlijn-sebrechts commented Oct 7, 2019

Qt applications are not not designed to run with this engine, therefore their authors have not designed to combine applications and theme.

I can follow this logic, and this is indeed similar to the logic Canonical uses for ZFS:

And zfs.ko, as a self-contained file system module, is clearly not a derivative work of the Linux kernel but rather quite obviously a derivative work of OpenZFS and OpenSolaris. Equivalent exceptions have existed for many years, for various other stand alone, self-contained, non-GPL kernel modules.

https://ubuntu.com/blog/zfs-licensing-and-linux

According to this logic, an application linked to this theme engine at runtime is not a derivative work of the theme engine, even though the theme engine shares the address space with the application. I consider this issue closed.

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

No branches or pull requests

3 participants