[PD] gpl vs creative commons

[marius schebella]

at the moment the discussion is theoretical because it is not possible 
to close-source a pd patch.

the original question (whether a pd patch is a piece of software or a 
piece of artwork - gpl/bsd vs cc) was not really answered.

and then - what about abstractions? under which license are for example 
the pdmtl abstractions released?

the big overall question is how to deal with intellectual property. do 
we as a society/community want to protect it? of course everybody likes 
sharing, but I don't think communism worked out well after all.

marius.


Chris McCormick wrote:
> On Tue, Jan 29, 2008 at 10:41:39AM +0100, IOhannes m zmoelnig wrote:
>> Chris McCormick wrote:
>>> Interpereted works are
>>> not covered by the GPL, but linked code is.
>> i cannot believe this.
>> one of the gpl-faqs at fsf [1] is "If a programming language interpreter 
>> has a license that is incompatible with the GPL, can I run GPL-covered 
>> programs on it?"
>> for me this (the mere existence of this faq with a different answer than 
>> "programs written in interpreted languages are not covered by the GPL") 
>> means, that programs running on an interpreter (that is: programs 
>> written in interpreted languages) _can_ be covered by GPL.
> 
> Yes, I spoke too curtly. The first line of that answer says "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."
> 
> To my mind, this is the important bit for Pd. It doesn't matter what you
> link the Pd binary with - it is interpereting patches and they themselves
> aren't linked to GPL code (in my mind anyway).
> 
> I guess you could argue that instantiating a GPL external in Pd is like
> the case of Python's ctypes module, where you actually dynamically load a
> library and expose the API to your interpereted code itself - calling
> functions within the library from your script. I believe this requires
> you to release your interpereted code under the GPL if the library you
> are dynamically loading and linking your code with is GPL. But in my
> mind, a GPL external is more linked into Pd itself, which then uses
> that linked library to help interperet the Pd patch. So, in short, I
> dunno 100%. I would be more likely to err on the side of saying that
> you don't have to release your Pd patch GPL just because it uses GPL
> externals. That seems like a really weird restriction to me, but I might
> be wrong.
> 
>>>> finally, i am still unsure about the "static linking" clause, and how it 
>>>> affects an interpreted language.
>>> It doesn't in the case of the GPL.
>>
>> again quoting from [1]:
>>
>>> Another similar and very common case is to provide libraries with the
>>> interpreter which are themselves interpreted. For instance, Perl comes
>>> with many Perl modules, and a Java implementation comes with many Java
>>> classes. These libraries and the programs that call them are always
>>> dynamically linked together.
>>>
>>> A consequence is that if you choose to use GPL'd Perl modules or Java
>>> classes in your program, you must release the program in a
>>> GPL-compatible way, regardless of the license used in the Perl or Java
>>> interpreter that the combined Perl or Java program will run on.
>> even though it does not mention Pd explicitely (probably because it is 
>> significantly less used than e.g. Perl), it clearly states that if 
>> "interpreted libraries" (perl modules, java classes, pd abstractions) 
>> published under GPL (again: how is this possible if the GPL is not valid 
>> for interpreted languages) are used, then your program (patch) must be 
>> "released in a GPL-compatible way".
> 
> Yep, completely correct. So what it's basically saying is that if you
> use a GPL abstraction in your patch, then your patch must be GPL. That
> makes perfect sense to me. It doesn't say anything about externals
> though, and the question there is more complicated because the external
> is actually linked with the Pd interpereter itself, not with your patch
> (or is it?). I still don't think it's required that you release patches
> GPL just because you use a GPL external.
> 
>>>> i guess, if you have a  patch that depends on a GPL'ed pdlib, and you 
>>>> are distributing your patch with this library (e.g. for convencience 
>>>> reasons), then you are kind of _statically linking_ and thus your patch 
>>>> is automatically GPL'ed too.
>>> I really don't think so, unless you are actually using a linker program
>>> to link the .pd file with the Pd binary, which is very unlikely. If I am
>>> wrong then ALL YOUR BASE BELONG TO MILLER and I am switching to
>>> supercollider. :)
>> since when does statically linking defines ownership?
>> how is the license of supercollider (GPL) different from Pd's license 
>> (BSD), that it would prevent all of your sc code belong to james mccartney?
> 
> Of course statically linking doesn't define ownership. I like to think
> that what I said was funny and would be considered as a joke, but that
> is probably quite a stretch and I should go back to comedy school. Sorry
> for confusing the issue!
> 
> Best,
> 
> Chris.
> 
> -------------------
> http://mccormick.cx
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>