On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:
Roman Haefeli wrote:
ask a lawyer to check in detail, if this is true. however, if
licenses could cross 'levels of abstractions' in the sense of pd patches being affected by the license of pd,afaik, licenses do not cross "levels of abstractions". however, if i have a collection of abstractions published under the
GPL, then i think i don't cross this magical border.next comes the question, what is the difference between an
abstraction and an external non-abstraction object. afaik, GPL does
not dissolve just because of languages used. (that is: porting of
code from one language to another is (to my knowledge) not really
affected by the GPL (e.g.: you can chose the license again) as it
usually involves re-coding an algorithm rather than re-using pieces
of code.; but this is unrelated to the language a library is
written in)finally, i am still unsure about the "static linking" clause, and
how it affects an interpreted language. 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.but i really don't know
mfga.sd IOhannes
Dynamically linked libraries also trigger the GPL. For example, most
Linux kernel modules are dynamically linked into the kernel these
days, and they definitely required to be GPL.
PD patches are not a clear case like the Cubase example because
Cubase projects are clearly not programming. If you consider a Pd
patch a program, then it means it triggers the share-alike/copyleft
conditions of the GPL. When you load a patch, you are forcing all of
the compiled objects to be dynamically linked in, so the patch is
definitely linked.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White