Spec URL: http://oget.fedorapeople.org/review/lv2-fil-plugins.spec SRPM URL: http://oget.fedorapeople.org/review/lv2-fil-plugins-2.0-1.fc11.src.rpm Description: Stereo and mono LV2 plugins, four-band parametric equalisers. Each section has an active/bypass switch, frequency, bandwidth and gain controls. There is also a global bypass switch and gain control. The 2nd order resonant filters are implemented using a Mitra-Regalia style lattice filter, which has the nice property of being stable even while parameters are being changed. All switches and controls are internally smoothed, so they can be used 'live' whithout any clicks or zipper noises. This should make this plugin a good candidate for use in systems that allow automation of plugin control ports, such as Ardour, or for stage use. The GUI provides knobs and toggle buttons for tweaking filter parameters. It also provides frequency response widget with differently coloured curve for each section and separate curve for total equalization effect. rpmlint is silent. The package name is set for compliance with other lv2 plugins we have. Should be an easy review.
> License: GPLv2+ Several files contain a GPLv2 header _without_ the "or later" clause, e.g. log.*, lv2filter.* and lv2_ui.c The lv2_ui.h header contains a LGPL header! > Summary: Four-band parametric equalisers > > Description: > Stereo and mono LV2 plugins, four-band parametric equalisers. "equaliser" is British English while "equalizer" is American English _as well as_ British English.
(In reply to comment #1) > > License: GPLv2+ > > Several files contain a GPLv2 header _without_ the "or later" clause, e.g. > log.*, lv2filter.* and lv2_ui.c > The lv2_ui.h header contains a LGPL header! > So what is your conclusion? > > > Summary: Four-band parametric equalisers > > > > Description: > > Stereo and mono LV2 plugins, four-band parametric equalisers. > > "equaliser" is British English while "equalizer" is American English _as well > as_ British English. I took this directly from upstream description. By the way, I saw many people in the US who use "*iser" instead of "*izer". Are you sure there is a rule for this?
The conclusion is: License: GPLv2+ and LGPLv2+ and GPLv2 http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Mixed_Source_Licensing_Scenario By contacting the authors and asking them to clarify the licensing in the log.* files, it would reduce to "GPLv2+ and LGPLv2+". The latter is due to the unchanged lv2_ui.h license. Upstream may opt to change the licensing of that file to GPLv2+ when following the guidelines in the LGPL paragraph 3. > By the way, I saw many peoplein the US who use "*iser" instead of > "*izer". Are you sure there is a rule for this? The following is not my original source, but one I can link to: http://en.wikipedia.org/wiki/American_and_British_English_spelling_differences#-ise.2C_-ize and http://en.wikipedia.org/wiki/American_and_British_English_differences
(In reply to comment #3) > The conclusion is: > > License: GPLv2+ and LGPLv2+ and GPLv2 > > http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Mixed_Source_Licensing_Scenario > > By contacting the authors and asking them to clarify the licensing in the log.* > files, it would reduce to "GPLv2+ and LGPLv2+". The latter is due to the > unchanged lv2_ui.h license. Upstream may opt to change the licensing of that > file to GPLv2+ when following the guidelines in the LGPL paragraph 3. Yes, but when these files get compiled into one file, the effective license is the most restrictive one, which in this case is GPLv2. That's the way we've been doing. See for instance: https://www.redhat.com/archives/fedora-legal-list/2009-November/msg00027.html If there were different files being distributed under different licenses in the same package, then we use "A and B and ..." in the license tag.
You're contradicting yourself, and the thread on fedora-legal-list is not accurate and could be called "false advice". > the effective license is > the most restrictive one, which in this case is GPLv2. Then your package still cannot use "License: GPLv2+" as one source file remains GPLv2 and others remain LGPLv2+. License conversion is not implicit. Copying source code that applies license 1 into a project that applies license 2 does not automatically convert their licensing to anything like the "most restrictive one" or "the effective license". With regard to the GPL, to convert from one license to another means to re-license explicitly and in accordance with the current licensing terms. For a one-time conversion from LGPLv2+ to GPL this means to alter all notices that refer to the old license. The GPLv2 licensed file has further consequences as long as it is not converted to GPLv2+. http://fedoraproject.org/wiki/Licensing#GPL_Compatibility_Matrix Simply by building a program from a mixed sources project, you cannot alter/hide the licensing that applies to the program.
(In reply to comment #5) > > the effective license is > > the most restrictive one, which in this case is GPLv2. > > Then your package still cannot use "License: GPLv2+" I know. The license tag on the package is wrong right now. I am just trying to figure out what is the best thing to put there. > Simply by building a program from a mixed sources project, you cannot > alter/hide the licensing that applies to the program. *sigh* Everybody is talking different. I don't know whom to believe. Once I did what you said for the kmplayer package. I put all the license names into the tag that belong to source files that get compiled into a final binary. Please see [1]. Upon consultation to spot, we were advised to cut the list and put the "effective license" there [2]. I will open another topic at fedora-legal list, as they are the most authorized people. [1] http://cvs.fedora.redhat.com/viewvc/devel/kmplayer/kmplayer.spec?revision=1.7&view=markup [2] http://cvs.fedora.redhat.com/viewvc/devel/kmplayer/kmplayer.spec?r1=1.10&r2=1.11
These are situations that make bad thoughts creep into my brain. :-/ The "effective license" once more? Huh? That's another term for "WTF? We don't care about proper licensing of a program". A term that cannot be found in Fedora's Licensing Guidelines. - I'm not a lawyer. Spot isn't one either. But it doesn't need a lawyer to come up with a case of a mixed-source program that is based on GPL'ed files and LGPL'ed files doing most of the work. The FSF wants program licenses to be applied in a clear, unambiguous way (which is also one reason why they distinguish between copying source code and linking with external libraries). And what do we do? We make up an "effective license" and pretend that the program is subject to the GPL only while actually parts of it apply the more liberal [less free!] LGPL. Uh, come on! Fedora's Licensing guidelines explicitly ask for "maintainers [to] make every possible effort to be accurate when filling the License: field". [...] I've sent a message to the lv2fil author, pointing out the mixed-source licensing and suggesting a clarification and conversion to GPLv2 or later.
Hey, chill. I did not mean to piss you off. This is a legal issue and thus it is important that we do this consistently in Fedora. I have seen different implementations of this "effective license" and this breaks consistency. I have sent an email to Fedora Legal, and I hope that this issue will be settled once and for all. Thanks for contacting the lv2fil author.
Okay. I think the license issue is settled. Thanks for bringing it up. I updated the files: Spec URL: http://oget.fedorapeople.org/review/lv2-fil-plugins.spec SRPM URL: http://oget.fedorapeople.org/review/lv2-fil-plugins-2.0-2.fc12.src.rpm Changelog: 2.0-2 - Obey American English rules (equaliser -> equalizer) - Fix license. Add comments.
* lv2rack here freezes when asking it to display lv2-fil's UI. Process is: python /usr/lib/lv2/filter.lv2/ui osc.udp://localhost:17500/ http://nedko.aranaudov.org/soft/filter/2/mono /usr/lib/lv2/filter.lv2/ 0:4-band parametric filter (Mono) The "ui" python script works when running it manually, though. So, double-checking lv2rack's ability to display UIs: * lv2rack works with other plugins user interfaces, but crashes when loading lv2-swh-plugins' crossfade plugin. Seems there are some grave bugs.
(In reply to comment #10) > * lv2rack here freezes when asking it to display lv2-fil's UI. Process is: > > python /usr/lib/lv2/filter.lv2/ui osc.udp://localhost:17500/ > http://nedko.aranaudov.org/soft/filter/2/mono /usr/lib/lv2/filter.lv2/ 0:4-band > parametric filter (Mono) > It works here. lv2rack displays the GUI of lv2-fil with no freeze. Can you be more specific on your steps to produce the freeze? > The "ui" python script works when running it manually, though. So, > double-checking lv2rack's ability to display UIs: > > * lv2rack works with other plugins user interfaces, but crashes when loading > lv2-swh-plugins' crossfade plugin. Seems there are some grave bugs. swh plugins were being ported from ladspa to lv2 a while ago. Many of them were incomplete. I fixed some of them myself and upstreamed the fixes. For the rest, I filed an extensive bug in their bug tracker. You can find my list at http://github.com/swh/lv2/issues#issue/2 Some of these are fixed by other folks. I update the RPM package every now and then with the fixes from their git. If you want to give a hand, contact upstream. They are quite responsive.
The steps are: 1.) start lv2rack (via GNOME menu or in a terminal) 1.1) if started in a terminal, notice a suspicious search path for LV2 plugins: Loading LV2 plugin cache from "/home/qa/.cache/lv2rack/plugins" LV2_PATH not set, defaulting to ['/home/qa/.lv2', '/usr/local/lib/lv2', '/usr/lib/lv2', '/usr/local/lib64/lv2', '/usr/lib64/lv2'] 2.) in lv2rack, open menu "Effect > Load..." 3.) highlight "4-ban parametric filter (Mono) ..." 3.1) or the Stereo version 4.) click "Load" button 5.) in list of instances, click UI checkbox 6.) lv2rack freezes + no lv2-fil UI appears
I just can't reproduce this. I tried it ~20 times during different times of the day. It works fine on the 2 computers that I tried. Does the freeze happen every time for you?
Yes, it's reproducible. Also on two machines (which are not similar to eachother). It depends on the networking setup, but I don't have the time to examine it much further as other networking apps work fine here. From comment 10: > ... osc.udp://localhost:17500/ ... If I switch networks or tell the dhcp server to emit hostnames, the UI invocation changes (and specifies a hostname instead of "localhost"), and the UI appears. Well, I don't see any obvious error WRT the localhost setup here, but since the dhcp server/gateway influences DNS queries, there may be special conditions under which lv2-fil gets an answer that makes it fail. Shouldn't block the review.
Fedora Review lv2-fil-plugins 2010-07-15 rpmlint output: $ rpmlint lv2-fil-plugins-2.0-2.fc12.src.rpm lv2-fil-plugins-2.0-2.fc12.x86_64.rpm lv2-fil-plugins-debuginfo-2.0-2.fc12.x86_64.rpm lv2-fil-plugins.src: W: spelling-error %description -l en_US whithout -> without, whiteout, whither lv2-fil-plugins.src: W: spelling-error %description -l en_US plugin -> plug in, plug-in, plugging lv2-fil-plugins.src: W: spelling-error %description -l en_US coloured -> Coloured, colored, co loured lv2-fil-plugins.x86_64: W: spelling-error %description -l en_US whithout -> without, whiteout, whither lv2-fil-plugins.x86_64: W: spelling-error %description -l en_US plugin -> plug in, plug-in, plugging lv2-fil-plugins.x86_64: W: spelling-error %description -l en_US coloured -> Coloured, colored, co loured 3 packages and 0 specfiles checked; 0 errors, 6 warnings. Fix spelling error: whithout → without Fix BE vs. AE: coloured → colored The warning about "plugin" can be ignored + Package is named according to guidelines (and fits well with existing lv2-*-plugins packages) + Specfile is named after the package + Package license tag (LGPLv2+ and GPLv2 and GPLv2+) is Fedora approved Licenses of installed components: * filter.so: filter.[ch] → GPLv2+ lv2filter.[ch] → GPLv2 lv2plugin.c → GPLv2 log.[ch] → GPLv2 lv2_ui.c → GPLv2+ lv2_ui.h → LGPLv2+ lv2_external_ui.h → Public domain License for aggregate: GPLv2 * ui → license statement in file: GPLv2 * filter.ttl, lv2logo.png, manifest.ttl → no license statement in the files → assume GPLv2 since this is what upstream claims is the default for the project http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License:_field says: "The License: field refers to the licenses of the contents of the binary rpm." - So as far as I read the guidelines a license tag of "GPLv2" is enough + The license file (COPYING) is included as %doc + Specfile is written in legible English + Source matches upstream: $ md5sum srpm/lv2fil-2.0.tar.bz2 lv2fil-2.0.tar.bz2 dc1a54c3a35b3639755b985cdcd281b6 srpm/lv2fil-2.0.tar.bz2 dc1a54c3a35b3639755b985cdcd281b6 lv2fil-2.0.tar.bz2 + Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2322943 ? BuildRequires are sane, but build used bundles waf instead of system's, intentional? + No locales + No shared libraries in the default library search path + No bundled libraries + Package owns directories it creates + No duplicate files + Permissions are sane and %files has %defattr + Specfile uses macros consistently + Contains code + %doc is not runtime essential + No headers + No static libraries + No libtool archives + Package does not own other's directories + Installed files have valid UTF8 filenames
(In reply to comment #15) > Fedora Review lv2-fil-plugins 2010-07-15 > Thanks again! > Fix spelling error: whithout → without > Fix BE vs. AE: coloured → colored > Fixed. > + Package is named according to guidelines (and fits well with > existing lv2-*-plugins packages) > + Specfile is named after the package > + Package license tag (LGPLv2+ and GPLv2 and GPLv2+) is Fedora approved > > Licenses of installed components: > > * filter.so: > filter.[ch] → GPLv2+ > lv2filter.[ch] → GPLv2 > lv2plugin.c → GPLv2 > log.[ch] → GPLv2 > lv2_ui.c → GPLv2+ > lv2_ui.h → LGPLv2+ > lv2_external_ui.h → Public domain > License for aggregate: GPLv2 > > * ui → license statement in file: GPLv2 > > * filter.ttl, lv2logo.png, manifest.ttl → no license statement in the > files → assume GPLv2 since this is what upstream claims is the > default for the project > > http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License:_field > says: "The License: field refers to the licenses of the contents of > the binary rpm." > > - So as far as I read the guidelines a license tag of "GPLv2" is enough > That was the original license tag I set on this package (2.0-1). However, Michael pointed out that this is wrong. See comments 1-8 above. I also asked this on Fedora Legal list https://www.redhat.com/archives/fedora-legal-list/2009-December/msg00029.html The outcome was "There is no such thing as effective license, or no such thing as most restrictive license wins. List all licenses included in the tag". So I changed it to LGPLv2+ and GPLv2 and GPLv2+ > ? BuildRequires are sane, but build used bundles waf instead of system's, > intentional? > See https://bugzilla.redhat.com/show_bug.cgi?id=541524#c5 This one even crashes the system waf. :( SPEC: http://oget.fedorapeople.org/review/lv2-fil-plugins.spec SRPM: http://oget.fedorapeople.org/review/lv2-fil-plugins-2.0-3.fc13.src.rpm Changelog: 2.0-3 - More language fixes
(In reply to comment #16) > That was the original license tag I set on this package (2.0-1). However, > Michael pointed out that this is wrong. See comments 1-8 above. I also asked > this on Fedora Legal list > https://www.redhat.com/archives/fedora-legal-list/2009-December/msg00029.html > > The outcome was "There is no such thing as effective license, or no such thing > as most restrictive license wins. List all licenses included in the tag". > > So I changed it to LGPLv2+ and GPLv2 and GPLv2+ I find this to contradict item 1 and 2 in the following section of the Fedora Licensing FAQ: https://fedoraproject.org/wiki/Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F 1. The source code contains some .c files which are GPLv2+ and some other .c files which are BSD. They're compiled together to form an executable. Since some of the files are licensed as GPL, the resulting executable is also GPL. The License tag should read: License: GPLv2+ Note that you do NOT need to list BSD in the License tag, the License tag reflects the resulting, packaged, items in the binary RPM. 2. The source code contains some .c files which are GPLv2 and some other .c files which are GPLv2+. They're compiled together to form an executable. In this case, the stricter license wins, so the resulting executable is GPLv2. The License tag should read: License: GPLv2 Note that you do NOT need to list GPLv2 and GPLv2+ in the License tag. Due to the way GPL is constructed ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein.") - The most restrictive license of GPL and any GPL compatible license is always GPL. If none of the licenses involved was GPL I would agree with you that they should all be listed, but since GPL is involved in this case, I still think the proper License tag for this package is GPLv2.
Great. Back to where I started. :) I brought up the issue in FE-Legal list again. Let's see what will come out this time: http://lists.fedoraproject.org/pipermail/legal/2010-July/001340.html
Please read Joerg Schilling's response in the above mailing list thread. According to his explanation, lv2fil can be classified as a "collective work" since the codes of various author are brought together into a single product. The source files are not written by a single author. Now we know that, * The source files are: filter.* : GPLv2+ by Nedko Arnaudov. But the DSP code is based on ladspa:1970 by Fons Adriaensen. log.* : GPLv2 by Nedko Arnaudov. lv2_external_ui.h : Public Domain lv2_ui.h : LGPLv2+ by various authors lv2_ui.c : GPLv2+ by Nedko Arnaudov. lv2filter.* : GPLv2 by Nedko Arnaudov lv2plugin : GPLv2 by Nedko Arnaudov * In an email, Nedko Arnaudov states that he wanted his code to be GPLv2 only. So from here, we can say that Nedko Arnaudov's part of the code is GPLv2. We have 2 possibilities: 1- If Fons Adriaensen's part of the code in filter.* is GPLv2 too, we can say that the collective work of Nedko Arnaudov, Fons Adriaensen and all the authors of lv2_external_ui.h is GPLv2 and LGPLv2+. 2- However, if Fons Adriaensen's part of the filter.* code is GPLv2+, then the collective work has license LGPLv2+ and GPLv2 and GPLv2+. We find Fons' code in our ladspa-fil-plugins package in file filters.cc. This file clearly states that the license is GPLv2+. Hence the collective work is LGPLv2+ and GPLv2 and GPLv2+. I think I interpreted it correctly this time.
I'm not sure anything got more clear for me after reading this explanation. As far as I can tell there seems to be different opinions regarding this expressed by different people, and either camp fails to provide the arguments necessary to convince the other that their point of view is correct. I still think that having only GPL2 as the License tag would be allowed, but there is not really anything wrong with listing all three either. Finding the ultimate answer for this issue is clearly beyond the scope of this one review, and waiting for that should not block its approval. Package approved.
I am 90% sure (but not 100%) that I interpreted FE-Legal's explanation correctly. But as you said, LGPLv2+ and GPLv2 and GPLv2+ may be long but is not wrong. Thank you for the review Mattias. New Package CVS Request ======================= Package Name: lv2-fil-plugins Short Description: Four-band parametric equalisers Owners: oget Branches: F-12 F-13 InitialCC:
Ah, I just copy/pasted the "Short Description" from the thread title which I needed to fix. The correct request is New Package CVS Request ======================= Package Name: lv2-fil-plugins Short Description: Four-band parametric equalizers Owners: oget Branches: F-12 F-13 InitialCC:
CVS done (by process-cvs-requests.py).
lv2-fil-plugins-2.0-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/lv2-fil-plugins-2.0-3.fc13
lv2-fil-plugins-2.0-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/lv2-fil-plugins-2.0-3.fc12
lv2-fil-plugins-2.0-3.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lv2-fil-plugins'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lv2-fil-plugins-2.0-3.fc13
lv2-fil-plugins-2.0-3.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lv2-fil-plugins'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/lv2-fil-plugins-2.0-3.fc12
lv2-fil-plugins-2.0-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
lv2-fil-plugins-2.0-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.