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.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list