PDA

View Full Version : Gpl



inguz
2006-05-29, 06:04
From my limited understanding of the Gnu Public License, it seems that this license (or a compatible license) must apply to third-party SlimServer plugins. Is that true? Are there exceptions?

inguz
2006-05-30, 18:56
OK, no responses, so let me be more specific.

I have a plugin, currently unreleased. I do not wish to release this with a GPL license. But SlimServer is GPL, and this

http://www.gnu.org/licenses/gpl-faq.html#GPLModuleLicense

seems quite clearly to say that my plugin must be GPL or a compatible license.

Actually an MIT-style license for the perl component would probably be just fine. And of course there's no reason to obscure the plugin code (it's perl, after all).

But, there's an executable component to my planned product offering, which is in no way available to be licensed under GPL or compatible licenses. Looking at this part of the GPL FAQ it seems quite clearly to state that I can have my executable component invoked by slimserver with 'fork' or 'exec' (or equivalent, eg. transcode pipe), but not in a closer binding (eg. making COM function calls to methods within my executable component):

http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

Unfortunately there are good design reasons for my plugin to call COM methods in my executable library.

What to do?

erland
2006-05-30, 21:11
I am no expert on this but I would say that your situation is a "borderline case" as described in the second link in your post.

I also know that there are plugins already today that calls non GPL software, for example:
- MusicMagic plugin deliverd with slimserver calls MusicIP application using HTTP api, MusicIP is not GPL
- iTunesUpdate plugin calls iTunes application using COM.

So at least you wouldn't be alone, but as I said in the beginning I am not an legal expert.

Personally I would of course prefer that the plugin was release with GPL, but if that is not possible I would prefer that it was released using closed source license than that it wasn't released at all.

bill fumerola
2006-05-30, 23:28
On Tue, May 30, 2006 at 09:11:28PM -0700, erland wrote:
> Personally I would of course prefer that the plugin was release with
> GPL, but if that is not possible I would prefer that it was released
> using closed source license than that it wasn't released at all.

GPL isn't the only open source license. alternative licenses aren't
'closed' simply because they're not GPL. some of them aren't viral.

-- bill

htrd
2006-05-31, 01:06
On Wednesday 31 May 2006 02:56, inguz wrote:

.....

> Unfortunately there are good design reasons for my plugin to call COM
> methods in my executable library.
>
> What to do?

The GPL says:

| 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.

If your perl component is just a thin proxy layer which converts the plugin
API into COM method calls then it seems quite clear that your separate
executable (which implements the COM-ified plugin API) most likely is "a work
derived from" slimserver.

If your separate executable was developed before the slimserver plugin, and
clearly has a purpose independent of slimserver then it is clearly not "a
work derived from" slimserver. For example this is the case for iTunes, no
matter how many plugins make COM calls into it.

Most likely you are in the grey area in between ;-)

--
Toby Dickenson

Fred
2006-05-31, 16:05
I'd also be of the opinion that *what* it is is somewhat more important than the plumbing details.

If your plugin interfaces some external thingy, then providing Perl code mapping some generic API to the plugin one in GPL in combination with some executable talking to the external thingy sounds OK to me.

If your plugin is designed to perform advanced animation on the SqueezeBox screen and you want to hide the animation/graphics code, this is another matter.

In the second case, the viral nature of GPL fully applies as this is a downwards move (your code only extends the capabilities of the original code).
I'd say the first case is a lateral move, where you provide a bridge between two worlds. The grey area. GPL would like to apply but can't escape the fact a closed bridge may bring more good than no bridge at all.

So, well, knowing what this is all about would help us help you more, if only with our opinion.

Fred

inguz
2006-05-31, 16:16
It's this:
http://www.inguzaudio.com/EQ/

JJZolx
2006-05-31, 16:47
It's this:
http://www.inguzaudio.com/EQ/
Curious... I wonder how many SlimServer plugins have been released that run only on the Windows platform. Can the binary component not be compiled for the other supported SlimServer platforms?

Is the equalization done in a binary component for performance reasons or is it strictly for the purpose of hiding proprietary code?

inguz
2006-05-31, 17:35
The EQ is done by creating fairly long (4096-tap) FIR filters on demand. The convolution engine is compiled code for performance. It's Windows-only by a series of accidents (and to be honest I'm not worried about porting it, since a brutefir-based solution on linux should be achievable anyway). It's closed-source by choice.

Fred
2006-06-02, 04:11
Well,

From my perspective your stuff seems to have been created mainly as a Slimserver extension, and I would therefore expect the GPL to apply to your entire code. I mean that this plugin falls into the viral intentions of the GPL, to prevent parts of GPL work to slowly become closed source.

Your only hope IMHO lies in creative interpretation of some GPL clauses and acrobatic plumbing. But then, as mentioned before, other plugins are in the grey area, and what's your risk?

Fred

ceejay
2006-06-02, 09:07
I agree with Fred's interpretation - this has been created purely as a Slimserver plugin, and I'd be more than a little cross if this were released as parasitic code on the Slimserver base without being GPL'd.

Or do we think that the restrictions of the GPL are not in practice defensible?

If it were to be released as a separate engine that had a variety of applications - just one of which was slimserver - that would be a different matter.

Just my view.

Ceejay

John A. Tamplin
2006-06-03, 18:58
On Wed, 31 May 2006, inguz wrote:

> The EQ is done by creating fairly long (4096-tap) FIR filters on demand.
> The convolution engine is compiled code for performance. It's
> Windows-only by a series of accidents (and to be honest I'm not worried
> about porting it, since a brutefir-based solution on linux should be
> achievable anyway). It's closed-source by choice.

If you made it closed-source by choice, then it sounds like you decided
not to integrate it with code distributed under GPL. You are free to
use any proprietary code you like with GPL code, you simply can't
distribute the binary of such a system without distributing the source
required to build it.

You can always distribute the source to the GPL portion of your code (that
using the SlimDevices plugin API) and the binary of your proprietary code,
but you can't expect the plugin to be included in the main distribution as
it is worthless without the proprietary portion which can't be distributed
in that manner. It sounds much like the way NVidia distributes their
video drivers -- there is a GPL'd source version which includes GPL'd
kernel portions which is compiled, which then links to a binary driver
through a proprietary interface. Even the GPL'd portion of their driver
is not included in any distribution I know of.

--
John A. Tamplin jat (AT) jaet (DOT) org
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723

tme
2006-06-06, 07:51
i suspect you should be ok as GPL is primarily concerned with distribution rights so as long as you don't distribute your plugin with slimserver then you don't need to be GPL. it's the user who puts it together and at that point won't be able to distribute the bundle further....