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