search

FedoraQt / adwaita-qt

A style to bend Qt applications to look like they belong into GNOME Shell
Other
488 stars 48 forks source link

Licensing issue #105

Closed merlijn-sebrechts closed 4 years ago

merlijn-sebrechts commented 6 years ago

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 commented 6 years ago

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 commented 4 years ago

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 commented 4 years ago

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.