Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Plugin foo_dsp_src violates copyright (Read 69151 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Plugin foo_dsp_src violates copyright

Dear Sir/Madam,

I am the author and copyright owner of software known as "Secret Rabbit Code" which is released
under the terms of the GNU General Public License.

On Monday August 8th 2005, I was made aware of a web site:

    http://pelit.koillismaa.fi/plugins/dsp.php

which contains a php redirect link

    http://pelit.koillismaa.fi/plugins/redir.php?id=494

which redirects to :

    http://sbougribate.free.fr/Files/Foobar2000/foo_dsp_src.zip

which offers a binary derived from Secret Rabbit Code in direct violation of the GNU GPL [0].

I would like the people responsible for the above websites to do the following:

Free.fr (sbougribate.free.fr / Proxad.net):
    Please remove the offending binary immediately. If the person who posted the binary
    wishes to comply with the GNU GPL they can contact me at the email address listed
    on the Secret Rabbit Code web page.

koillismaa.fi:
    Please get the owner of the page:
        http://pelit.koillismaa.fi/plugins/dsp.php
    to remove the link to the binary as soons as possible and replace it with a statement that
    the link was removed because of copyright violation.

I look forward to your swift reponse to this copyright violation.

Regards,
Erik

Plugin foo_dsp_src violates copyright

Reply #1
Have you contacted the plugin author about source code availability?
KarLKoX at ifrance dot com / sbougribate at free dot fr

Plugin foo_dsp_src violates copyright

Reply #2
Quote
Have you contacted the plugin author about source code availability?
KarLKoX at ifrance dot com / sbougribate at free dot fr
[a href="index.php?act=findpost&pid=318771"][{POST_SNAPBACK}][/a]


The lack of source code is not the only problem.

GPL cannot be linked to closed source code. Is Foobar2000 released under a GPL
compatible license?

Plugin foo_dsp_src violates copyright

Reply #3
Quote
GPL cannot be linked to closed source code. Is Foobar2000 released under a GPL
compatible license?

I did not thought about that point.
In case of application plug-ins, I am not sure if this apply. The plug-in itself abviously falls under the GPL, but I am not sure about the application dynamically loading it. Is there a definitive and comprehensive answer about that?

Plugin foo_dsp_src violates copyright

Reply #4
Quote
Quote
GPL cannot be linked to closed source code. Is Foobar2000 released under a GPL
compatible license?

I did not thought about that point.
In case of application plug-ins, I am not sure if this apply. The plug-in itself abviously falls under the GPL, but I am not sure about the application dynamically loading it. Is there a definitive and comprehensive answer about that?
[{POST_SNAPBACK}][/a]

I don't know, but I remember that we discussed this point several times before on this board. Maybe [a href="http://www.wordiq.com/definition/GNU_General_Public_License#GPL-related_disputes]this part about GPL-related disputes[/url] contains some relevant information.
Over thinking, over analyzing separates the body from the mind.

Plugin foo_dsp_src violates copyright

Reply #5
Quote
Quote
GPL cannot be linked to closed source code. Is Foobar2000 released under a GPL
compatible license?

I did not thought about that point.
In case of application plug-ins, I am not sure if this apply. The plug-in itself abviously falls under the GPL, but I am not sure about the application dynamically loading it. Is there a definitive and comprehensive answer about that?
[a href="index.php?act=findpost&pid=318785"][{POST_SNAPBACK}][/a]


I dont' know about this too, i thaught it was just about not releasing the code (this is why i mailed it to you) ... the plugin is now removed from my server until a solution is found by Erik.

Plugin foo_dsp_src violates copyright

Reply #6
Quote
I don't know, but I remember that we discussed this point several times before on this board. Maybe this part about GPL-related disputes contains some relevant information.
[{POST_SNAPBACK}][/a]


The link does explicity states that this issue has not been tested in court  .

However, it does state that a number of companies release GPL licensed dynamic libraries
and have separate commercial licensing available for companies or individuals which want to
use the library but do not want to release their own source code.

Since a commercal use license is available for Secret Rabbit Code it should be pretty obvious
that I assert that dynamically linking to a GPL licensed library creates a derviative work of
of that library. I am in the process of updating the licensing web page:

    [a href="http://www.mega-nerd.com/SRC/license.html]http://www.mega-nerd.com/SRC/license.html[/url]

I will also be adding a notice to this effect under the GPL copyright notice.

In other news, KarlKox has contacted me and removed the binary from his web site. Thanks
Karl.

I am now looking into the possibility of making a Secret Rabbit Code based resampler available
for foobar2000 users while maitaining my ability to to dual license the code and earn an income
from it.

Plugin foo_dsp_src violates copyright

Reply #7
Weeeee. Somebody didn't do his licensing homework.

(not that I blame him, understanding the GPL is not for anyone...)

Plugin foo_dsp_src violates copyright

Reply #8
Quote
I am now looking into the possibility of making a Secret Rabbit Code based resampler available for foobar2000 users[a href="index.php?act=findpost&pid=318805"][{POST_SNAPBACK}][/a]


...or users could just use one of the several high-quality resamplers available for foobar developed by people that actually know how the GPL works and what are the limitations involved, hrmmmm?

Food for thought:
in_mad
in_mpp (back when Musepack decoder was GPLd)
SNESamp
bbMPEG.PRM
... and countless other plugins for Winamp/Foobar/Photoshop/Audition, not to mention VST plugins and DirectShow filters, based on GPLd code.

Plugin foo_dsp_src violates copyright

Reply #9
Quote
in_mad[a href="index.php?act=findpost&pid=323858"][{POST_SNAPBACK}][/a]

Modified libmad to support single-packet decoding, mailed a patch to the developers over a year ago, never got a response.

Quote
SNESamp[a href="index.php?act=findpost&pid=323858"][{POST_SNAPBACK}][/a]

The applicable GPL code is a self-contained DLL module, but I'm not sure about the necessary plug-in. I also ported it to 0.9, and updated my dll_manager for full multi-instance, but that was only for benchmarking purposes.

Quote
... and countless other plugins for Winamp/Foobar/Photoshop/Audition, not to mention VST plugins and DirectShow filters, based on GPLd code.[a href="index.php?act=findpost&pid=323858"][{POST_SNAPBACK}][/a]

And probably in most of those cases, the authors of the relevant GPL libraries or other projects were not trying to make money through dual licensing. The project I can think of where that was not the case was rOn's UADE component for Winamp3, and I already know very little of the history surrounding that debacle.

Plugin foo_dsp_src violates copyright

Reply #10
From FSF's Frequently Asked Questions about the GNU GPL:
Quote
Can I release a non-free program that's designed to load a GPL-covered plug-in?
    It depends on how the program invokes its plug-ins. 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 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, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins.

    If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.


Hope it helps.

Plugin foo_dsp_src violates copyright

Reply #11
Quote
From FSF's Frequently Asked Questions about the GNU GPL:
<...>
Hope it helps.
[a href="index.php?act=findpost&pid=336613"][{POST_SNAPBACK}][/a]


It doesn't.

First, because Peter is not releasing foobar to use SRC, but someone else released a plugin to be used in foobar. There's a cause and consequence difference there.

Second, because most often than not you can not trust the FAQs at FSF. They are permeated by their zealotry.



Let's imagine a situation here:

Somebody managed to reverse engineer the foobar2000 SDK and created another player that can use foobar2000's plugins (we all saw that happen before with Winamp). This somebody releases this player under the GPL.

So, now, it suddenly becomes legal to create and release a plugin that uses SRC? It'll obviously be perfectly fine to add a SRC plugin for this hypotetical player, being GPL and all.

So, it is legal to create and release plugins, but you are limited to where you can use your plugin? Hrm... the plot thickens.


The bottom line:

Wooohooo, here comes the clue train, last stop is Mr. Erik de Castro Lopo! SRC is not and did not link against foobar2000. It's linking against the foobar SDK. And the SDK is released under the BSD license - that is compatible with the GPL.
Neither is Peter releasing "a non-free program that's designed to load a GPL-covered plug-in". For that to be characterized, he would have to bundle the plugin with foobar - and he's smart enough and knowledgeable enough about licenses to know that is a no-no.

Hope that clarifies the situation.

Best regards;

Me.


Edit: typos

Plugin foo_dsp_src violates copyright

Reply #12
Quote from: rjamorim,Oct 23 2005, 09:03 AM


> First, because Peter is not releasing foobar to use SRC,

Who is Peter? I assume he is the author of FooBar. I have not made any claims
against FooBar. My claim was the the plugin which uses SRC and violated my
license.

> Second, because most often than not you can not trust the FAQs at FSF. They are permeated by
> their zealotry.

So according to you we should ignore the FSF's zealotry but listen to yours?

> Wooohooo, here comes the clue train, last stop is Mr. Erik de Castro Lopo!

That is somewhat inflamatory. I'll try to ignore it.

> SRC is not and did not link against foobar2000. It's linking against the foobar SDK. And the SDK is
> released under the BSD license - that is compatible with the GPL.

I repeat, my claim was against the plugin author not the foobar author. Secondly, my
complaint was that the plugin was released as a binary and that the source code was
not made available. Please explain to me how this was not a violation of the GPL.

In this plugin, SRC linked the the FooBar SDK which links to FooBar, therefore, when the
plugin is loaded by foobar, SRC links to FooBar. Once SRC links to Foobar my license
is being violated. It is being violated by the end user who under the GPL has rights to
do just about anything as long as they don't distribute it. However, even if the plugin author
released the source code, the sole purpose of this source would be to link my GPL code
to a binary only program. I think that you will find that this is somewhat shaky legal
ground.

Erik

Plugin foo_dsp_src violates copyright

Reply #13
Quote
> First, because Peter is not releasing foobar to use SRC,
Who is Peter? I assume he is the author of FooBar. I have not made any claims
against FooBar. My claim was the the plugin which uses SRC and violated my
license.


Calm down... that was just part of my argumentation...

Quote
> Second, because most often than not you can not trust the FAQs at FSF. They
> are permeated by their zealotry.

So according to you we should ignore the FSF's zealotry but listen to yours?


You should look for a less biased opinion. Be it mine or someone else, I don't care. But the FSF is definitely not unbiased.

Quote
> SRC is not and did not link against foobar2000. It's linking against the foobar SDK. And the SDK is
> released under the BSD license - that is compatible with the GPL.

I repeat, my claim was against the plugin author not the foobar author. Secondly, my
complaint was that the plugin was released as a binary and that the source code was
not made available.


Yes, that too. But you also claimed that your beloved code can't be linked against foobar's closed code. I quote:

Quote
GPL cannot be linked to closed source code. Is Foobar2000 released under a GPL
compatible license?


Quote
It is being violated by the end user who under the GPL has rights to
do just about anything as long as they don't distribute it.


Right! So you should go around screaming at users, and not at whoever is hosting your plugin at a site.

You WOULD have a point if you complained about lack of sources only. The point about the plugin not being allowed to be distributed because it MAY be linked to foobar is moot, for somewhat obvious reasons.


Quote
However, even if the plugin author
released the source code, the sole purpose of this source would be to link my GPL code
to a binary only program. I think that you will find that this is somewhat shaky legal
ground.[a href="index.php?act=findpost&pid=336685"][{POST_SNAPBACK}][/a]


Not really. Maybe someone would like to look into the sources to learn how to implement a resampler in the SDK? Or maybe use it as a base to reverse-engineer the SDK and come up with his own player?


Besides, the "might get linked against non-GPLd code" has never been tested to court. We know of countless cases even more grave that foobar's case. I already gave a few examples in a previous post. Here's another one:

Audacity uses your sampling rate converter. At the same time, the developers of audacity release a VST add-on that adds VST capabilities. The key point there is that the developers are releasing it, and announcing it at the official page. So, your code might eventually be linked against non-GPL code (Steinberg's SDK is incompatible to the GPL)! Egad!

People might even start using closed source VST plugins there! Double egad!

Why don't you go after Audacity then too? Either demand that they stop distributing the VST plugin altogether, or demand that they remove your code.

Plugin foo_dsp_src violates copyright

Reply #14
Quote
Calm down... that was just part of my argumentation...


I'll calm down if you stop being inflmatory.

Quote
You should look for a less biased opinion. Be it mine or someone else, I don't
care. But the FSF is definitely not unbiased.


Noone can correctly claim to be unbaised. The FSF may not have won many court
battles, but they haven't lost any either. The main reason for this is the infingers
back down rather than go to court. This history lends a lot of weight to the arguments
they put forth.

Quote
You WOULD have a point if you complained about lack of sources only. The point about the plugin not being allowed to be distributed because it MAY be linked to foobar is moot, for somewhat obvious reasons.


Really, care to explain why? Actually, don't bother.

Quote
Besides, the "might get linked against non-GPLd code" has never been tested to court. We know of countless cases even more grave that foobar's case.


If any of those cases involve SRC, you be sure to tell me what they are.

Quote
  I already gave a few examples in a previous post. Here's another one:

Audacity uses your sampling rate converter. At the same time, the developers of audacity release a VST add-on that adds VST capabilities. The key point there is that the developers are releasing it, and announcing it at the official page.


I have just been to:

    http://audacity.sourceforge.net/download/source

and downloaded audacity-src-1.2.3.tar.gz. It does not contain the SRC code, neither is SRC
listed as an optional component (same page).

Some time ago, the Audacity authors emailed me and asked me my thoughts on linking
SRC to an application which also linked in VST plugins at run time. I told them that I
would consider this an infringment of my license and asked them not to. They complied
and we are still on good terms. Dominic Mazzoni and Joshua Haberman have both
supplied suggestions for my other project libsndfile. Josh was actually the Debian
maintainer of libsndfile for a number of years.


Erik

Plugin foo_dsp_src violates copyright

Reply #15
Quote
Noone can correctly claim to be unbaised. The FSF may not have won many court
battles, but they haven't lost any either. The main reason for this is the infingers
back down rather than go to court. This history lends a lot of weight to the arguments they put forth.


infingers?

Anyway, the FSF is rabidly zealottish and anybody knows that. If you doubt, just look at any interview or article put forth by their benevolent-dictator-for-life. If you pride so much into believing their opinions, so be it, but don't come here expecting us to have them in similarly high regards.

Quote
Quote
You WOULD have a point if you complained about lack of sources only. The point about the plugin not being allowed to be distributed because it MAY be linked to foobar is moot, for somewhat obvious reasons.


Really, care to explain why? Actually, don't bother.


Don't bother why? Noticing your lack of argument?

But I'll explain, in hopes you'll understand. The plugin is there, sitting idly at a web site. Downloading it doesn't force anyone to use it with foobar. Therefore, it can't be illegal.

It's like outlawing guns because they MIGHT be used to commit a crime. (yes, my country is doing precisely that, but then again, my country is retarded)

Once again. Your code is linking against the BSDish foobar SDK. Not foobar. The plugin itself is clean. Period. The plugin itself, when used with foobar, might or might not be clean (I would suspect it's not clean, but it's open to interpretation, since it's something you do individually)

The bottom line, as I see it: Distributing SRC with foobar is wrong. Distributing the plugin alone and then adding it to foobar might or might not be wrong. Only distributing the plugin is clean.

Quote
If any of those cases involve SRC, you be sure to tell me what they are.


Fortunately, these other cases involve code created by people with at least a minimal understanding of what the GPL means.

Quote
Some time ago, the Audacity authors emailed me and asked me my thoughts on linking
SRC to an application which also linked in VST plugins at run time. I told them that I
would consider this an infringment of my license and asked them not to. [a href="index.php?act=findpost&pid=336765"][{POST_SNAPBACK}][/a]


Yeah, I shouldn't have hoped for the Audacity authors to understand the GPL. Oh well. A pity.

Regards;

Roberto.

Plugin foo_dsp_src violates copyright

Reply #16
Quote
Some time ago, the Audacity authors emailed me and asked me my thoughts on linking
SRC to an application which also linked in VST plugins at run time. I told them that I
would consider this an infringment of my license and asked them not to.[{POST_SNAPBACK}][/a]

So you're saying it's wrong for GPL code to link in closed source software. Find your own open source solutions, or GTFO?

While we're on that subject, we should not be linking our GPL code to the closed source Windows system modules, which are required to interoperate with the system in the first place. So, let's all use a [a href="http://www.linux.org]Free Operating System[/url].

But wait, we're still running at the mercy of a closed source BIOS! So, let's all equip our systems with a Free BIOS!

Let's not stop there, though! We also need to free ourselves from the clutches of closed source processor microcode! And why stop there? We need a Free Processor Architecture as well, where anyone can download the schematic to the processor and fabricate their own silicon wafers! Or, lacking microchip fabrication equipment, assemble manually using 10 million transistors, resistors, capacitors, and other miscellaneous parts, available direct from the FSF in a convenient solder-together kit! Just $29,999.99!! We'll be reverting to the days of building-sized big iron computers, but we'll be Free!

I can see it now, RMS dancing madly and singing the FSF theme song. C'mon everybody, let's all praise communism!

Plugin foo_dsp_src violates copyright

Reply #17
Now that I think about it, I should urge John33 to remove SRCdrop from RareWares. It's GPLd, but he compiled it with Visual C, therefore it must be using Microsoft's filthy and corrupt (that is, closed source) C runtime libraries.


Edit: now that I think about it, how come the author provides makefiles to evil MSVC? Isn't that like sleeping with the enemy? That will not do! Stallman will frown upon you, sonny.


Plugin foo_dsp_src violates copyright

Reply #19
Quote
Um, you're taking this too far. the GPL specifically allows linking with core operating system interfaces, AFAIK.[a href="index.php?act=findpost&pid=336961"][{POST_SNAPBACK}][/a]


I'll give you a cookie if you give me a good (legal-worthy) definition of "core operating system interfaces". Where do you draw the line?

BTW, the precise wording is:

"However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable."

Notice they are talking about "major components of the operating system", and then they throw around some examples. Are these examples exhaustive? What does "and so on" precisely mean? Hell if I know!

Now, let me emphasize a particular sentence:

"unless that component itself accompanies the executable"

Well, well, the MSVC/ICL/BCC runtimes accompany the executable when you create a static binary. Solve that for me, Dr Watson!

Plugin foo_dsp_src violates copyright

Reply #20
I know that licences and laws aren't about it, but i always feel the need to p*** when people begin to argue the wording of rules, instead of their meaning and intention. I despise it because in those cases the rules end up being abused and twisted.

In this case (IMHO) the GPL's main purpose is to stop others from abusing the free availability of GPLed code("stealing" without giving back) as well as to ensure that anyone can see and modify the source at will. So to make it simple: to stop abuse.

Almost all of foobar which matters for endusers is moved into plugins. Heck, even the UI is a plugin. And all those plugins are BSDed. The only reason why the CORE itself is not opensourced is because the author wants to keep control on the development of the application(i.e. discouraging forks, etc.) and possibly(though, i dont know this - its just speculation) because he doesn't trust opensource 100% (cases where opensourced code is stoeled and then sold, etc. happen daily).

Thus, all "components" of foobar which are mainly interesting to the enduser are opensourced - its just that the author wants to keep in control of the project overally. This is not unfounded paranoia - attempts to abuse the project as a whole already happened.

Thus, we have a player which overally plays the opensource game(almost everything is opensourced) and a component which uses opensource. In terms of intention and practice, i dont understand the reason for all this hairsplitting. The only flaw i notice is the lack of available source for the plugin in question. But concerning foobar itself, i think the author of the SRC code is currently practicing "friendly-fire".
I am arrogant and I can afford it because I deliver.


Plugin foo_dsp_src violates copyright

Reply #22
Quote
But concerning foobar itself, i think the author of the SRC code is currently practicing "friendly-fire".[a href="index.php?act=findpost&pid=336998"][{POST_SNAPBACK}][/a]


Very good point.

Quote
rjamorim, aren't you verging way off-topic here?[a href="index.php?act=findpost&pid=336999"][{POST_SNAPBACK}][/a]


Why? Aren't we discussing licensing from the very first post? How more on-topic can you be that trying to clarify obscure clauses in the GPL?

Plugin foo_dsp_src violates copyright

Reply #23
Quote
But I'll explain, in hopes you'll understand. The plugin is there, sitting idly at a web site. Downloading it doesn't force anyone to use it with foobar. Therefore, it can't be illegal.

It's like outlawing guns because they MIGHT be used to commit a crime. (yes, my country is doing precisely that, but then again, my country is retarded)

Once again. Your code is linking against the BSDish foobar SDK. Not foobar. The plugin itself is clean. Period. The plugin itself, when used with foobar, might or might not be clean (I would suspect it's not clean, but it's open to interpretation, since it's something you do individually)

The bottom line, as I see it: Distributing SRC with foobar is wrong. Distributing the plugin alone and then adding it to foobar might or might not be wrong. Only distributing the plugin is clean.
[a href="index.php?act=findpost&pid=336787"][{POST_SNAPBACK}][/a]

I got bored the other day and sent off an email to the FSF to see what their take on it was. I got an answer back about an hour ago.

Note that I intentionally made the scenario I asked about a bit generic, so I'll post my email and their response. I don't know if the scenario I wrote wholly fits, but it's how I understand it anyway.

I wrote:
> 1. Person X writes a closed source program. It's available to anybody,
> free as in beer. This program can load plugins.
>
> 2. Person X then writes an SDK for this closed source program. X makes
> this available to everybody under a modified BSD license (which is GPL
> compatible). Compiling a plugin for the closed source program now
> requires nothing but this SDK. No binaries from the closed source
> program are involved to compile (the program dynamically loads the DLL
> at runtime, basically).
>
> 3. Person Y comes along, combines part of this SDK with a GPL'd
> library (which is written by Person Z). He releases this plugin, along
> with the source.
>
> 4. The plugin and the original program are at no time combined
> together into a single distribution, installer, anything like that.
> They aren't even downloaded from the same website. The end user has to
> combine them together himself. Which many do, in fact.
>
> Is there anything wrong with this picture?

Response:

I assume that the plugin interacts deeply with the internals of the main
program. In this scenario, person Y has violated the GNU GPL. The GPL
doesn't concern itself with technical details about how two programs are
combined; so the fact that person Y didn't need to link any
GPL-incompatible code directly to the GPLed library is irrelevant. The
GPL only cares about whether a given work is based on GPLed code. If it
is, then the final, combined work must all be licensed under the terms
of the GPL. Person Y has failed to follow this requirement.

<http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF> explains why,
in general, you can't write plugins for proprietary programs with GPLed
code without some sort of special exception.

I hope this clarifies the situation. If you have more specific questions,
please feel free to contact us.

Best regards,
--
Brett Smith
Free Software Foundation Licensing Team

Plugin foo_dsp_src violates copyright

Reply #24
Quote
> 3. Person Y comes along, combines part of this SDK with a GPL'd library (which is written by Person Z). He releases this plugin, along with the source.


Just a small clarification (not that it matters to the current subject): The source wasn't available.

Quote
I assume that the plugin interacts deeply with the internals of the main program.


That is something that needs to be clarified. What is a "deep" interection, and what is a shallow one?

Quote
In this scenario, person Y has violated the GNU GPL. The GPL
doesn't concern itself with technical details about how two programs are
combined; so the fact that person Y didn't need to link any
GPL-incompatible code directly to the GPLed library is irrelevant. The
GPL only cares about whether a given work is based on GPLed code. If it
is, then the final, combined work must all be licensed under the terms
of the GPL. Person Y has failed to follow this requirement.


I disagree, for the reason I stated before: you can't know how the person obtaining that plugin will use it. he might use it with foobar - and in that case he'll be probably breaking the GPL (as I stated before) - but he might as well use it to study how the SDK works. In that case he would be completely on the clean.

The point is, there's no way for the plugin author to know how his creation will be used. It's like the old analogy of blaming Col. Colt for a murder that was carried using one of the guns he made.

The most the developer could do is warning people they shouldn't use the plugin with foobar as it would probably be illegal. But that's pretty much it.


But I agree with others, this thread is losing its usefulness. We already discussed to death every party's point of view on the situation, and fact is, there are similarly good resamplers available for foobar2000 that were developed by less anal people. So why waste so much energy on a non-issue?

Thanks for contacting the FSF BTW. Knowing their PoV on the matter is interesting.

Regards;

Roberto.