Bug 537325 - Review Request: lv2-fil-plugins - Four-band parametric equalizers
Summary: Review Request: lv2-fil-plugins - Four-band parametric equalizers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mattias Ellert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-11-13 06:42 UTC by Orcan Ogetbil
Modified: 2010-08-06 21:02 UTC (History)
2 users (show)

Fixed In Version: lv2-fil-plugins-2.0-3.fc12
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-06 20:56:38 UTC
mattias.ellert: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Orcan Ogetbil 2009-11-13 06:42:54 UTC
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.

Comment 1 Michael Schwendt 2009-12-05 18:56:00 UTC
> 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.

Comment 2 Orcan Ogetbil 2009-12-05 21:14:57 UTC
(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?

Comment 3 Michael Schwendt 2009-12-06 10:37:18 UTC
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

Comment 4 Orcan Ogetbil 2009-12-09 04:43:22 UTC
(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.

Comment 5 Michael Schwendt 2009-12-09 08:40:57 UTC
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.

Comment 6 Orcan Ogetbil 2009-12-09 09:23:46 UTC
(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

Comment 7 Michael Schwendt 2009-12-09 10:26:41 UTC
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.

Comment 8 Orcan Ogetbil 2009-12-09 10:45:56 UTC
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.

Comment 9 Orcan Ogetbil 2009-12-12 04:51:03 UTC
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.

Comment 10 Michael Schwendt 2010-01-06 14:27:43 UTC
* 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.

Comment 11 Orcan Ogetbil 2010-01-23 01:31:48 UTC
(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.

Comment 12 Michael Schwendt 2010-01-26 16:24:32 UTC
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

Comment 13 Orcan Ogetbil 2010-01-30 18:29:48 UTC
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?

Comment 14 Michael Schwendt 2010-01-31 10:59:11 UTC
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.

Comment 15 Mattias Ellert 2010-07-15 20:50:46 UTC
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

Comment 16 Orcan Ogetbil 2010-07-16 23:13:38 UTC
(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

Comment 17 Mattias Ellert 2010-07-18 03:21:30 UTC
(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.

Comment 18 Orcan Ogetbil 2010-07-18 03:48:20 UTC
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

Comment 19 Orcan Ogetbil 2010-07-18 22:20:26 UTC
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.

Comment 20 Mattias Ellert 2010-07-19 10:47:03 UTC
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.

Comment 21 Orcan Ogetbil 2010-07-19 15:07:24 UTC
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:

Comment 22 Orcan Ogetbil 2010-07-19 15:09:56 UTC
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:

Comment 23 Kevin Fenzi 2010-07-21 05:09:57 UTC
CVS done (by process-cvs-requests.py).

Comment 24 Fedora Update System 2010-07-22 04:23:12 UTC
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

Comment 25 Fedora Update System 2010-07-22 04:24:05 UTC
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

Comment 26 Fedora Update System 2010-07-23 02:39:20 UTC
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

Comment 27 Fedora Update System 2010-07-23 02:39:25 UTC
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

Comment 28 Fedora Update System 2010-08-06 20:56:31 UTC
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.

Comment 29 Fedora Update System 2010-08-06 21:02:28 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.