many years ago, Frakn Barknecht wrote:
several problems with several things (see debian.org). Darn, I don't know much else than that I don't like CC, and I can't even put my CC aversion into sensible words.
i'm interested in whether you still feel this Frank, and if you've made any progress at putting your aversion into words.
hi all!
I've Gem configured --without-gltt --without-avi --without-ieee1394
compiled and installed but when i try to load it it gives me
/usr/local/lib/pd/extra/Gem.pd_linux: /usr/local/lib/pd/extra/Gem.pd_linux: undefined symbol: XF86VidModeSetViewPort
i've also installed/
/libxxf86vm-dev
which should be answer to this, isn't it? do i have to set some paths?
powerpc, debian, kernel 2.6.16.20, xorg 7, mesalibs & -glut local installed
thanks, romana
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
many years ago, Frakn Barknecht wrote:
several problems with several things (see debian.org). Darn, I don't know much else than that I don't like CC, and I can't even put my CC aversion into sensible words.
i'm interested in whether you still feel this Frank, and if you've made any progress at putting your aversion into words.
Interestingly some other people put it into words: http://www.metamute.org/?q=en/Freedoms-Standard-Advanced http://www.fsf.org/blogs/rms/entry-20050920.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
which license would be advised for free software, and in concrete for pd
patches? I was thinking about something free to all uses, but where
reference to the original creator would be kept. in the CC site they
advise to choose other licenses to software than their's.
Joao
Am 15.06.2006, 12:28 Uhr, schrieb Frank Barknecht fbar@footils.org:
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
many years ago, Frakn Barknecht wrote:
several problems with several things (see debian.org). Darn, I don't know much else than that I don't like CC, and I can't even put my CC aversion into sensible words.
i'm interested in whether you still feel this Frank, and if you've made any progress at putting your aversion into words.
Interestingly some other people put it into words: http://www.metamute.org/?q=en/Freedoms-Standard-Advanced http://www.fsf.org/blogs/rms/entry-20050920.html
Ciao
Hallo, João Miguel Pais hat gesagt: // João Miguel Pais wrote:
which license would be advised for free software, and in concrete for pd
patches? I was thinking about something free to all uses, but where
reference to the original creator would be kept. in the CC site they
advise to choose other licenses to software than their's.
Generally Pd's license is well accepted in the comunity, another popular choice is the GPL. I would recommend to stay away from trying to make up your own license.
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too. Personally I don't believe it has to be GPL, but I think, IOhannes once argued that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Le 15 Juin 2006 09:40, Frank Barknecht a écrit :
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too. Personally I don't believe it has to be GPL, but I think, IOhannes once argued that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)
A patch is not a derived work, so it doesn't have to be GPL. For example, an image created with Gimp doesn't have to be GPL. -- Marc
Marc Lavallée schrieb:
Le 15 Juin 2006 09:40, Frank Barknecht a écrit :
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too. Personally I don't believe it has to be GPL, but I think, IOhannes once argued that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)
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.
greetings, Thomas
Hallo, Thomas Grill hat gesagt: // Thomas Grill wrote:
Marc Lavallée schrieb:
Le 15 Juin 2006 09:40, Frank Barknecht a écrit :
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too. Personally I don't believe it has to be GPL, but I think, IOhannes once argued that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)
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
Frank Barknecht _ ______footils.org_ __goto10.org__
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
I've had this question for a while now: (and I sure don't understand licenses)
Suppose I get a job as an engineer, and decide to prototype DSP or control algorithms using Pd, for some great big company. Do we have legal issues, in development? Then, suppose, we decide to sell, hardware (like embedded linux) with Pd running the DSP algorithm, and some proprietary external (not released), that makes it work. Do we have legal issues, then?
At what point, do we cross the line and become evil like Tivo?
Chuck
- Pd from Miller is BSD licensed so you can do whatever you want with
it as long as you include the copyright statement.
- Pd-extended and almost everything in the pure-data CVS is GNU
GPL'ed. That means you can do whatever you want with it as long as
you freely distribute the source to any changes that you make.
So either way, you would have no legal issues in your two examples.
You would only have legal issues if the company did not share its
changes of Pd-extended or other GPL'ed code. They would be forced to
release the source just like Linksys was for their routers.
.hc
On Jun 15, 2006, at 7:03 PM, Charles Henry wrote:
I've had this question for a while now: (and I sure don't
understand licenses)Suppose I get a job as an engineer, and decide to prototype DSP or control algorithms using Pd, for some great big company. Do we have legal issues, in development? Then, suppose, we decide to sell, hardware (like embedded linux) with Pd running the DSP algorithm, and some proprietary external (not released), that makes it work. Do we have legal issues, then?
At what point, do we cross the line and become evil like Tivo?
Chuck
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
hi.
as thomas has said, this is indeed a neat example.
however, if someone could share a light on my ignorance on GPL:
my little program uses "freelib" a GPL-covered (not LGPL) library, for free speech. the only header file of this lib is freelib.h:
#ifndef FREELIB_H #define FREELIB_H #ifdef __cplusplus extern "C" { #endif void speak_free(char *string); #ifdef __cplusplus } #endif #endif
that's the little program i wrote:
#include <freelib.h> int main(){ speak_free("freedom sucks"); return 0; }
when i link my program against freelib, it surely has to be covered by the GPL (http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL) only because i have because 2 lines in my source code refer to this library.
but hold on! what if i had written a header-file "freelib.h" on my own:
#define speak_free(x)
this header-file is under a very restrictive EULA which infects all source code which uses it (like the GPL, but worse). so my little program surely has to be covered by this license.
so can anybody tell me, which license my program has to be published under? i doubt that this has not been discussed to death at fsf. most likely the arguing will be about "intentioned use" and/or about 2 licenses to be applied to the final program (depending on the produced binary).
Frank Barknecht wrote:
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.)
the occurence of "expr" in your .pd-file will not make your 2-liner to be covered by the GPL. this has nothing to with name-clashes, but with modularity: i can implement a free version of a non-free library, which share the interface (as long as the interface is not protected by some explicit legal "thing"; but even then i guess that you could find some loophole), just the same as i could implement a library totally differently (e.g. my libfree() could output the free speech to the console, a lineprinter or via blinkenlights.
typing "expr" within an object box is not enough to be caught by the GPL. however, using shahrokh's [expr] will make any patch GPL.
but of course i have not the slightest idea about legal issues....
mfga.sdr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
so can anybody tell me, which license my program has to be published under? i doubt that this has not been discussed to death at fsf. most likely the arguing will be about "intentioned use" and/or about 2 licenses to be applied to the final program (depending on the produced binary).
Maybe this is a case of the "dual-license" thing that's becoming popular for GPL software. If you distribute a binary of your little program linked with the GPL-speakfree, then you little program has to be *distributed* according to GPL as well. Linking that code with a nonfree-speakfree would be forbidden.
However if someone wants to do so, he could ask you for permission to do it, and if you agree, you could give him the license to link with proprietary code as well, because you are the author of the little program. You still cannot give a "closed license" to link with GPL-speakfree, of course.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Le 20 Juin 2006 05:40, IOhannes m zmoelnig a écrit :
however, using shahrokh's [expr] will make any patch GPL.
Is a patch using [expr] like a derivative work? I don't think so. A derivative work is more like a "new version" of something. "1+1", even calculated with a GPL software and saved within a patch is not a derivative work. A picture retouched with the Gimp is a derivative work of the original picture, not of the Gimp. -- Marc
On Tue, 20 Jun 2006, Marc Lavallée wrote:
Is a patch using [expr] like a derivative work? I don't think so. A derivative work is more like a "new version" of something. "1+1", even calculated with a GPL software and saved within a patch is not a derivative work.
Derivative work according to GPL includes anything made with GPL libraries.
If you can make [expr] run in another process, you might have an effective means of circumventing the GPL. =)
work. A picture retouched with the Gimp is a derivative work of the original picture, not of the Gimp.
It's not a suitable analogy because the picture doesn't contain a copy of the Gimp.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Tue, 20 Jun 2006, Marc Lavallée wrote:
Is a patch using [expr] like a derivative work? I don't think so. A derivative work is more like a "new version" of something. "1+1", even calculated with a GPL software and saved within a patch is not a derivative work.
Derivative work according to GPL includes anything made with GPL libraries.
Not quite: anything "linked to" GPL software, but not anything "made with GPL". It already is a different case with interpreted languages, as I mentioned in a previous mail, where I quoted the respective GPL FAQ entry in full.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
hi matju, hi marc
On Tue, 2006-06-20 at 22:38 -0400, Mathieu Bouchard wrote:
work. A picture retouched with the Gimp is a derivative work of the original picture, not of the Gimp.
It's not a suitable analogy because the picture doesn't contain a copy of the Gimp.
so does a patch not contain the code of [expr], but is referencing it. it doesn't even say, which [expr] it is referencing. what if, when you share a patch and give a dummy-[expr] with it and you tell explicitly not to use the 'original' [expr], that comes with millers pd, and people do substitute it by themselves?
roman
___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
unfortunately my pc crashed while i was typing a reply. so i'll try it again
hi
Roman Haefeli wrote:
so does a patch not contain the code of [expr], but is referencing it. it doesn't even say, which [expr] it is referencing.
but it is the same with any dynamically linked code: in my little example, my program does not know, which "void speak_free(char*)" it is referencing; it just knows that "someone" (e.g. any(!) of the libraries it is linked to) ought to provide this function. it doesn't know which library will provide the symbolic name "speak_free". furthermore, it only knows the names of the libraries it is linked to (which is essentially the same as pd knows about any "yet unknown" object); you can replace the /usr/lib/libfreelib.so with any other dynamic library (if you want to use it with other programs, you might want this library to provide the same symbols as the original one)
still, if my programm uses the GPL'ed "freelib", it MUST be distributed under the GPL. therefore i think that if your patch uses the GPL'ed [expr], it needs to be GPL'ed too.
what if, when you share a patch and give a dummy-[expr] with it and you tell explicitly not to use the 'original' [expr], that comes with millers pd, and people do substitute it by themselves?
if your patch is released under a GPL-incompatible license, then the users who substitute your [expr] with the GPL'ed one, might be violating the GPL (probably only, if they distribute your patch "linked" with GPL [expr]); your patch should not be affected by whatever license shahrokh's [expr] is released under.
however, if you don't provide a separate version of [expr] and don't give users a hint that they must not use shahrokh's [expr], then one could argue that since the GPL'ed [expr] is bundled with pd, any "ordinary" user will by-default use the GPL'ed version and therefore your patch has to be GPL'ed too.
fmga.sdr IOhannes
On Wed, 2006-06-21 at 12:01 +0200, IOhannes m zmoelnig wrote:
what if, when you share a patch and give a dummy-[expr] with it and
you
tell explicitly not to use the 'original' [expr], that comes with millers pd, and people do substitute it by themselves?
if your patch is released under a GPL-incompatible license, then the users who substitute your [expr] with the GPL'ed one, might be violating the GPL (probably only, if they distribute your patch "linked" with GPL [expr]); your patch should not be affected by whatever license shahrokh's [expr] is released under.
well, my interpretation of: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL is the following:
if expr would be part of the pd language, patches wouldn't have to be gpl-compatible licensed ... the question is, _is_ expr part of the pd language? as there is no language specification it is not clear ...
otoh, it's also possible to run gpl'ed programs with a proprietary interpreter like max/msp (http://www.gnu.org/licenses/gpl-faq.html#TOCInterpreterIncompat)
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Nothing exists until or unless it is observed. An artist is making something exist by observing it. And his hope for other people is that they will also make it exist by observing it. I call it 'creative observation.' Creative viewing. William S. Burroughs
Tim Blechmann wrote:
On Wed, 2006-06-21 at 12:01 +0200, IOhannes m zmoelnig wrote:
what if, when you share a patch and give a dummy-[expr] with it and
you
tell explicitly not to use the 'original' [expr], that comes with millers pd, and people do substitute it by themselves?
if your patch is released under a GPL-incompatible license, then the users who substitute your [expr] with the GPL'ed one, might be violating the GPL (probably only, if they distribute your patch "linked" with GPL [expr]); your patch should not be affected by whatever license shahrokh's [expr] is released under.
well, my interpretation of: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL is the following:
if expr would be part of the pd language, patches wouldn't have to be gpl-compatible licensed ... the question is, _is_ expr part of the pd language? as there is no language specification it is not clear ...
since [expr] is not part of pd itself, how should it be part of the language?
i think the number of objects that are really part of the Pd-language (this is: they are "keywords") is rather small. i think that most objects that are built-ins are not to be seen as "part of the language" but part of the default "object library" that comes with pd.
otoh, it's also possible to run gpl'ed programs with a proprietary interpreter like max/msp (http://www.gnu.org/licenses/gpl-faq.html#TOCInterpreterIncompat)
and i am pretty sure that it is allowed to compile GPL'ed sources with proprietary compilers (else we would have a problem), as well as run it on proprietary operating systems and hardware.
mfg.sdr IOhannes
Le 20 Juin 2006 22:38, Mathieu Bouchard a écrit :
On Tue, 20 Jun 2006, Marc Lavallée wrote:
Is a patch using [expr] like a derivative work? I don't think so. A derivative work is more like a "new version" of something. "1+1", even calculated with a GPL software and saved within a patch is not a derivative work.
Derivative work according to GPL includes anything made with GPL libraries. If you can make [expr] run in another process, you might have an effective means of circumventing the GPL. =)
The term "derivative work" is defined in the copyright law, not in the GPL. Here's an article about this: http://www.linuxjournal.com/article/6366 And the Wikipedia article: http://en.wikipedia.org/wiki/Derivative_work
Modifying a software does create a derivative work. Static linking also create a derivative work. But using a software never create derivative works. A PD patch could be interpreted by some other software, like a tiff image created with the Gimp could be opened and modified using Photoshop.
work. A picture retouched with the Gimp is a derivative work of the original picture, not of the Gimp.
It's not a suitable analogy because the picture doesn't contain a copy of the Gimp.
Just like a patch using [expr] does not contains a copy of [expr].
On Wed, 2006-06-21 at 09:24 -0400, Marc Lavallée wrote:
work. A picture retouched with the Gimp is a derivative work of
the
original picture, not of the Gimp.
It's not a suitable analogy because the picture doesn't contain a
copy of
the Gimp.
Just like a patch using [expr] does not contains a copy of [expr].
loading expr could be interpreted as binding to facilities: http://www.gnu.org/licenses/gpl-faq.html#TOCIfInterpreterIsGPL
t
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. Groucho Marx
Le 21 Juin 2006 09:55, Tim Blechmann a écrit :
Just like a patch using [expr] does not contains a copy of [expr].
loading expr could be interpreted as binding to facilities: http://www.gnu.org/licenses/gpl-faq.html#TOCIfInterpreterIsGPL
But the binding occurs between [expr] and Pd, not between a patch using [expr] and [expr]. A patch is a document; it can ask the original [expr] or a different [expr] to interpret "1+1". -- Marc
Marc Lavallée wrote:
Le 21 Juin 2006 09:55, Tim Blechmann a écrit :
Just like a patch using [expr] does not contains a copy of [expr].
loading expr could be interpreted as binding to facilities: http://www.gnu.org/licenses/gpl-faq.html#TOCIfInterpreterIsGPL
But the binding occurs between [expr] and Pd, not between a patch using
no, the binding occurs between [expr] and the patch (both are run by Pd). your argumentation would render GPL on any interpreted language meaningless. however, fsf thinks (and i believe they have asked their lawyers who probably know more about legal issues than me) that GPL is applicable to interpreted languages (else all those quoted FAQ entries would not make sense).
[expr] and [expr]. A patch is a document; it can ask the original [expr] or a different [expr] to interpret "1+1".
the patch is also code (a .c file with c-code in it looks like a text document; it _is_ a document (try opening it with notepad); but it is code too) if '(the patch) can ask the original [expr] or a different [expr] to interpret "1+1"', then the patch has ceased to be a passive document and *actively* links to a library (either this [expr] or another). in this case, there is no doubt, that if the patch asks the GPL'ed [expr] to interpret "1+1" it has to be GPL too.
however, usually the patch cannot decide which object it uses - that's why we are discussing.
mfga.sdr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Marc Lavallée wrote:
Le 21 Juin 2006 09:55, Tim Blechmann a écrit :
Just like a patch using [expr] does not contains a copy of [expr].
loading expr could be interpreted as binding to facilities: http://www.gnu.org/licenses/gpl-faq.html#TOCIfInterpreterIsGPL
But the binding occurs between [expr] and Pd, not between a patch using
no, the binding occurs between [expr] and the patch (both are run by Pd). your argumentation would render GPL on any interpreted language meaningless. however, fsf thinks (and i believe they have asked their lawyers who probably know more about legal issues than me) that GPL is applicable to interpreted languages (else all those quoted FAQ entries would not make sense).
What I don't understand at all about http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL is this:
The FAQ-answer first states, that I'm not obliged to put the GPL or anything compatible on an interpreted program, even if the interpreter is GPL, because my interpreted program is "just data" to the interpreter.
But then later it says, that if I'm using some modules of that interpreted language, that are GPL, in my "just data"-program, I'm suddenly obliged to use GPL or compatible.
I mean, if the interpreter is GPL and I'm not bound by its terms, then why is is, that if I'm using some GPL's extensions of that interpreter, that I'm now bound to the GPL?
How comes, that my "just data" program now became more than "just data"?
I mean, I'm not opposed to using the GPL, as you all should know by now, but: I just don't get it!?
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
I mean, if the interpreter is GPL and I'm not bound by its terms, then why is is, that if I'm using some GPL's extensions of that interpreter, that I'm now bound to the GPL?
How comes, that my "just data" program now became more than "just data"?
I mean, I'm not opposed to using the GPL, as you all should know by now, but: I just don't get it!?
Just my 2 cents...
I believe it is because of this kind of things that the LGPL came into existance. Let's forget about pd for a moment. Imagine you are a c programmer and you're writing software using the gcc compiler. The running version of your software does not use gcc anymore, so you're safe there. But in most cases you've used some libraries, and they get staticly or dynamicly linked. So you need them to run your software. If those libraries are GPL'd, your software MUST be GPL too! That is why the LGPL is 'invented'. Placing the libraries in LGPL gives freedom to commercial vendors, to create and sell software that makes use of, for example, important linux libraries. In other words, the GPL does NOT give them the right to do so, only the LGPL does. Back to PD now. Pd is an interpreter, not a compiler. But externals are like libraries. If everything is GPL, the answer is quite simple, i think. What you make with it must be released under GPL too. If the externals are LGPL, you can choose yourself. Only one more problem: The gcc compiler itself could stay GPL because it is not needed when you use the program. That is different with pd. It means that everything made with pd must be GPL?? This is fortunately not true. There is an exception for interpreters. Our pd-patches are just data. It's like writing a book in open-office. It does not mean you have to release it under the GPL just because you used GPL software to write it. But extensions are another thing. It's like placing a chapter from a gpl'd book in your own book. If you do so, your book must be gpl too. If this is not wat we want, then i guess extensions should be released with LGPL, just like many libraries.
I'm not a real expert of course. But after several years of involvement with open source, this is what i think is how it works. And i think it makes sense that way.
Regards,
yvan vander sanden
hi
Frank Barknecht wrote:
Hallo,
What I don't understand at all about http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL is this:
The FAQ-answer first states, that I'm not obliged to put the GPL or anything compatible on an interpreted program, even if the interpreter is GPL, because my interpreted program is "just data" to the interpreter.
But then later it says, that if I'm using some modules of that interpreted language, that are GPL, in my "just data"-program, I'm suddenly obliged to use GPL or compatible.
i don't quite understand your problem (but probably i am oversimplifying things)
the "modules" in question are not extensions to the interpreter but extensions for the patch.
imo, an extension to pd itself (which will NOT influence the license of the patch, because of the "IfInterpreterIsGPL" issue), would for example be a plugin that would allow for spline patch chords. such a feature would add nothing to the functionality of the patch itself, though it might make patches prettier (or not;-)) and it might increase your productivity in general (e.g. when you created the patch). however, the patch itself is not really touched by such an extension.
another example (this time from the real world) _might_ be the features added to core-pd in the pd-extended distribution: i am NOT talking about the added libraries! but about things like the libpath hack and the like. while these hacks might be GPL'ed, they would not affect a patch created with such a version of pd.
another example: if you were using a library which provides gui elements for pd (like iemgui, ...) and your patch is "artistic per se" (this is: the patch looks pretty enough to be considered artistic), then the artwork would not need to be covered by the GPL (like when you create an image with the gimp) no i don't want to start a discussion about when a patch starts to be an artwork by itself nor about art at all.
I mean, if the interpreter is GPL and I'm not bound by its terms, then why is is, that if I'm using some GPL's extensions of that interpreter, that I'm now bound to the GPL?
because it is not an extension to the interpreter but to the program.
btw, as we all know, Pd is NOT released under GPL but under a "free to evil" :-) license. this license does not apply to patches as long as only the interpreter "Pd" is used. this license applies (imo) to patches as soon as you use Pd core objects that are not to be seen as "part of the language" (whatever these are); luckily Pd's licence is so free that you can as you like.
How comes, that my "just data" program now became more than "just data"?
for the interpreter Pd, your patch is "just data", like C-code is "just data" for a compiler. it ceases to be "just data", when it is run (by the interpreter), because then it becomes instructions.
btw, [expr] is an interpreter by itself. the [expr]essions need not be covered by the GPL. so if you have patented a new algorithm and want to put it into a pd-patch which is using [expr], you could write your algorithm as an [expr] expression without violating the GPL.
I mean, I'm not opposed to using the GPL, as you all should know by now, but: I just don't get it!?
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)
mfg.asdr. IOhannes
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__
Frank Barknecht wrote:
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.
quoting myself:
<quote> btw, as we all know, Pd is NOT released under GPL but under a "free to evil" :-) license. this license does not apply to patches as long as only the interpreter "Pd" is used. this license applies (imo) to patches as soon as you use Pd core objects that are not to be seen as "part of the language" (whatever these are); luckily Pd's licence is so free that you can as you like. </quote>
so i could answer your problem, if we could find a definition about which objects are part of the "language specification" and which objects are "other" objects. i guess [trigger] could be seen as "language specification" object (lso), since it represents a core concept of how dataflow is handled within Pd [readsf~] is probably one of the "other" objects.
most likely [+] would be an lso too.
so even in a GPL-Pd, your 1st patch would not need to be GPL'ed.
my conclusion of this is, that *if* Pd was GPL'ed, we would need to define the boundaries between these 2 sets of built-in objects.
since Pd is not GPL'ed, we can skip this and still be happy.
mfga.sdr. IOhannes
IOhannes m zmoelnig wrote:
Marc Lavallée wrote:
Le 21 Juin 2006 09:55, Tim Blechmann a écrit :
Just like a patch using [expr] does not contains a copy of [expr].
loading expr could be interpreted as binding to facilities: http://www.gnu.org/licenses/gpl-faq.html#TOCIfInterpreterIsGPL
But the binding occurs between [expr] and Pd, not between a patch using
no, the binding occurs between [expr] and the patch (both are run by Pd). your argumentation would render GPL on any interpreted language meaningless. however, fsf thinks (and i believe they have asked their lawyers who probably know more about legal issues than me) that GPL is applicable to interpreted languages (else all those quoted FAQ entries would not make sense).
[expr] and [expr]. A patch is a document; it can ask the original [expr] or a different [expr] to interpret "1+1".
the patch is also code (a .c file with c-code in it looks like a text document; it _is_ a document (try opening it with notepad); but it is code too) if '(the patch) can ask the original [expr] or a different [expr] to interpret "1+1"', then the patch has ceased to be a passive document and *actively* links to a library (either this [expr] or another). in this case, there is no doubt, that if the patch asks the GPL'ed [expr] to interpret "1+1" it has to be GPL too.
however, usually the patch cannot decide which object it uses - that's why we are discussing.
mfga.sdr. IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
IMO, the biggest problem regarding these discussions about licenses, intellectual property, copyright and so on is that it's impossible to judge if a work is original. What if, for instance, I decide to write my own [expr] implementation. The copyright would be mine and I could also decide to use another kind of licence.
I bet that when comparing the source of my own implementation with the original one they'll be so similar that there's no way to tell if I copied the original source and maybe just changed the name of some vars or if I started from scratch, finding my own way of doing the same thing.
This is why patents (especially software patents) are evil.
c.
Marc Lavallée wrote:
Modifying a software does create a derivative work. Static linking also create a derivative work. But using a software never create derivative works. A PD patch could be interpreted by some other software, like a tiff image created with the Gimp could be opened and modified using Photoshop.
which interpreter is used to run a Pd-patch does not affect the license of the pd-patch. see http://www.fsf.org/licensing/licenses/gpl-faq.html#InterpreterIncompat
what matju was referring to is this article: http://www.fsf.org/licensing/licenses/gpl-faq.html#NFUseGPLPlugins which says: "If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program."
if a Pd-patch is seen as a program, then it makes use of plug-ins (externals) via Pd's built-in loading mechanism, which is NOT based on "fork and exec" (or similar). continuing the quote: "If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license..."
according to http://en.wikipedia.org/wiki/Plug-in i think that Pd-externals are "plug-ins". objects within pd make function calls to each other via Pd's inlet/outlet concept and share data structures (e.g. lists of atoms)
mfg.asdr. IOhannes
Marc Lavallée wrote:
Le 15 Juin 2006 09:40, Frank Barknecht a écrit :
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too. Personally I don't believe it has to be GPL, but I think, IOhannes once argued that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)
A patch is not a derived work, so it doesn't have to be GPL. For example, an image created with Gimp doesn't have to be GPL.
yeah, but [expr] isn't like Gimp, it's more like a library. for example if you were to take gimp and build some larger program using it, then the larger program would have to be gpl. pd patches are more like software objects than sound objects...
hmm, although in that thinking [expr] is being used like a lib in traditional software development; just using a gpl'd lib doesn't mean that you have to gpl the thing that uses the lib - does it?
Hallo, Damian Stewart hat gesagt: // Damian Stewart wrote:
hmm, although in that thinking [expr] is being used like a lib in traditional software development; just using a gpl'd lib doesn't mean that you have to gpl the thing that uses the lib - does it?
If using means "linking", then yes, it does for GPL, but no, it doesn't for LGPL.
Quoting http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL now:
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?
Yes, because the program as it is actually run includes the
library.
Looking this up, I found another interesting FAQ directly after it, which might be interesting to our case. My remarks are indented 8 spaces:
If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses?
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.
Frank: IMO Pd is an interpreter, patches are interpreted
programs. [expr] can be viewed as an interpreter in itself as
well.
However, when the interpreter is extended to provide "bindings" to
other facilities (often, but not necessarily, libraries), the
interpreted program is effectively linked to the facilities it
uses through these bindings. So if these facilities are released
under the GPL, the interpreted program that uses them must be
released in a GPL-compatible way. The JNI or Java Native Interface
is an example of such a binding mechanism; libraries that are
accessed in this way are linked dynamically with the Java programs
that call them. These libraries are also linked with the
interpreter. If the interpreter is linked statically with these
libraries, or if it is designed to link dynamically with these
specific libraries, then it too needs to be released in a
GPL-compatible way.
Frank: I must admit, I don't fully understand above paragraph
yet, probably because I have only a vague view of what "JNI"
and "bindings" are exactly. Is a patch similar to JNI? As I
understand it, it is not: A patch file is not effectively
linked to anything, it is just instructing Pd to link its main
application to other modules/libraries. I also see some tricky
cases coming up here: Assuming I write a closed-source, binary
only external. Someone else uses it in a patch and also uses
[expr] there. Is this someone allowed to distribute the patch
file? Am I, as the author of the binary external, suddenly
violating the GPL without even knowing?
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.
Frank: "libraries which are themselves interpreted" would be
patches shipped with Pd.
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.
We should probably consult a lawyer now. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jun 15, 2006, at 5:55 PM, Damian Stewart wrote:
Marc Lavallée wrote:
Le 15 Juin 2006 09:40, Frank Barknecht a écrit :
There seems to be no consensus about wether a patch, that uses externals released under GPL, should have to be GPL, too.
Personally I don't believe it has to be GPL, but I think, IOhannes once argued
that it has to be GPL as well. (Which would mean, that all patches using [expr] would need to be GPL, btw.)A patch is not a derived work, so it doesn't have to be GPL. For example, an image created with Gimp doesn't have to be GPL.
yeah, but [expr] isn't like Gimp, it's more like a library. for
example if you were to take gimp and build some larger program
using it, then the larger program would have to be gpl. pd patches
are more like software objects than sound objects...hmm, although in that thinking [expr] is being used like a lib in
traditional software development; just using a gpl'd lib doesn't
mean that you have to gpl the thing that uses the lib - does it?
The GNU GPL requires software that links against GPL'ed libraries to
GPL'ed also. The LGPL does not.
.hc
http://at.or.at/hans/
Le 15 Juin 2006 06:28, Frank Barknecht a écrit :
Hallo,
Damian Stewart hat gesagt: // Damian Stewart wrote:
many years ago, Frakn Barknecht wrote:
several problems with several things (see debian.org). Darn, I don't know much else than that I don't like CC, and I can't even put my CC aversion into sensible words.
i'm interested in whether you still feel this Frank, and if you've made any progress at putting your aversion into words.
Interestingly some other people put it into words: http://www.metamute.org/?q=en/Freedoms-Standard-Advanced http://www.fsf.org/blogs/rms/entry-20050920.html
The problem is that we tend to believe that CC licenses are either all good or all bad. A licence is not a trademark. CC is not a license, its an experimental legal framework to challenge the traditional conception of copyright. The GPL is endorsed by CC, but the FSF is pissed off because the CC is not an ideological movement, it's a place where lawyers and the general public can have some fun, together. The CC initiative is fine, as long as we take the time to understand their (easy) licenses. -- Marc
Interestingly some other people put it into words: http://www.metamute.org/?q=en/Freedoms-Standard-Advanced http://www.fsf.org/blogs/rms/entry-20050920.html
The problem is that we tend to believe that CC licenses are either all good or all bad. A licence is not a trademark. CC is not a license, its an experimental legal framework to challenge the traditional conception of copyright. The GPL is endorsed by CC, but the FSF is pissed off because the CC is not an ideological movement, it's a place where lawyers and the general public can have some fun, together. The CC initiative is fine, as long as we take the time to understand their (easy) licenses.
I think a greater problem is that we tend to think of GPL and CC as being similar things, when in fact they are quite different.
But, I'm not so sure the CC is not an ideological movement. It's just that it's not as totalitarian as the FLOSS/GPL movement.
CC addresses the production of culture, the GPL address the production of code. They are two very different intentions, two very different "things".
And, despite being a FLOSS advocate and avid FLOSS programmer since many years, I take particular offense to this article:
http://www.metamute.org/?q=en/Freedoms-Standard-Advanced
Mako Hill only wishes to extend the naive tautology of the word "freedom", and knock CC for not having an ideology that is as simple and total as the GPL.
best -august.
Le 15 Juin 2006 11:50, august a écrit :
But, I'm not so sure the CC is not an ideological movement. It's just that it's not as totalitarian as the FLOSS/GPL movement.
The FSF have a very strong position and is essential to this movement; the larger FLOSS "movement" basically want the source code and doesn't stand for much. The free software movement is setting the rules to ease and protect the development and use of free software, which includes being against proprietary software and restrictive about the way source code should be used, but it is not totalitarian.
Consider the description of "totalitarism" in Wikipedia: "Totalitarianism is a term employed by political scientists, especially those in the field of comparative politics, to describe modern regimes in which the state regulates nearly every aspect of public and private behavior". Free software is not a regime, and is not telling us what to do with source code in private. By comparaison, proprietary software is monopolistic, companies dont want us to know how their products are made, and they would like to know what we do in private with them, because it's their absolute property. The "content industry" is even worse...
CC addresses the production of culture, the GPL address the production of code. They are two very different intentions, two very different "things".
Yes. But not so different. The CC licenses (with "some rights reserved") are not like the GPL (or some other free license), because the "cultural industry" is not ready for the kind of freedom promoted by the FSF; this industry is being totalitarian because it was able, after centuries, to create such a restrictive context. The free software movement started at about the same time as the PC industry because it was threatening the freedom of programmers that were already sharing code. The software industry is still young, so it's the right time to promote a favorable context to legally protect our computing freedom, hoping this will continue to inspire other types of human activities.
And, despite being a FLOSS advocate and avid FLOSS programmer since many years, I take particular offense to this article:
http://www.metamute.org/?q=en/Freedoms-Standard-Advanced
Mako Hill only wishes to extend the naive tautology of the word "freedom", and knock CC for not having an ideology that is as simple and total as the GPL.
Exactly. But I understand the critic of the FSF about some CC licenses; for example, the "Developing Countries" license is a good example of a bad license with a good intention. The CC project should be careful, because if it evolves only as a collection of almost good and not so free licenses, it will loose its momentum. It's now the right time to promote cultural freedom, like 1984 was the right time to promote computing freedom.
On Jun 15, 2006, at 11:50 AM, august wrote:
Interestingly some other people put it into words: http://www.metamute.org/?q=en/Freedoms-Standard-Advanced http://www.fsf.org/blogs/rms/entry-20050920.html
The problem is that we tend to believe that CC licenses are either
all good or all bad. A licence is not a trademark. CC is not a license, its an experimental legal framework to challenge the traditional
conception of copyright. The GPL is endorsed by CC, but the FSF is pissed off
because the CC is not an ideological movement, it's a place where lawyers and the general public can have some fun, together. The CC initiative is
fine, as long as we take the time to understand their (easy) licenses.I think a greater problem is that we tend to think of GPL and CC as being similar things, when in fact they are quite different.
But, I'm not so sure the CC is not an ideological movement. It's just that it's not as totalitarian as the FLOSS/GPL movement.
CC addresses the production of culture, the GPL address the production of code. They are two very different intentions, two very different "things".
And, despite being a FLOSS advocate and avid FLOSS programmer since
many years, I take particular offense to this article:http://www.metamute.org/?q=en/Freedoms-Standard-Advanced
Mako Hill only wishes to extend the naive tautology of the word
"freedom", and knock CC for not having an ideology that is as simple and total as
the GPL.
People talk of freedom and its hard to make concrete but there are
real, concrete effects. Lawrence Lessig is definitely a lawyer and
lawyers usually believe that the law works. But few lawyers realize
that the law is really, really expensive. Richard Stallman is a
hacker and was looking for something that actually works. Therefore
the GNU GPL uses the law get rid of as much of the law as possible.
For example, you put your song out with a Non-Commercial CC license,
then some big company uses it anyway. Are you going to pay 1-2
months of your salary to enforce the license and make that
corporation stop using your song? That's the reality. Here's an
example:
http://unraveled.com/archives/2004/05/enforcing_the_creative_commons
CC won't help you enforce your license:
http://creativecommons.org/ faq#Will_Creative_Commons_help_me_enforce_my_license?
The FSF regularly helps enforce against GNU GPL violations. The core
idea is that the GNU GPL allows you to share your code yet be
guaranteed to always have control over it, and to benefit from other
people's improvements to your code. The CC licenses have a bunch of
clauses that sound good, but unless you are going to fork over a lot
of money, they are not enforceable.
.hc
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner wrote:
For example, you put your song out with a Non-Commercial CC license, then some big company uses it anyway. Are you going to pay 1-2 months of your salary to enforce the license and make that corporation stop using your song? That's the reality. Here's an example:
http://unraveled.com/archives/2004/05/enforcing_the_creative_commons
CC won't help you enforce your license:
http://creativecommons.org/ faq#Will_Creative_Commons_help_me_enforce_my_license?
Just to add some meat to your post (even if I'm vegetarian), but what about those who resources hack an open source software like Audacity and sell it for a price?
http://www.marketworks.com/storefrontprofiles/DeluxeSFItemDetail.aspx?sid=1&...
And please, can somebody translate (from german) what this guy is selling on ebay at €5?
http://cgi.ebay.de/Download-over-1200-albums-FREE_W0QQitemZ100501905802QQcat...
:-)
c.
www.cesaremarilungo.com
Cesare Marilungo wrote:
Just to add some meat to your post (even if I'm vegetarian), but what about those who resources hack an open source software like Audacity and sell it for a price?
Far from a "hack", this is totally legal, as long as they follow the terms of the license. In the case of Audacity, you should be able to get the source code, plus any changes they have made in the source code, on request. One could also sell PD for money, as long as they include the copyright statement, as HC mentioned. I'm about to get involved in a similar issue, where a company is distributing an OSX port of the sound editor ReZound. The user community could benefit from seeing the changes they made to get it compiled. d.
derek holzer wrote:
Cesare Marilungo wrote:
Just to add some meat to your post (even if I'm vegetarian), but what about those who resources hack an open source software like Audacity and sell it for a price?
Far from a "hack", this is totally legal, as long as they follow the terms of the license. In the case of Audacity, you should be able to get the source code, plus any changes they have made in the source code, on request. One could also sell PD for money, as long as they include the copyright statement, as HC mentioned. I'm about to get involved in a similar issue, where a company is distributing an OSX port of the sound editor ReZound. The user community could benefit from seeing the changes they made to get it compiled. d.
I know that it's legal to sell GPL code. But there's no copyright statement on the page. Audacity isn't mentioned at all.
They're selling the binary (windows only) as if it was an original product.
OpenOSX is a different thing. More like a linux distro (with just the apps). Totally legal.
c.
www.cesaremarilungo.com
Le 16 Juin 2006 08:32, Cesare Marilungo a écrit :
OpenOSX is a different thing. More like a linux distro (with just the apps). Totally legal.
Legal but apparently not in good terms with the Fink project: http://fink.sourceforge.net/pr/openosx.php -- Marc
Marc Lavallée wrote:
Le 16 Juin 2006 08:32, Cesare Marilungo a écrit :
OpenOSX is a different thing. More like a linux distro (with just the apps). Totally legal.
Legal but apparently not in good terms with the Fink project: http://fink.sourceforge.net/pr/openosx.php -- Marc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
A lot of things, IMO, are legal but unjust. And viceversa.
I would really like to discuss this topics from the perspective of what is valuable for the so-called community, or for people in general.
c.
www.cesaremarilungo.com
Le 16 Juin 2006 05:48, derek holzer a écrit :
I'm about to get involved in a similar issue, where a company is distributing an OSX port of the sound editor ReZound. The user community could benefit from seeing the changes they made to get it compiled. d.
That would be great; ReZound is my favorite sound editor. If it works it would be nice that some code of money gets back to the original project for its development. -- Marc
Le 16 Juin 2006 06:28, Cesare Marilungo a écrit :
Just to add some meat to your post (even if I'm vegetarian), but what about those who resources hack an open source software like Audacity and sell it for a price?
http://www.marketworks.com/storefrontprofiles/DeluxeSFItemDetail.aspx?sid =1&sfid=77876&c=421871&i=10531671
If it's a hack, it's legal to sell it, but it's illegal to hide the source code. Maybe it's not a hack, maybe it's Audacity with a different name. You should write to the author of Audacity so they can check.
And please, can somebody translate (from german) what this guy is selling on ebay at €5?
http://cgi.ebay.de/Download-over-1200-albums-FREE_W0QQitemZ100501905802QQ categoryZ43613QQssPageNameZWD2VQQrdZ1QQcmdZViewItem
He's probably selling a registrastion to this (legal) commercial service: http://www.jamendo.com/
eBay is a junkyard, so just be careful...
Marc
-
august -
Cesare Marilungo -
Charles Henry -
Damian Stewart -
derek holzer -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
João Miguel Pais -
Marc Lavallée -
Mathieu Bouchard -
Roman Haefeli -
romana -
Thomas Grill -
Tim Blechmann -
yvan vander sanden