hey,
i've written some pd patches for an artist-in-residence working the Netherlands Media Art Institute Amsterdam (NIMK). NIMK are running something of an open-source-everything policy at the moment, so they want the patches released somehow.
there's two parts to the project, a text-parser (i recommend not doing text-parsing in Pd if you can help it, it hurts) and a sound-creation module.
the text-parsing part makes perfect sense to be released under the GPL to me, but the sound part is a little more unclear - perhaps Creative Commons makes more sense for a sound-making patch (despite CC's inherent problems..)
(i don't know - how do you license an interactive installation? is it software? is it music/media? what about a portable computing device that's processing incoming data in realtime to make sound?)
then there's the question of whether any and all Pd patches are 'derived works' (derived from Pd) or '[a combination of] two modules into one program' and therefore need to be GPL.
can anyone shed some light on this?
cheers d
Damian Stewart wrote:
then there's the question of whether any and all Pd patches are 'derived works' (derived from Pd) or '[a combination of] two modules into one program' and therefore need to be GPL.
No. The GPL only applies when distributing compiled binaries, as far as I'm aware.
.pd files are as much derived from Pd as a .py file is derived from a Python interpreter or a binary from a compiler (a compiler is a tool for creating binaries, which are derived works of their source, not the compiler).
Pd's linking is at runtime, you can distribute a collection containing GPL externals. and otherly licensed stuff, because they aren't linked together until you run it.
The output from a GPL program cannot be licenced (eg, it would be a nonsense for (LGPL) GCC to force all C programs it compiles to be (L)GPL). What you can do is license a particular recording - I license my patches under GPL, and time-consuming renders under CC license (but anyone who bothered to re-render could use the output as they wished, as far as I understand).
BTW, this is from my fuzzy understanding of GPL2, v3 might be different.
Also, Pd isn't GPL.
Claude
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
then there's the question of whether any and all Pd patches are 'derived works' (derived from Pd) or '[a combination of] two modules into one program' and therefore need to be GPL.
Pd isn't GPL, so even if patches were derived from it, you'd be fine in that regard.
Ciao
Frank Barknecht _ ______footils.org__
On Jan 28, 2008, at 3:45 AM, Frank Barknecht wrote:
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
then there's the question of whether any and all Pd patches are
'derived works' (derived from Pd) or '[a combination of] two modules into one program' and therefore need to be GPL.Pd isn't GPL, so even if patches were derived from it, you'd be fine in that regard.
Most externals are GPL'ed (and therefore Pd-extended too), so there
you have to watch.
As for a recommended license, you can use the GNU GPL as long as you
can make a clear distinction what the "source code" is. For a sound
file, the Pd patch and the Audacity files could be the "source
code". If you like the ideas of the GNU GPL but don't want to worry
about the source code definition, then the FSF (and I too ;)
recommend the Free Art License.
Check the section "Licenses for Works Besides Software and
Documentation":
http://www.gnu.org/philosophy/license-list.html
http://artlibre.org/licence/lal/en/
I think that the attribution clauses in all Creative Commons licenses
are problematic, just like the attribution clause in the original BSD
license was problematic and since removed. For more info on that,
watch for the people.makeart book coming from goto10. :D
.hc
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
Hans-Christoph Steiner wrote:
On Jan 28, 2008, at 3:45 AM, Frank Barknecht wrote:
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
then there's the question of whether any and all Pd patches are
'derived works' (derived from Pd) or '[a combination of] two modules into one program' and therefore need to be GPL.Pd isn't GPL, so even if patches were derived from it, you'd be fine in that regard.
Most externals are GPL'ed (and therefore Pd-extended too), so there
you have to watch.
does this mean it makes a difference if I use a library from within pd-extended or install it myself? from my understanding GPL is more restrictive than the Pd license (BSD). because it forces me to publish whatever I create under GPL again. does working with a library that is gpl force me to open source my pd patch? is a pd patch a derived software at all? and if yes, which are the libraries that can be used without problems? marius.
On Jan 28, 2008, at 1:23 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
On Jan 28, 2008, at 3:45 AM, Frank Barknecht wrote:
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
then there's the question of whether any and all Pd patches are
'derived works' (derived from Pd) or '[a combination of] two modules into
one program' and therefore need to be GPL.Pd isn't GPL, so even if patches were derived from it, you'd be fine in that regard.
Most externals are GPL'ed (and therefore Pd-extended too), so
there you have to watch.does this mean it makes a difference if I use a library from within
pd-extended or install it myself?
Technically, yes, but in reality, not really. If someone tried to
enforce the GPL on you, then you'd just have to make your own custom
build using the BSD licensed code.
from my understanding GPL is more restrictive than the Pd license
(BSD). because it forces me to publish whatever I create under GPL
again. does working with a library that is gpl force me to open source my
pd patch? is a pd patch a derived software at all? and if yes,
which are the libraries that can be used without problems? marius.
That's an interesting question. I think that if you write a patch
that uses a Pd library that is covered by the GPL, technically, your
patch is covered by the GPL. If those libs used the LGPL then you
would not. It's a bit of a gray area, but I release all my code
under the GPL, so I haven't really worried about it.
.hc
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
On Mon, 2008-01-28 at 18:06 -0500, Hans-Christoph Steiner wrote:
On Jan 28, 2008, at 1:23 PM, marius schebella wrote:
Hans-Christoph Steiner wrote:
On Jan 28, 2008, at 3:45 AM, Frank Barknecht wrote:
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
then there's the question of whether any and all Pd patches are
'derived works' (derived from Pd) or '[a combination of] two modules into
one program' and therefore need to be GPL.Pd isn't GPL, so even if patches were derived from it, you'd be fine in that regard.
Most externals are GPL'ed (and therefore Pd-extended too), so
there you have to watch.does this mean it makes a difference if I use a library from within
pd-extended or install it myself?Technically, yes, but in reality, not really. If someone tried to
enforce the GPL on you, then you'd just have to make your own custom
build using the BSD licensed code.from my understanding GPL is more restrictive than the Pd license
(BSD). because it forces me to publish whatever I create under GPL
again. does working with a library that is gpl force me to open source my
pd patch? is a pd patch a derived software at all? and if yes,
which are the libraries that can be used without problems? marius.That's an interesting question. I think that if you write a patch
that uses a Pd library that is covered by the GPL, technically, your
patch is covered by the GPL. If those libs used the LGPL then you
would not. It's a bit of a gray area, but I release all my code
under the GPL, so I haven't really worried about it.
not that i am an expert in this field myself, but i have the strong feeling (and iirc, i was told so), that this is not true. a song made in cubase is not affected by the license of cubase. a patch made in pd is not affected by the license of pd and is basically only a text-file with no relation to the source of pd nor to any external nor is it statically linked nor is it a derivate of the pd source code (one could perfectly write a pd-patch without touching pd at all nor reading the source of pd). as long as the patch is distributed without pd's or any external's source code, you are free to distribute it under whatsoever license you want. and i am pretty sure, that the same rules also apply on one level up: the songs you create with my patches are not affected by the license i gave to my patches. the songs you made with my patches derive from a legal point of view from your creativity (not mine) and therefor fall under your copyright (and are not affected by the license of my patches).
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, actually nothing could published anymore without violating licenses (or everything would need to be distributed under the same or compatible license).
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
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
On Tue, Jan 29, 2008 at 09:08:18AM +0100, 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".
In this particular case, Hans is wrong and you guys are right, but it's quite complicated, depending on the type of work which is created and the license of the software. Let me try to explain (IANAL and I am also sleep deprived :) ).
Hans wrote: "I think that if you write a patch that uses a Pd library that is covered by the GPL, technically, your patch is covered by the GPL."
This would only be true if you were: a) Distributing the GPL library/external with your patch. b) 'Linking' your patch with the original software.
On count (a) you generally don't distribute externals with your patch - you expect people to download and install them themselves. Distributing the patch on it's own is fine even if it used a commercially licensed external - it's up to other users to procure a license for that commercially licensed external in order to run your patch. Infact, if you are not distributing the result, you can do whatever you want (including linking commercial code or whatever) in the comfort of your own home and nobody can stop you.
On count (b), I don't think anybody would 'link' a Pd patch with Pd since that would require the patch to be turned into a data segment and linked into the Pd binary and a special hook would be required to load the linked binary segment directly into Pd at runtime instead of reading it from a .pd text file. In other words, if someone made a stand-alone application with the Pd file compiled into the binary and then distributed that, then they would probably be required to adhere to the GPL license of the externals used (e.g. if they used the linker program to link the patch into the application). This area is quite fuzzy because some people even contend whether dynamically linking things is covered by the GPL - this has probably changed with GPL 3.0 which probably makes it more explicit (but would still allow an interpereted .pd file no problems at all). If the developer/distributor used pure Pd then they wouldn't have to worry about that because it's BSD (except they would have to flash the Pd license to the user at some point).
It's conceivable that someone would write some software that had an EULA which specified that works created with that software were covered by the same license as that software (crossing "levels of abstraction"). Microsoft's Hotmail service does something like this - when you create a hotmail account you agree that all data and emails that pass through their server are owned by them. As for whether this would stand up in court or not is a different matter. Especially interesting in this regard is whether code is speech or not because as I said, the type of work created matters a lot as different works are considered in different ways under the law.
however, if i have a collection of abstractions published under the GPL, then i think i don't cross this magical border.
There is no "magical border". There is just different software with different licenses and different types of works (which are treated differently under the law) created with those bits of software. 99% of the time you are going to be fine and you are going to be able to license your work in whatever way you want, independently of the software. When the work is itself a computer program it seems more complicated but actually really isn't.
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)
Yep. The copyright covers the text of the source code. So if you re-write the source code in a different language you have created a new and different text. This is akin to re-writing a novel with different words and characters and place names, but with the same basic plot. It's completely legal. In the case of algorithms though, watch out because under certain jurisdictions they may be covered by software patents which will bite you in the ass.
The principal difference between and abstraction and an external is that an external is 'linked' with the Pd binary (dynamically at runtime usually) whilst an abstraction is interpereted. Interpereted works are not covered by the GPL, but linked code is.
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.
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. :)
Best,
Chris.
Chris McCormick wrote:
however, if i have a collection of abstractions published under the GPL, then i think i don't cross this magical border.
There is no "magical border". There is just different software with different licenses and different types of works (which are treated differently under the law) created with those bits of software. 99% of
this is what i was referring to as "magical border" (trying to find a metaphor for "crossing the 'levels of abstractions'")
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.
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".
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?
apart from that i largely agree.
mfga.sdr IOhannes
[1] http://www.fsf.org/licensing/licenses/gpl-faq.html
Best,
Chris.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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.
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
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
Hans-Christoph Steiner wrote:
On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:
but i really don't know
mfga.sd IOhannes
Dynamically linked libraries also trigger the GPL. For example, most
yeah; i wanted to stress that shipping a patch with abstraction dependencies could even be considered as static linking - because people seem to think that static linking enforces the GPL more than dynamic linking. (which does say nothing about whether this is true)
Linux kernel modules are dynamically linked into the kernel these
days, and they definitely required to be GPL.
but there _are_ non-GPL'ed kernel-modules. even though they are disliked.
mfg.,asdr. IOhannes
On Jan 29, 2008, at 10:05 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Jan 29, 2008, at 3:08 AM, IOhannes m zmoelnig wrote:
but i really don't know
mfga.sd IOhannes
Dynamically linked libraries also trigger the GPL. For example, most
yeah; i wanted to stress that shipping a patch with abstraction
dependencies could even be considered as static linking - because
people seem to think that static linking enforces the GPL more than
dynamic linking. (which does say nothing about whether this is true)Linux kernel modules are dynamically linked into the kernel these
days, and they definitely required to be GPL.but there _are_ non-GPL'ed kernel-modules. even though they are disliked.
Yes, and they are also technically in violation of the GPL, AFAIK. I
imagine that Linus and the FSF has not enforced it because it could
be counterproductive.
.hc
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
-
Chris McCormick -
Claude Heiland-Allen -
Damian Stewart -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
marius schebella -
Roman Haefeli