Hi Frank, thanks for your interesting and instructive example. I think your arguments are correct, but it's a bit academic. Normally one does have a specific (GPL'd in our case) external in mind, and when the patch isn't GPL then, distribution would be impossible. The responsibility would somehow be shifted to the one packing the stuff, wouldn't it?
greetings, Thomas
A patch is not a derived work, so it doesn't have to be GPL.
I would be quite surprised if this is true. To my mind it's exactly the same as using a code library with an API, which is where LGPL comes in.
Putting aside, that LGPL and GPL are different beasts, here's how I see that using [expr] affects the licenses I can choose for my patch. Assuming I wrote this interesting application:
#N canvas 0 0 450 300 10; #X obj 144 139 expr 1 + 1;
I might intend to use the GPL-external [expr] in line 2. I might also intend to use an abstraction, that I happened to call "expr.pd" which looks like this:
#N canvas 0 0 450 300 10; #X obj 152 171 $1; #X obj 152 196 $2; #X obj 183 170 $3; #X connect 0 0 1 0; #X connect 2 0 1 1;
It behaves the same as if I'd used the GPL [expr] (minus some in/outlets).
Now would I be obliged to put my 2-line application under GPL, just because it uses a name, for which there also is a GPL-external? In my opinion: no. (In the light of the fact, that nameclashes still are a daily business, it even would be crazy to require that using certains identifiers would automatically make a patch need to follow the GPL.)
However of course as soon as I distribute a binary of the GPL-[expr] or its help file I would need to do as GPL says, which is provide sources for everything etc.
Pd itself is both a programming language and an implementation of this language. To me using the language is like using The Gimp for painting pictures: My pictures don't need to be released under GPL, even when The Gimp is. However distributing (derived) versions of Gimp *would* need to follow the GPL.
But IANAL etc.
Ciao