Friday, June 13, 2008

KDE, plugins, GPL and closed source applications

Here i was today, thinking about this stuff (yeah you can say i'm weird).

In KDE all of our core libs are LGPL so if someone owns a Qt commercial license he can write closed source applications using kdelibs.

In KDE we also have this nice technology called KParts that let's you load plugins for lots of things on runtime. One of the KParts possibilities is to load a KPart for a specific mimetype.

Let's say the above closed source application uses KParts to preview things, and the user of that closed source application decides to preview a PDF.

In that moment, the KPart system will lookup and load the OkularPart that is able of viewing PDFs.

And there is where my mind broke, OkularPart is GPL and is being used by a closed source application.

"NO! VIOLATION!" Does my mind shout, but how can the closed source developer prevent it? All he did is use a LGPL library, so, maybe this is not a violation? And if it is, what are we doing in the KDE project to help the closed source developer be a good citizen? Maybe we should tell the kpart system what kind of Parts are acceptable?

Can someone highlight me?

8 comments:

Benjamin said...

I can give you some more examples where this has caused issues or is talked about:
1) GStreamer has had the same problem in reverse: There's lots of GPL applications that might link against Fluendo's (closed) GStreamer plugins. The idea to solve this has been by using a license exception that allows closed plugins.
2) Samba is GPL, so closed source apps that use any VFS that implements smb:// are having this issue. And KIO, gnome-vfs and gvfs all do this.

However, keep in mind that linking GPL to closed source is not a problem. The problem only comes when you distribute GPL and closed source software. And that pretty much never happens, as distros only ship the free stuff and the ISVs don't ship the GPL plugins.

Unknown said...

I'm pretty sure it's OK for a closed source application to use a Free Software plugin.

It's not linking statically with okularpart, but loading it dynamically.

Only if they decided to extend okularpart and create their own secretpdfpart without making the source available would there be a violation.

By simply loading okular part they are not committing to any licence because okularpart could be replaced with any other kpart capable of displaying a pdf.

Jason Stubbs said...

IANAL, but...

As you've mentioned, the closed source application is obeying the rules for qt and kdelibs. The okular kpart being GPL only means that and components that the okular kpart requires or any components that require it must be licensed under something GPL-compatible to be distributable. So, unless the closed source application specifically requires the okular kpart, no rules are broken.

At least this is my understanding... but IANAL.

Andrius said...

GPL requires complying with it even if you only do dynamical linking. I think that only launching Free Software applications (for example using system()) from proprietary app is allowed.

Diederik van der Boor said...

The GPL states that your product is not derived if there is no direct dependency. For example, if a part is pluggable and can be replaced at runtime by any other part. So to me, it seams using Okular is OK.

If that rule wasn't there, every app had to be GPL too if it invoked bash via execve() :-p

IMHO we should make things easy to understand for commercial development. A rule you "you can use KDElibs because it's all LGPL" makes that possible. So if there is a conflict within KDE's own libs, it should be resolved by making sure it's LGPL too.

Paul said...

It is perfectly fine for a closed source application to load a GPL module.

It is perfectly fine for a closed source application to link (even statically) to a GPL library.

It is perfectly fine for a company to distribute closed source code that will load a GPL module (provided the code is not derived from the GPL code).

It is perfectly fine for a company to distribute GPL code that will load propietary code.

What is not allowed, is to distribute the GPL code together with propietary code linked either statically or dynamically. The minute you try to distribute the bundle, you violate the license.

There are many other restrictions in the GPL license, but all of them apply to distribution of code. There are no restrictions for the guy using the software.

Anonymous said...

But what about commercial Linux distributions? They do sell a bundle of GPL/Commercial code.

Albert Astals Cid said...

@benjamin: kioslaves run in a different process, so libsmbclient won't be in the same process when using smb:// kioslave