Hallo, IOhannes m zmölnig hat gesagt: // IOhannes m zmölnig wrote:
i don't quite understand your problem (but probably i am oversimplifying things)
Let me try to clarify my problem a bit. For that I assume, that not only [expr] is GPL, but that Pd would be GPL, too (I know it isn't).
Now as I understand the FSF, if I do a patch for such a GPL-Pd I'm not bound by the GPL for my patch, because it's just data. Assume my patch is this:
[+ 2]
No GPL required, even though my Pd is GPL.
Now I do a second patch and use [expr]:
[+ 2] | [expr $f1 + 2]
I'm using an extension that is covered by the GPL. According to my understanding of the FSF, *now* my patch has to be licensed GPL-compatible, because [expr] is GPL. But in fact, in a GPL-Pd, [+ 2] would be a GPL-object as well. Why is a simple extension more binding license-wise than the interpreter itself, which offers the same kind of objects? I can see absolutely no difference between [+ 2] and [expr $f1 + 2] in a GPL'd Pd.
That about wraps up my problems with understanding the interpreter-GPL.
i think it would be good, if we could ask a lawyer at FSF for a definitive answer. therefore we would need to set up a description of the problem to which we all agree (e.g. can a patch be considered a program at all)
Good idea. IMO a patch is very similar to a Perl script, additionally it can embed artwork like a sound sample in an array or a data structure drawing or score. (A special case would be k_cext.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__