adjusting sound levels for all .wav files

OK, it’s working with the static build.

I was a bit surprised to see a license notification saying some rights reserved in what I thought was GPL software.
I see now that the VST plug-in is licensed under MIT/X11 License.
What rights are reserved?
Is it OK to mix and match licenses like this? I’m not a lawyer and no expert in this type of thing, but I would have thought that there would be incompatibility between the GPL license of the original code and a more restrictive license for the VST version, assuming that the VST version is derived from the original command line version. :confused:

It does not seem to be audible with real-world audio, but this image is a generated “440 Hz sine tone. 30 seconds duration, amplitude 0.8” to which I have applied the VST version with the default settings. Zooming in shows small, but clearly visible 500 ms “steps” as the amplitude is ramped up.

MIT is compatible with GPL. This allows MIT to be combined with GPL, so I think it is quite in order to present the VST plug-in licence as under overall GPL. MIT License - Wikipedia .

I’m less clear about the “some rights reserved” inserted into these licences.


Gale



The question whether software licenses are “compatible” arises when you take somebody else’s code and create a derivative work from it. This is not the case here, so this question is actually irrelevant.

More specifically, the original author of a software, who obvisouly owns all rights on his or her own code, can decide to release his or her own work under whatever license he or she deems suitable. This could be one of the “standard” OpenSource licenses, it could be a custom-made OpenSource license or it may be a proprietary commercial license. And of course the original author is free to put some parts of his own work under one license and other parts of his own work under another license. Heck, the original author is even free to release his own software under two (or more) different and incompatible licenses! Many projects, like Qt Framework or x264, use a “dual license” model: They release their code under the (L)GPL and, at the same time, under a proprietary/commercial license - so every user can choose the license that covers his uses cases.

Having said that, there is absolutely nothing in the GPL that would prevent GPL’ed code to be combined with code that is released under the MIT license. Neither does the MIT license prevent code that was released under MIT license to be combined with GPL’ed code. However, it should be clear that any derivative work that contains some (L)GPL’ed code has to be released under the (L)GPL again - unless the original author explicitly agrees to the license change.

If the author of a software decides to share his code under the GPL or LGPL, this doesn’t change anything about the fact that he or she still owns all rights on the code.

With the GPL or LGPL, the author allows everybody to use, modify and redistribute the software without the need for any additional permission, as long as the restrictions and obligations that are imposed by the GPL/LGPL are respected. However, if anybody wants to do something with code that the GPL/LGPL does not explicitly allow, he or she still must ask the original author (copyright holder) for permission!

If the original author gave up his rights on the software by releasing his software under the GPL/LGPL, which of course is not the case, then any license terms would by completely pointless. That’s because, if the original author gave up his rights on the software, then who would own those rights instead? And who would demand that the license terms are respected, even if in court? Nobody? So if nobody could actually enforce the license, what would it be worth?

Yes, nothing :wink:

BTW: You will often find the line “All rights reserved” in copyright notices. That’s because this line was required in copyright notices in the past. Without that line it was not possible (or at least more difficult) to enforce the author’s rights, e.g. to sue somebody who violates the license terms. Today, as far as I know, this line is no longer necessary, in most countries. Anyhow, I tend to keep the variant “Some rights reserved” to make clear that this software is OpenSource but not “public domain” (that is: it’s “free software” but that does not mean you do whatever you want with it). The restrictions and obligations of the respective software license, e.g. GPL or LPGL, apply.

All rights that are not explicitly granted to everybody by the (L)GPL are reserved. And even those rights that are granted, are only granted if you agree to the (L)GPL - which comes with certain restrictions and obligations.

And the most important restriction/obligation of the GPL is: If you incorporate some GPL’ed code into your own project, then your own project becomes a derivate work and thus it must be shared under the conditions of the GPL too.

The LGPL says pretty much the same, except that linking your program against an LGPL’ed library does no make your project a derivate work. With the GPL, your project would be considered a derivate work, in that case.

Thanks for the explanation Gunnar. My questions were not meant as an attack - I was asking because I was unclear what was meant.
I’m still not sure that I’m 100% clear about the “some rights reserved” (I’ve not seen that added to a GPL license before). Are you saying that some rights are reserved, as described by the respective GPL/LGPL/MIT license terms, but no additional restrictions? Clarity on this point may be important if we want to list your plug-in in any of the official documentation.

Well, if the original author of the software decided to released his software under the (L)GPL, then you can use it exactly as describes in the (L)GPL license terms, without the need for further permission by the author.

But still you are not allowed to do anything with the software that the (L)GPL doesn’t allow explicitly. If you want to do something that goes beyond the permission given by the (L)GPL - for example, incorporate the code into your ClosedSource commercial product that you are going to keep ClosedSource - then you still have to ask the author for permission. And he or she may deny it, or ask for money :wink:

If the original author didn’t reserve at last some rights, then the software would effectively become “public domain”. And then some company could come along and incorporate that software into their commercial products without ever telling anybody or without ever giving back anything. And that even would be perfectly legal, since the code is “public domain”. Thus, if you wish that the (L)GPL applies to your work, you have to reserve some rights…

Agreed, so I’m unclear why you have an additional clause saying that some rights are reserved.

The (L)GPL states what is allowed and what is not. Both specifically allow use in commercial products, provided that it remains under the original license terms. If you wish to prohibit that, then I don’t see how you can describe it as (L)GPL because your license terms prohibit use that is explicitly granted by the (L)GPL license.
(Ref. GPL FAQ: Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation)

Yes, the GPL explicitly allows commercial use of the software. But it does not allow incorporating the GPL’ed code into (commercial) ClosedSource applications.

That means, if a company use the GPL’ed software, as-is, for commercial purposes, that is perfectly fine. That’s because the GPL’ed software may be used for free and for all purposes. Even if they deliver the GPL’ed software, as-is, along with their commercial products, that is still perfectly fine. That’s because the GPL’ed software may be redistributed freely (though sources must be provided along with the binaries).

But: As soon as they take the GPL’ed code (or parts of it) and incorporate it into their own software, they create a “derivate work” and thus they must release their software under the GPL too - if the intend to distribute it. That means the company would have to make their own source codes public, if they want to include any GPL’ed code - which of course is not an option for most commercial software products :wink:

Sure, and I think that is all covered in the GPL wording and documentation.

The aspect that I’m asking for clarification about is: Does your software have license restrictions that go beyond (ie more restrictive than) the respective LGPL/GPL/MIT licenses or is your software under standard LGPL/GPL/MIT licenses?

Nope. The README file clearly states which parts of the software are released under which license. The source/header files contain corresponding notices. And therefore you can use the software according to the respective license. It’s as simple as that. I don’t know how this could be made any clearer. There are no “secret” additional restrictions. Such restrictions would be void anyway, if they are mentioned nowhere in the license terms, right? :wink:

As said before, once the original author has decided to released his software under the GPL, you can use that software according to the license terms of the GPL. Now and for all future! Sure, the original author (copyright holder) can decide that future versions will no longer be released under the GPL. But even in that case, you could continue using the “old” version (the one that had been released under the GPL) as long as you wish, according to the GPL license terms. Finally, if the original author wanted to apply additional restrictions to his software, restrictions that go beyond the “official” GPL, he/she would have to write down those additional restrictions into the license! That would no longer be the “official” GPL though, but some custom-made license (based on the GPL). That’s is perfectly possible, of course. But it doesn’t apply here. Sneaking in additional restrictions retroactively isn’t possible either.

The only thing that made it unclear for me was your additional license text (in addition to the standard license text) that appeared when I first loaded the VST version in Audacity, stating “some rights reserved”.

I was able to reproduce this behavior. I think I have tracked down what caused this and a fix is on the way…

I think everything about that has been said:



The Gaussian kernel is applied on the “per frame” gain factors, so that the gain factors of neighboring frames will be smoothed. However, since each frame will still get its own separate gain factor, we can not (or better: should not) simply apply a frame’s gain factor to all samples inside that frame - that would result in an ugly discontinuity at the frame boundary! Consequently, the “per sample” gain factors inside of each frame will be interpolated, from the previous frame’s gain factor to the current frame’s gain factor, so that we get a steady transition rather than “jumps” at the frame boundary. It was a small bug in that interpolation code which caused that “steppy response” you were seeing :blush:

Please try with the new version here:

Then IMO you don’t need extra words in the licence. It’s already implicit in the licence that you retain all copyright.

QT look as if they have separate versions of the software under different licences. If so they are not mixing and matching licences for the same version.

You can incorporate GPL code in a commercial closed source product without licensing the commercial product under GPL. For example it can be done by loading the open source code as a plug-in within the commercial product.


Gale

As mentioned before, the line may not be absolutely required nowadays in most countries, but it doesn’t hurt either and makes things more clear (though that doesn’t seem to be the case here).

If the copyright holder of a software wants that his/her software can be used (only) under a specific license, e.g. the GPL or LGPL, the copyrights must necessarily remain at the copyright holder, so that the license can actually be enforced. Otherwise, if the copyright holder decides to give up his rights, the software becomes “public domain” and everybody can do whatever he or she wants with the software - regardless of any software license restrictions!

Nope. That is allowed with the LGPL, but not with the GPL.

If a proprietary ClosedSource application loads a DLL or ShareObject (at runtime) that was released under the LGPL (not GPL), then this is considered a “use of the work”, but not creating a “derivate work”. Thus, the code of the main application can remain under whatever proprietary license it was before, in this case. But with the GPL (not LGPL) it doesn’t matter whether you insert the code as “copy & paste”, link it as a “static” library or load it as a DLL/ShareObject at runtime - in any of these cases you are creating a “derivate work” and thus your own code must be distributed under the GPL too. I’m not a lawyer either, but that’s how the GPL and LGPL are commonly interpreted :nerd:

BTW: You can still ship a GPL’ed application along with a proprietary CloseSource one, as long as they remain two separate stand-alone programs. And as long as the sources for the GPL’ed application are made available.

Nope. Starting with Version 4.5 the Qt Framework uses a LGPL/Commercial dual license model. The Qt Framework is released under the LGPL and, at the same time, under some proprietary commercial license. The code is exactly the same with both licenses, though the “commercial” license may include access to some bonus tools that I’m not aware of (never used the “commercial” license, because I never needed it).

That is: As long as your application is OpenSource or as long as your ClosedSource application uses an unmodified Qt Framework as DLLs (SharedObjects), you can use Qt under the LGPL. If, however, you wish to link Qt statically into your ClosedSource application or if you modified the Qt Framework (and don’t want to publish your modifications), then you have to buy the commercial license.

At all times, Qt was available under a commercial license that allows developing proprietary applications with no restrictions on licensing. In addition, Qt has been gradually made available under several increasingly free licenses. […] Until version 1.45, source code for Qt was released under the FreeQt license. […] With the release of version 2.0 of the toolkit, the license was changed to the Q Public License (QPL). […] In 2000, Qt/X11 2.2 was released under the GPL v2 […] This was resolved when Trolltech released Qt/Windows 4 under the GPL in June 2005. Qt 4 now supports the same set of platforms in the free software/open source editions as in the proprietary edition, so it is now possible to create GPL-licensed free/open source applications using Qt on all supported platforms. […] On 14 January 2009, Qt version 4.5 added another option, the LGPL. - Wikipedia

BTW: The x264 project uses a very similar dual license model, though they use GPL and commercial, rather than LGPL and commercial.

Of course you are entitled to license your work under whatever license you want, but as feedback (not criticism) from the standpoint of a user, I think the additional text makes it less clear (otherwise I’d not have mentioned it in the first place :wink:.

In particular, the license agreement that comes up on first use of the VST effect says that it is licensed under LGPL v2.1 or later.
That would have been clear to me if it were not that you have added the additional text, which suggested to me that there may be additional restrictions, which is confirmed by the fact that if I don’t click the OK button to “agree”, then I can’t use the software, though LGPL v 2.1 does not require that the user accepts the terms in order to “use” the software. Section 9 of LGPL v2.1 makes it clear that acceptance of the license agreement is required “for copying, distributing or modifying the Library or works based on it” but places no such restriction on “using” the software. As this restriction on use is contrary to the freedom granted by the stated license, that would appear to invalidate the agreement. So no, I don’t think it is clear.

First of all, I don’t think the Copyright notice (may the “All rights reserved” line still be needed nowadays in your/my country or not) is not “contrary” to the license terms at all. Instead, it’s a necessary precondition for the license to be applied. If the original author didn’t retain the rights on his software, he or she wouldn’t be in the position to license the software to anybody - and thus any license terms would be void.

Secondly, the “license” dialog box is more of an informational nature. It informs the user which license applies to the software and, even more important (from the author’s point of view), that the software comes “WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE”. If the user isn’t okay with that, he should click “Cancel” an not use the software. At least, if the software destroys your computer and kills your cat, you cannot say that you haven’t been warned. And it’s the exactly same notice that the (L)GPL suggests adding to your software! A console application would usually print this notice to the console on application startup (or when a special “–license” switch is used), while a GUI application would show it in its “About” dialog. Neither method is applicable to a VST plug-in, so it has been implemented as a pop-up dialog that appears on the first use.

I didn’t say it was. I said that requiring acceptance of the license for “use” of the software imposes a restriction on the user over and above that which is stated in LGPL v.2.1. In other words, it is restricting the end users freedom to a greater degree than the LGPL v.2.1 license.

Of course if the GPL/LGPL licenses did not already cover that, then those licenses would be meaningless, but they do clearly state what rights each party has and what rights they do not have. That is the point of the license. If you are not happy with the terms of the license that you are using then you should use a different license.

I have no vested interest in whatever license you chose to use, and that is entirely your right and your decision. but imho if you declare that it is released under LGPL v2.1 then it should be exactly those terms that apply, no more and no less (otherwise it is not really LGPL v2.1 is it?)

:smiley:

I agree with Steve. It does not make things more clear. And for GPL you should not require acceptance at all.

Yes, that is what I meant - I should have explained further. FSF have told me that loading a GPL plug-in that displays a separate GPL licence inside a closed source app was permissible.

If the GPL plug-in loads without licence and so looks like part of the host application, it’s probably not acceptable, unless the user had first to separately install the GPL application and see its licence, before it could be loaded in the closed source app.


Gale

Well, if some code that was released under the GPL is modified and/or combined with other code, this creates a “derivate work”. And such “derivate work”, as a whole, then needs to be distributed under the GPL. Whether the GPL’ed code is linked with the other code in the form of a (plug-in) DLL or as a static library or simply via copy&paste doesn’t matter for the GPL. It’s the LGPL that allows combining the LGPL’ed code with proprietary code - but only as long as the LGPL’ed portion and the proprietary portion of the software can still be linked separately. This is usually interpreted in the way that the LGPL’ed code must remain in a separate DLL, while linking it in as a “static” library is forbidden.

Anyway, you are allowed to load a GPL’ed plug-in into a proprietary application, because you are not redistributing anything at this moment. The GPL only requires you to publish the source codes, if you actually redistribute the software. That’s also why you can modify a GPL’ed software and never publish your modified sources - as long as you never distribute your modified version. If you do distribute the modified version, the modified sources have to be published too.