Linux in a product

Some of it is "copylefted" - they made up a new word. Anyway, here's the GNU GPL:

Cheers! Rich

For everything you ever wanted to know about making money off somebody else's work. :-)

Cheers! Rich

What happens if, say, I use a GPL library in my s/w product? Do I have to make the source code of the entire app available, or only that library?

As I understand it, if you *link* with the GPL'ed library, and distribute it, then you have to release the source code to the whole app.

Often free libraries use the LGPL or BSD licences instead, for this reason, so they can still be used in proprietary programs.

They sell an *integration* of Linux and Applications as their product, not Linux as such - which they do not claim any ownership or special rights over other than GPL. Even the source for the packaging tools is licensed under GPL.

What I though I said - learn to read what I mean, not what I write, dammit ;-)

GPL - Yes, you have to make your app GPL as well. This is the famous 'viral' nature of GPL.

LGPL - No, your app don't have to be GPL. Only modifications to the library needs to be.

BSD - Do whatever you want.

The nature of GPL actually makes it impossible to write GPL plugins to non GPL programs like Photoshop since it implies that Adobe needs to make Photoshop GPL as well even if it's the end user who loads the plugin. For this situation the LGPL (Lesser/Library GPL) was created.

I think the OP meant that _Adobe_ would have a hard time writing GPL modules for Photoshop without someone claiming that they then had to release the source code for Photoshop. Is that not the case?

There are people out there who actively try to dissuade people from using the LGPL. I really believe that some of them would rather that software not be written at all (even if it's given away freely) than to not have access to the source code.

There a pretty silly (IMO) thread over on eHam.net about how the death of the author of some popular (freely distributed) software package has somehow harmed its users due to the guy's estate not being willing to hand over its source code (rumor has it they actually shredded his CDs and printouts!). Seems they're kinda looking a gift horse in the mouth there... Unlike the ideal world where the author would have GPL'd the software and "the community at large" would continue development, I think the real world runs more along the lines of (1) the author might have never written the program if it had to be GPL'd in the first place and (2) even if it had been, there's probably less than a 1% chance that anyone else would have continued its development.

The people I admire most are the ones who are pro-free software (and other forms of intellectual property) but not simultaneously anti-commercial software/IP.

---Joel Kolstad

Only if your app uses GPLd code. An embedded device can have GPLd applications on it. And, you can write a non-GPL program that exec()s a GPLd program. Now your program does NOT have to be GPL'd.

No, the BSD license does have conditions of it's own. Namely, you have to place a notice of some sort in the product documentation. "Public domain" mans do whatever you want (see

This is not correct. I can't write a GPL module for a non-GPL program and use that to force the original developer's code into GPL. Just like I can't sell your car to someone else without your permission.

It'd be perfectly fine to write a GPL'd plugin for a commercial application, and it would not force the other developer to relicense _their_ product. Don't be silly.

On the other hand, it would be strange to release a module as GPL...LGPL is more appropriate.

ttyl,

--buddy

Read the question I answered.

You can obviously write GPL plugins for non GPL programs physically. Nobody's there to physically stop you. But it makes the legality of using the plugin very complex. Lets analyse this a bit.

GPL states that any code which links to GPL'd code must be made GPL as well. You write a Photoshop plugin and GPL it. Therefore, the end user must agree to your license (GPL) in order to use your software unless you say otherwise. This means, to comply with your conditions to use your plugin, Photoshop must be GPL. It obviously is not so your plugin immediately invalidates its own license. But wait, GPL makes exceptions on code not meant for distribution. So you can use the combination - Photoshop + GPL plugin as long as they are not distributed together. But GPL also has strict definitions of what distribution means. And you have to make sure you adhere to those.

My point is, yes it can be done if you want, but why release code with such confusing and conflicting licensing when you really should be using LGPL?

No.

Ian

If the violator had widely distributed GPL code without a valid license, the choice might come down to a huge copyright infringement judgement, or a settlement built around opening the source to achieve licensing compliance.

If they refused to settle and the infringement judgement exceeded the value of infringer's other assets, it's possible the plantiff might be awarded ownership of whatever copyrights the infringer did have, if such a plantiff were a GPL-promoter they would probably take it and re-release the product in full compliance with the GPL. Unless the product has enough unique new value to justify removing and replacing the GPL code, it's unlikely that selling it to a third party would raise the necessary cash to settle the judgement.

Read GPL. By definitions in GPL Photoshop links to your code since it is the one 'loading' the plugin.

If Adobe wanted to, they could release plugins with a dual license: Use this with photoshop, or use the GPL. At that point, anyone else who wanted to load those plugins in their applications would have to make their applications GPL'd. So in that case, it would make sense.

There's a lot of dual licensing that goes on, especially when the GPL gets involved.

tyl,

--buddy

It can't be quite that simple.

Say I have a GPL application running on a machine with a proprietary OS, windowing system, and window manager. If I launch the GPL application by selecting it from a window manager menu and it is then loaded and executed, how is this fundamentally different from a plugin for a special purpose "image processing operating system" like photoshop?

There has to be a dividing line somewhere... published API's or something. But couldn't a plugin interface be published? It seems to get down to a semantic argument over what is operation system vs application, compared to what is application vs plugin...

Having to define this dividing line is one of the reasons many companies are leery of using GPLd software!

One easy to define dividing line would be whether or not the code of the GPLd software runs in the same process space as that of the caller -- this way it's OK for a proprietary Windows manager to invoke the GPLd code, and for something like Photoshop you could cleanly setup up something like a mail slot RPC interface between the two, although any form of 'direct call' interface wouldn't cut it.

Photoshop most likely uses a COM interface to its plug-ins... anyone know for sure? Depending on how the threading model of the COM component is set-up, though, the plug-in may run in or out of process which makes this all kinda murky...

Wrong, because your code links to Photoshop not the other way round.

Ian

Ian, have you read through the GPL license? A document is not 'executing code'. GPL only covers executable code. The definition of 'linking' loosely tranlated is calling a function in a library/file. Parsing a file is not covered. That's why it's OK to develop non-GPL scripts that runs on GPL'd intrepreters.

Also, GPL allows using non-GPL plugin/library/dll in GPL'd code, not the other way around. So your example should be reading a GPL'd document in Microsoft Word.

But as Joel Kolstad replied earlier, even this is already dealt with by the GPL license. It's allowed to use a GPL *code* (not just a document or script) with a non-GPL application as long as they both don't run in the same process space. For example it's OK to use a GPL database with your code as long as they communicate via pipes, TCP etc.

These are not my definitions but GPL's.

Again, my point is if you want to develop a dll/plugin for a commercial application you should be using LGPL.

How would you classify dynamic linking?

Or going the other way, what about registering a callback function to respond to events from the host application, window manager, or OS ?

Wrong again. This is exactly the same as Open Office reading a text file and there is no requirement to make your text file open source.

Ian