Bug#859793: fluidsynth: Package has infringed GPL
El dl 10 de 04 de 2017 a les 23:06 +0200, Peter Hanappe va escriure: > However, it seems that chorus.c is now under the LGPL license. From > https://sourceforge.net/p/sox/code/ci/master/tree/COPYING: As I understand, fluidsynth_chorus.c was imported from SoX rather than the original project by Juergen Mueller. Thus, Chris Bagwell is the one who can shed light on the origin. > However, since fluidsynth was under LGPL > with "Copyright (C) 2003 Peter Hanappe and others" from the > beginning, I don't believe any contributors to > fluidsynth_chorus.c would object to putting their changes to that > file under the LGPL. I'll happily make my changes available under > that license. That makes sense. However, the main problem is the permission from Juergen Mueller and related contributors. > So, because SoX/chorus.c is now under the LGPL and all the > changes that have been made between chorus.c and > fluidsynth_chorus.c fall under the LGPL, I believe that > fluidsynth_chorus.c can be put under the LGPL, too. I see no evidence to support such relicensing. Original copyright should be to dropped if there is no trace from the original file, but this does not seem to be the case. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859793: fluidsynth: Package has infringed GPL
El dl 10 de 04 de 2017 a les 09:24 +0200, David Henningsson va escriure: > What makes things slightly easier for us as upstream is that FluidSynth > is released under LGPL rather than GPL. LGPL allows linking to custom > licenses. This is not the case because fluid_chorus.c is part of the library and must respect rights under LGPL. Rewriting fluid_chorus.c could be one first step. However, we could wait some time until Chris Bagwell tells us about the original source; Chris Bagwell or Peter Hanappe, it is not clear to me that fluid_chorus.c comes from SoX. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859793: fluidsynth: Package has infringed GPL
Dear Chris Bagwell, In 1999, you imported src/chorus.c to SoX on SourceForge.[6] File is copyrighted by Juergen Mueller and sundry contributors. Could you tell us where we could find the original project or how to contact Juergen Mueller? Thank you. -- [6] https://sourceforge.net/p/sox/code/ci/98267de439714fcdff94c9588f34fb8a67df70c1/?page=1 smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859793: fluidsynth: Package has infringed GPL
Regarding SoX and Debian bug #92969, the copyright handling in wav.c is dubious.[5] Assuming this modification is allowed, wav.c changes the notice XAnim Copyright (C) 1990-1997 by Mark Podlipec. [...] This software may be freely copied, modified and redistributed without fee for non-commerical purposes which is clearly incompatible with the original license, to Thanks goes to Mark Podlipec's XAnim code. It gave some real life understanding of how the ADPCM format is processed. Actual code was implemented based off of various sources from the net. So the code was from Mark Podlipec, but now it is only an inspiration for Chris Bagwell, yet various sources from the net are needed? Or Mark Podlipec's code was inspired by those sources from the net? Chris Bagwell should clarify the origin of the code. -- [5] https://sourceforge.net/p/sox/code/ci/613f50d018d73308428dda8c610066a726e1a95e/ smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859793: fluidsynth: Package has infringed GPL
El dv 07 de 04 de 2017 a les 19:13 +0100, James Cowgill va escriure: > FYI the license in question is the SoX license which has been in Debian > and basically all distributions for 20 years (as part of SoX)... So SoX and derivatives are affected too. The problem was not detected.[3] > The SoX project relicensed some time ago to GPL so if you are to believe > that that was OK, then there are no licensing problems with this file > (but the copyright header should be updated to reflect that). Upstream file still has the old copyright.[4] Where is this relicensing process documented? -- [3] https://bugs.debian.org/92969 [4] https://sourceforge.net/p/sox/code/ci/master/tree/src/chorus.c smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#859793: fluidsynth: Package has infringed GPL
Source: fluidsynth Version: 1.1.6-4 Severity: wishlist fluid_chorus.c is under a custom license, granting the following: This source code is freely redistributable and may be used for any purpose. The license does not grant the right to modify the software. Therefore, it is not compatible with GPL-2.1+ (sic) or LGPL-2.0+. Whether intentionally or not, Debian has been distributing this software without complying with GPL. Thus its rights have been automatically terminated. Ceasing violation does not restore rights and a new license should be acquired. I will remind you of the scope of such infringement. Since Debian does not have the right to distribute, it does not have the right to propagate the license. All Debian-based distros and their users have not automatically received a license through Debian. Because of the avalanche effect of GPL, all works based on these versions of FluidSynth have not received rights under GPL. The process recurs: all Debian-based distros, their users, and depending works have not received a license through this path. I will remind you of the potential severity. Like the patent troll phenomenon, some people profit from GPL reinstatements. The argument exists: If you have redistributed an application under GPLv2, but have violated the terms of GPLv2, you must request a reinstatement of rights from the copyright holders before making further distributions, or else cease distribution and modification of the software forever.[1] There are real cases based on this reasoning; e.g., BusyBox related.[2] Although the Software Freedom Law Center may not be interested in infringements caused because of FluidSynth, other parties may be. Is there anyone against successful free audio software? -- [1] https://www.softwarefreedom.org/resources/2008/compliance-guide.html [2] http://www.ecommercetimes.com/story/73241.html smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#850179: libgig-dev: ISO C++11 compliance
Package: libgig-dev
Version: 3.3.0-5
Severity: wishlist
Tags: patch
Clang on C++11 mode complains:
ISO C++11 does not allow access declarations;
use using declarations instead
DLS::Sampler::UnityNote;
This patch fixes the header.
Description: ISO C++11 compliance
Fix compilation with Clang on C++11 mode.
Author: Javier Serrano Polo <jav...@jasp.net>
Index: libgig-3.3.0/src/gig.h
===
--- libgig-3.3.0.orig/src/gig.h 2015-08-04 23:22:14.0 +
+++ libgig-3.3.0/src/gig.h 2017-01-04 17:52:46.0 +
@@ -431,11 +431,11 @@
uint8_tDimensionUpperLimits[8]; ///< gig3: defines the upper limit of the dimension values for this dimension region
// derived attributes from DLS::Sampler
-DLS::Sampler::UnityNote;
-DLS::Sampler::FineTune;
-DLS::Sampler::Gain;
-DLS::Sampler::SampleLoops;
-DLS::Sampler::pSampleLoops;
+using DLS::Sampler::UnityNote;
+using DLS::Sampler::FineTune;
+using DLS::Sampler::Gain;
+using DLS::Sampler::SampleLoops;
+using DLS::Sampler::pSampleLoops;
// own methods
double GetVelocityAttenuation(uint8_t MIDIKeyVelocity);
@@ -452,8 +452,8 @@
void SetVCFVelocityScale(uint8_t scaling);
Region* GetParent() const;
// derived methods
-DLS::Sampler::AddSampleLoop;
-DLS::Sampler::DeleteSampleLoop;
+using DLS::Sampler::AddSampleLoop;
+using DLS::Sampler::DeleteSampleLoop;
// overridden methods
virtual void SetGain(int32_t gain);
virtual void UpdateChunks();
@@ -669,15 +669,15 @@
class Instrument : protected DLS::Instrument {
public:
// derived attributes from DLS::Resource
-DLS::Resource::pInfo;
-DLS::Resource::pDLSID;
+using DLS::Resource::pInfo;
+using DLS::Resource::pDLSID;
// derived attributes from DLS::Instrument
-DLS::Instrument::IsDrum;
-DLS::Instrument::MIDIBank;
-DLS::Instrument::MIDIBankCoarse;
-DLS::Instrument::MIDIBankFine;
-DLS::Instrument::MIDIProgram;
-DLS::Instrument::Regions;
+using DLS::Instrument::IsDrum;
+using DLS::Instrument::MIDIBank;
+using DLS::Instrument::MIDIBankCoarse;
+using DLS::Instrument::MIDIBankFine;
+using DLS::Instrument::MIDIProgram;
+using DLS::Instrument::Regions;
// own attributes
int32_t Attenuation; ///< in dB
uint16_t EffectSend;
@@ -688,7 +688,7 @@
// derived methods from DLS::Resource
-DLS::Resource::GetParent;
+using DLS::Resource::GetParent;
// overridden methods
Region* GetFirstRegion();
Region* GetNextRegion();
@@ -750,16 +750,16 @@
static const DLS::version_t VERSION_3;
// derived attributes from DLS::Resource
-DLS::Resource::pInfo;
-DLS::Resource::pDLSID;
+using DLS::Resource::pInfo;
+using DLS::Resource::pDLSID;
// derived attributes from DLS::File
-DLS::File::pVersion;
-DLS::File::Instruments;
+using DLS::File::pVersion;
+using DLS::File::Instruments;
// derived methods from DLS::Resource
-DLS::Resource::GetParent;
+using DLS::Resource::GetParent;
// derived methods from DLS::File
-DLS::File::Save;
+using DLS::File::Save;
// overridden methods
File();
File(RIFF::File* pRIFF);
smime.p7s
Description: S/MIME cryptographic signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#835589: libjack-jackd2-0: libjack-0.116 is not equivalent to libjack-jackd2-0
Package: libjack-jackd2-0 Version: 1.9.10+20150825git1ed50c92~dfsg-2 Severity: wishlist Control: clone -1 -2 Control: reassign -2 libsoundio1 Control: retitle -2 libsoundio1: Missing hard dependency on libjack-jackd2-0 Control: found -2 1.0.2-1 libsoundio1 depends on jack_set_port_rename_callback, which is provided by libjack-jackd2-0 only. libjack-jackd2-0 should provide a symbols file to know if libjack0 (libjack-0.116) is a valid alternative. libsoundio1 could add a manual dependency on libjack-jackd2-0 while waiting for this symbols file. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#826110: swh-plugins, vocoder-ladspa: error when trying to install together
Control: reassing -1 vocoder-ladspa Control: affects -1 swh-plugins I will ask to upload a new version of lmms to remove vocoder-ladspa. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824211: marked as pending
El dt 31 de 05 de 2016 a les 14:09 +, Jaromír Mikeš va escriure: > + * Fix multi-arch path. Will the plug-ins be installed under /usr/lib/*/ladspa? I would be in favor, but AFAIK this would be the first Debian package to ship LADSPA plug-ins under a multiarch folder instead of /usr/lib/ladspa. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824211: swh-plugins: Package new upstream version
El dj 19 de 05 de 2016 a les 19:41 +0200, Jaromír Mikeš va escriure: > Yes, that would be definitely possible, but I would to to know where > next releases will be published to tune watch file accordingly. Nine years have passed without a release. I think a watch file is obsolete. I would rely on "New upstream release" bugs from users. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#824211: swh-plugins: Package new upstream version
Package: swh-plugins Version: 0.4.15+1-8 Severity: wishlist The upstream project is maintained at https://github.com/swh/ladspa . It includes a vocoder plug-in that is shipped with the lmms package. To reuse this plug-in, lmms could put it under /usr/lib/ladspa, but that would conflict with a new version of swh-plugins. Could you tell if you will package a new upstream version, which is preferable, or if lmms can publish this plug-in in the meantime? smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#823561: zynaddsubfx: License should be GPL-2+
Package: zynaddsubfx Version: 2.5.2-2 Severity: wishlist According to https://github.com/LMMS/lmms/issues/2752#issuecomment-217043740 , it looks like the license should be GPL-2+ despite what individual files say. smime.p7s Description: S/MIME cryptographic signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
