On Monday 03 August 2009 16:45:23 Julien Claassen wrote: FSF cannot really do anything unless the copyright is theirs (they even encourage free software creators to transfer it to them so they can pursue these cases.). Only the copyright holder has the power to do anything really. Try http://www.softwarefreedom.org/ and http://gpl-violations.org. Raymond

On 4 Aug 2009, at 01:21, Erik de Castro Lopo wrote: Agreed. If someone wants to draft such an email, I'll put my name to it. As someone who's copyright is being infringed. - Steve

On Tue, Aug 04, 2009 at 08:33:22AM +0100, Nick Bailey wrote: Two question arise: - Is a program that loads LADSPA plugins (at run time) a 'derived work' ? Note that anyone can create a 'clean' version of ladpsa.h, as some people did with the VST headers. - If an installer (run on the end user's machine) fetches the plugins from their official site, would this be 'distribution' ? My first guess would be no, no. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga.

On Tue, Aug 4, 2009 at 3:45 PM, Dr Nicholas J Bailey<n.j.bailey(a)elec.gla.ac.uk> wrote: "Derived work" in the context of the GPL is entirely a question of copyright. If two works have been produced completely independently -- for example if their authors produced them without being aware of one another's existence at all -- then I don't think there could be any basis for considering either of them a derived work of the other. This could routinely be the case for a LADSPA plugin and host, for example. If your interpretation was correct, then I could require Cubase to be GPL'd by writing a VST plugin for it and publishing it under the GPL. This would obviously be absurd. In real life, a court faced with a problem like this would surely have to consider the circumstances of authorship: is it actually reasonable to describe program A as being derived from program B, to the extent that the terms of program B's license must be considered when redistributing program A? That consideration would surely vary hugely from case to case. Chris

On Tue, Aug 4, 2009 at 4:08 PM, Gabriel M. Beddingfield<gabriel(a)teuton.org> wrote: My _user_? That can't be the case, the GPL only covers distribution. Nick's interpretation was "same memory space => derived work", implying that a host that loads a GPL'd plugin is a derived work of that plugin, ergo Cubase is a derived work of my VST plugin -- which is obviously absurd. Chris

On Tue, 2009-08-04 at 10:42 -0500, Gabriel M. Beddingfield wrote: As far as I understand it, the action of linking is not a violation. Distributing the "linkage" might be a violation depending on the license used. For example: I can modify a piece of GPL'd code to my hearts content, link it to my proprietary code, use it for years, all without violating the GPL. A violation would be if I distribute the combination as proprietary (non GPL) software. Comments? Sampo

On Tue, 2009-08-04 at 21:46 +0200, Arnold Krille wrote: There's also another aspect. Company A might sell a GPL license for their software X to company B. They might want to do this as X uses or is based on GPL'd code. This means X needs to be licensed under the GPL. A is not obliged to distribute X to anyone but B and B might not want to redistribute X. B is naturally entitled to the source code of X as per GPL. I'm expecting this happens all the time. This should happen when B orders a bespoke software from A and A happens to use GPL software in the product. As far as I understand the GPL, it does not obligate A or B to release X to anyone else. Sampo

On Tuesday 04 August 2009 16:16:11 Chris Cannam wrote: You don't need that understanding. You just need it to be in B's interest for it to go no further. Say it gives them an advantage... Note: You can sell a copy of code with a GPL license. Selling a GPL license would be something different than what is being discussed I think. drew

Hi, On Tuesday 04 August 2009 22:11:40 you wrote: Actually you can. If you have to copyright, you can re-license your works as you like. Only you cannot really un-GPL your code after publishing it, you can only un-GPL future versions. Unless of course you signed a contract with anyone that gives him an exclusive license. Which is the default with most/all work-contracts as I pointed out earlier... And maybe they think that Qt is actually pretty good so you can pay them. And maybe for real programming business the development-only phase is so short (because of the good Qt-API and documentation) that its not that much money to pay for the back-dated license. ;-) Arnold

Arnold Krille wrote: You can skip 1., 2.1 and 2.2 and directly read 3. ;). 1. If somebody has got a website made with Drupal (GPL) and he wants visitors of the side to install the proprietary flash player to use the web site, this won't be a problem. But will it be a violation, if somebody publishes a web site done with GPL software and proprietary software? Doing this isn't a distribution of the software. Doing this has nothing to do with with reprogramming the software, but even if somebody publishes a website done with reprogrammed GPL software, it's not publishing the reprogrammed software. GPL has nothing to do with just using software. 2.1 I download your GPL software and only change the copyright, I claim that I'm the original coder and in addition I add comments that you are liar, you have stolen my software. I copy this software with the faked copyright to 100 DVDs, but I keep this copies my own. This isn't a violation of the GPL. 2.2 I take those copies with me, while I'm using the short distance public transport and I forget them in a bus, without purpose, some people take a copy and install it to their desktop computers. This might be a violation, but the whole situation is grotesquely. 3. E.g. Cinelerra I guess this is software that links to Non-GPL software. "64 Studio cannot include it as part of the distribution because it has too many patent encumbered dependencies. But not to worry, if you install it yourself from other sources it is yours to use as you please! And this is that story..." (http://www.64studio.com/howto_cinelerra) From the file COPYING by "git clone git://git.cinelerra.org/j6t/cinelerra.git my_cinelerra": "GNU GENERAL PUBLIC LICENSE Version 2, June 1991" From the file LICENSE by "git clone git://git.cinelerra.org/j6t/cinelerra.git my_cinelerra": "In addition to the GPL's warranty stipulation, Cinelerra is distributed WITHOUT GUARANTEED SUPPORT; without even the guarantee of ADDITIONAL LABOR. Support that is not guaranteed includes technical support, compiler troubleshooting, debugging, version matching, updating, among other additional labor which may or may not be required to meet a user's requirements. GNU GENERAL PUBLIC LICENSE Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."

Gabriel M. Beddingfield wrote: How can a user comply with the GPL or violate the GPL? A user is just using applications.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 04, 2009 at 03:45:13PM +0100, Dr Nicholas J Bailey wrote: i guess your understanding is correct. in a past thread (feb. 2004) on the piksel list regarding licensing of video plugins, i've asked the FSF regarding this issue and got this reply: "Legally speaking, there's never been a case which discussed this. FSF believes that dlopen operates the same way as compile-time linking." Dave Turner GPL Compliance Engineer ciao - -- jaromil, dyne.org developer, http://jaromil.dyne.org GPG: 779F E8B5 47C7 3A89 4112 64D0 7B64 3184 B534 0B5E

On Tue, 2009-08-04 at 10:10 +0200, Fons Adriaensen wrote: GPL crosses the plugin barrier if they live in the same address space and call each other / share data, etc: http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF However, you can add a license restriction to avoid this for a particular interface (e.g. the LADSPA API): http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface Either way, the user can't "violate the GPL" just by loading a plugin (since the GPL is a copyright license). Distributing such a combination in any way would, though. Cheers, -dr

On Tue, 4 Aug 2009, Chris Cannam wrote: Yes, I think that it is widely accepted that this is a _really_ murky area. :-) In the case of *users*... I stand corrected. Sorry for the noise. (Ralf: thanks for the challenge.) WRT the OP, here's a couple of more relevent sections from the GPL FAQ... and even concedes the "murky" part.... http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem -and- http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper In the case of the OP, the problem is that they were distributed together... as a whole. They at least have to honor the GPL requirements for distributing the plugin binaries. As for GPL-tainting the whole program, it has to be determined if they are interfaced "at arm's length." <opinionating_the_murk> Since we all know that LADSPA is a protocal that causes dynamic linking to object code, it seems clear that this is *not* at arms length. But, I can see room for argument that LADSPA is an intermediate protocol (like text-based I/O, TCP/IP communication, morse code)... and that this makes it arms length. So, I'm now back where we started. :-P </opinionating_the_murk> Peace, Gabriel

Hallo, Steve Harris hat gesagt: // Steve Harris wrote: Are they? See below. According to the slightly skewed view of the FSF, even the former could be a violation: 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. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program. Quotint the GPL-FAQ. However applied to LADSPA this would mean, that GPL-plug-ins are not allowed in commercial software *at all*, and this would also be the case for e.g. Renoise, even when it doesn't ship the plugins, but uses the system-wide installed plugins. So if Beat Kangzs isn't allowed to load swh-plugins, then Renoise wouldn't be allowed neither, as far as I understand it. And Renoise does load them, I just checked. So we'd have another violation alert for Renoise. Happy hunting. :) Ciao -- Frank

Quoting "Steve Harris" &lt;steve(a)plugin.org.uk&gt;uk>: Hi, I wonder if we have received the same email? The email I got did not mention any specific license or even a type of license they would like. At least I don't think they were asking for the plugins under a non-GPL license. To me it sounded like they were making a proposal on how to become compliant with GPL. GPL + plugins seems to be a really iffy combination. I myself find the plugin interface separating the host from the plugins sufficient. The linkage happens when the user acts to load the plugin. This runtime linkage is never distributed, distribution being where GPL viral clauses would kick in. An hard-wired piece of software like Jamin on the other hand would be more tricky. In such a case it might be necessary for the proprietary host to be separately distributed from the plugins. Might. Who knows? This discussion does raise a good question about which license LADSPA and LV2 plugins should use. GPL might just be too viral and too restrictive. I'm too much of a pragmatic to consider the amount of packages being delivered to be that relevant. It's like saying you can deliver weapons to embargoed countries as long as you keep the ammunition and hardware in different shipments. By that slightly limping analog I'm trying to say that they can distribute the plugins with their program and still be compatible in what I see as fair use of my open source. As long as they clearly point this out and release any modifications they do to the GPL'd code, naturally. In fact, I just scoured the .jars of a fairly popular proprietary Java application server and I found at least one piece of GPL licensed software in there. The company who makes this server is very open source friendly: they have released a lot of their code as open source projects and they are very active in developing these and other free software projects. They feel comfortable enough distributing GPL'd code within their proprietary server, and I'm pretty sure they have asked their lawyers. The company is/was BEA Systems. These licenses are soooo tricky. No wonder so many people release their free software "free of charge" and without a license in sight :) Sampo

Sampo Savolainen wrote: This is wise :) for proprietary host software that isn't just a robbery of FLOSS software. People will learn, that the plugins are FLOSS and that there also might be host software that is FLOSS ;). Proprietary software companies might learn, that they should keep their software FLOSS too and instead make money by services, special OEM packages etc..

On Wed, 2009-08-05 at 10:02 +0100, Steve Harris wrote: I don't think they're in violation just by including the plugins with their proprietary application. I think that would most likely come under the "aggregate" concept in the GPL, which was included to support GNU/Linux distributions: "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." I think it could reasonably be argued that an automatic installer of both the (separate) proprietary application and the plugins would constitute an "aggregate" rather than a "derived work". I think really, Beat Kangz just need to fall into line with the normal obligations of a distributor; including a notice about the GPLd software, an offer to provide the source code, etc. I'd note that this would just be limited to the aggregate (ie, the installer) as well. -- Bob Ham &lt;rah(a)bash.sh&gt; for (;;) { ++pancakes; }

On Tue, Aug 4, 2009 at 11:37 AM, David Robillard&lt;dave(a)drobilla.net&gt; wrote: The FSF writes there: "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. " Unfortunately, this merely continues the gray area. * LADSPA does not define any mechanism for the plugin make function calls back to the host * Dynamic linking in almost all FSF writing seems to refer to something that is contrasted with static linking. This does not usefully or meaningfully describe the use of dl_open(). * The FSF is on crack if they believe that you can possibly call a LADSPA host a derivative work of any number of LADSPA plugins unless the host automatically loads and uses those plugins to provide non-optional functionality to the user. I am still deeply disappointed that this issue, which has been around for more than a decade, was not resolved in GPL v3. Its absurd that we should still be debating this in 2009. The FSF needs to: (1) describe the differences between static linkage, dynamic linkage and run-time linkage (2) cover the case where the "controlled interface" between run-time linked code and the host is an API that is implemented by several different applications, released under different licenses. With their loosely worded claims, a plugin using the API is a derivative of several different independent works. To claim that a VST plugin is a derivative work of both Ardour, Cubase and Reaper is clearly absurd. To claim that distributing said plugin with any of the said hosts forms a single work is almost as absurd. Their existing proposed "interface exception" is clearly written to cover dynamic linkage. It also contains an assertion that is nothing but an assertion at this time when applied to run time linkage: "Linking ABC statically or dynamically with other modules is making a combined work based on ABC" FSF: define the lines! Its 2009, not 1989.... --p

On Tuesday 04 August 2009 09:33:22 Nick Bailey wrote: Please be aware that (last time I checked) the gpl doesn't talk about giving access to all gpl-code you use. Only if you change something you have to make your changes available for free. So if they just use the plugins without any modification, they don't actually have to provide source codes. They just need to mention that they provide plugins that are gpl. I don't even think that using gpl-ladspa-plugins makes their software gpl because the linking happens at run-time (if at all). And if the plugins are lgpl they can even link their closed-source stuff to them. But here people with more knowledge should chime in. Arnold

On Tue, Aug 4, 2009 at 9:43 AM, Frank Barknecht&lt;fbar(a)footils.org&gt; wrote: Arnold's explanation is approximately true of the LGPL rather than the GPL, so perhaps that's the confusion here. The LADSPA header is indeed under the LGPL, but the plugins in question are generally under the GPL -- so terms and conditions of our normal flamefests apply. (Probably best not to get sidetracked by the LGPL if we can help it, considering how much time has been spent arguing about the much simpler GPL lately...) Chris

On 4 Aug 2009, at 10:21, Chris Cannam wrote: I'm a but rusty on these issues, but my reading of the GPLv2 (many years ago now) was that LADSPA plugins in it do not "infect" the host with their licence. There used to be a clear distinction between runtime linking, and loadtime linking. - Steve

On Tue, Aug 4, 2009 at 1:19 PM, Steve Harris&lt;steve(a)plugin.org.uk&gt; wrote: You are, but dynamic linkage with the GPL is a complete minefield as well, because it really hinges on what might be considered a derived work in copyright terms rather than on the content of the GPL. (The FSF has a position that I think is a convenient oversimplification, which is that any dynamic loading forms a derived work. Others disagree -- Linus for example with his binary kernel modules. The GPL does contain a line about applicability "when you distribute the same sections as part of a whole which is a work based on the Program", but it basically seems to be the license ruling itself on whether it applies or not, and I don't think it's the only possible authority for that -- if there is no derived work in pure copyright terms, then it doesn't make any difference what the GPL says about derived works.) Chris

Hallo, Forest Bond hat gesagt: // Forest Bond wrote: I don't think it's sufficient. http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary says: I downloaded just the binary from the net. If I distribute copies, do I have to get the source and distribute that too? Yes. The general rule is, if you distribute binaries, you must distribute the complete corresponding source code too. The exception for the case where you received a written offer for source code is quite limited. So *you* have to distribute the source code just as you distribute the binary. This is also in your own interest, because if the original site goes offline, you are still required to give people source code. Ciao -- Frank

On Tue, Aug 4, 2009 at 2:29 PM, Forest Bond&lt;forest(a)alittletooquiet.net&gt; wrote: No. You can offer to provide the code only on request (section 3b), but it has to be you who provides it. The closest thing to an exception for this is section 3c which allows non-commercial distributors to pass on the offer their received for source if they received the code under 3b (the only place where GPLv2 distinguishes between commercial and non-commercial distribution). But most free software is initially distributed under 3a rather than 3b, and that's what your question seems to imply as well. This requirement is sometimes overlooked with unfortunate consequences (c.f. the MEPIS distribution furore of a couple of years ago). Note: assuming GPLv2 here. Chris