Overview
fwiw, I dont know, yet, why they include both licenses, but it seems to be unlikely they do it by accident. I assume some embedded code somewhere.
Is it really is a requirement I understand it? Is there some template/example for how that type of thing should be documented, once it has been determined.
I just checked the headers of files and readme, thats about what I did.
Also you should still update that Source to point somewhere either pypi or github tag.
And last what for is the thing bellow needed?: +%if 0%{?suse_version} && 0%{?suse_version} <= 1320 +BuildRequires: %{python_module devel} +%endif
Request History
jayvdb created request
- Activate test suite
- Remove unnecessary build dependencies, and add BuildArch: noarch
- Remove GPL license as it was relicensed to LGPL2.1+ in May 2015
scarabeus_iv accepted request
Note this doesn't include the
COPYINGfrom upstream which is a copy of the GPL ; c.f. superseded request.fedora spec does include the
COPYING.I cant see any requirement for including the
COPYINGin addition to theCOPYING.LESSER. While the LGPL does refer to the GPL, afaics 1) it does so only in the context of authors changing to the GPL, and 2) it contains no language requiring distribution of the GPL with the package.I could be wrong about that of course.
most of the packages in d-l-py do include both. python-pyzmq and python-kmod only include LGPL.
A quick search across all 21877 fedora specs suggests it is not necessary, as there are ~70 instances of
COPYING.LESSERwithout aCOPYING. I can go check them all manually to be absolutely sure, if that would be helpful. But also 70 of 21877 is low enough it could be some slipped through their copyright check net.$ fgrep COPYING.LESSER * | grep -Ev '(COPYING|COPYINGv3|COPYING.txt) 'A search of debian packages would be a better way to determine if this is OK - their copyright hawks have better eyes than most.We have legal team. Lets see what is their verdict :)