Spec URL: http://leamas.fedorapeople.org/lpf-spotify-client/2/lpf-spotify-client.spec SRPM URL: http://leamas.fedorapeople.org/lpf-spotify-client/2/lpf-spotify-client-0.9.0.133.gd18ed58.259-1.fc18.src.rpm Description: Bootstrap package allowing the lpf system to build the non-redistributable spotify-client package. Fedora Account System Username: leamas The spotify-client is a binary application which I originally submitted to rpmfusion [1]. After the license conditions was clarified as non-redistributable a recipe was published to build a rpm from the spec in [2]. This recipe has now been used through one upstream and two Fedora releases. Instead of creating a specific package which downloads and builds the spotify package I tried to create a more general framework in lpf (see dependencies). Basically, this package is a lpf recipe how to build the non-redistributable, binary blob application spotify-client. The spotify-client.spec, the target package otherwise in the srpm is in [3] [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2565 [2] http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/Linux-Fedora-RPM-package-for-F17-F18/m-p/191612 [3] http://leamas.fedorapeople.org/lpf-spotify-client/2/spotify-client.spec
Since the legal aspect of this will come up sooner or later, and I frankly don't know myself I'm blocking this on FE-Legal. The issue: can a package which is OK by itself but has the sole purpose to build a package which contains binary code (thus violating the guidelines) and is non-redistributable go into fedora?
In this specific case, Red Hat is uncomfortable with including this "recipe" without explicit confirmation from Spotify that it is acceptable.
I certainly understand that. What I've got so far is [1]. Do you think this is clear enough (it could certainly be more clear...) ? A sidenote: in their forum I have a thread [2] with a manual recipe how to build a rpm using the spec + some CLI magic. This thread is well-known and obviously accepted. The lpf package basically just automates this recipe, which in my (non-lawyer) eyes seems like more or less the same thing from a law perspective. (?) --alec PS: Sorry, I'm no native English speaker. It becomes just so embarrassing clear when trying to discuss legal stuff "blushes" [1]: http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/What-license-does-the-linux-spotify-client-use/td-p/17335[ [2]: http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/Linux-Fedora-RPM-package-for-F17-F18/m-p/191612#M8425
You need to explain to Spotify clearly and simply, what you are doing and how Fedora would be distributing it (and not the Spotify client), then ask for someone from Spotify to confirm that they are okay with it. Show us that and we'll let this proceed.
OK, fair enough, I'll try to do that. However, it might take some time. They are not to responsive in general, and since they are Swedes a lot of them are on long summer holidays now. We'll see...
Three months... but at last a reply [1]. In my eyes, this looks good. And in yours? [1] http://community.spotify.com/t5/Help-Desktop-Linux-Mac-and/What-license-does-the-linux-spotify-client-use/m-p/557782?nobounce#M63523
The only concern I have is "for personal use". I'm not sure it is possible for us to comply with that license restriction.
Note that the limitation is about what's produced by lpf-spotify, not lpf-spotify itself. We distribute an open-source tool which produces non-free software. Isn't this somewhat similar to an open-sourced client to a service which is not free?
Yes, but they have only granted permission for lpf-spotify to perform "automatic downloading and repackaging of the spotify software for personal use" They're effectively imposing a use restriction on the act of downloading/repackaging, and I don't think we can do that.
Hm...I take your message as this can't be hosted on fedora with this limitation ("maybe" is worst possible outcome here). Since this is not what they intend: Can you think of any wording which resolves this while still enforcing a non-redistribution condition on the created rpms?
I need to think about this some more. This is an entirely new case. We'd be telling consumers of Fedora "this file must only be executed/run for personal use", which is generally incompatible with every other file in Fedora.
Ping. And a thought: isn't this just like it always is when you have a tool which uses material from someone to build something else: you have to respect the original copyright owner? E. g., if you use gcc to compile some sources you might very well end up in that the compiled program is restricted one way or another and even being non-free. But this is certainly not being seen as a problem with gcc. To be frank, lpf-spotify looks similar to me - it's just that the usecase is much more restricted than that for a general tool such as a compiler.
The catch is that they are saying that the script may only be used for personal use, _not_ just the files it downloads. It is different from gcc, because the script only does one thing, and the Spotify folks are saying it is only okay to do that one thing if there is a restriction on personal use. I think it might be possible that what they meant to say is that unrestricted use of the download/packaging script is fine as long as the end-user complies with the spotify EULA, but that's not quite what they said, or at least, it could be interpreted either way. If you can have them clarify that they meant for the "personal use" restriction to apply to the spotify client bits (and not for the script), I think I'd be okay to clear this. Otherwise, I'm going to have to assume the opposite was their intention, and block it.
Spotify is ready to amend their license statement with (private message): ---- Spotify confirms that the personal use restriction does not apply for the open-source downloader. The repackaged Spotify software is for personal use only and in accordance with the Spotify end user agreement. ---- Would this make lpf-spotify legally OK?
Yes. Lifting FE-Legal.
Updating links, new spotify upstream release: spec: http://leamas.fedorapeople.org/lpf-spotify-client/3/lpf-spotify-client.spec srpm: http://leamas.fedorapeople.org/lpf-spotify-client/3/lpf-spotify-client-0.9.4.183.g644e24e.428-1.fc20.src.rpm
Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package does not contain duplicates in %files. Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [!]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. No licenses found. Please check the source files for licenses manually. [x]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/lpf, /var/lib/lpf/packages, /var/lib/lpf, /usr/share/lpf/packages [x]: Package must own all directories that it creates. Note: Directories without known owners: /var/lib/lpf, /var/lib/lpf/packages, /usr/share/lpf, /usr/share/lpf/packages [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [!]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Each %files section contains %defattr if rpm < 4.4 [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop- file-validate if there is such a file. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 0 bytes in 0 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [!]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [x]: Package functions as described. [x]: Latest version is packaged. [!]: Package does not include license text files separate from upstream. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [-]: Packages should try to preserve timestamps of original installed files. [x]: Spec use %global instead of %define unless justified. Note: %define requiring justification: %define target_pkg %(t=%{name}; echo ${t#lpf-}) [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present (not strictly required in GL). [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [!]: SourceX tarball generation or download is documented. [!]: SourceX is a working URL. ===== EXTRA items ===== Generic: [!]: Spec file according to URL is the same as in SRPM. Note: 0 or more than one spec file in srpm(!) See: (this test has no URL) [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Rpmlint ------- Checking: lpf-spotify-client-0.9.4.183.g644e24e.428-1.fc19.noarch.rpm lpf-spotify-client-0.9.4.183.g644e24e.428-1.fc19.src.rpm lpf-spotify-client.noarch: W: spelling-error %description -l en_US redistributable -> redistribute, redistribution, attributable lpf-spotify-client.noarch: W: invalid-url URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec HTTP Error 404: Not Found lpf-spotify-client.noarch: W: no-documentation lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client pkg-build lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client pkg-build lpf-spotify-client.noarch: E: non-standard-dir-perm /var/lib/lpf/packages/spotify-client 0775L lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client/state pkg-build lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client/state pkg-build 0 packages and 0 specfiles checked; 1 errors, 7 warnings. Rpmlint (installed packages) ---------------------------- # rpmlint lpf-spotify-client lpf-spotify-client.noarch: W: spelling-error %description -l en_US redistributable -> redistribute, redistribution, attributable lpf-spotify-client.noarch: W: invalid-url URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec HTTP Error 404: Not Found lpf-spotify-client.noarch: W: no-documentation lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client pkg-build lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client pkg-build lpf-spotify-client.noarch: E: non-standard-dir-perm /var/lib/lpf/packages/spotify-client 0775L lpf-spotify-client.noarch: W: non-standard-uid /var/lib/lpf/packages/spotify-client/state pkg-build lpf-spotify-client.noarch: W: non-standard-gid /var/lib/lpf/packages/spotify-client/state pkg-build 1 packages and 0 specfiles checked; 1 errors, 7 warnings. # echo 'rpmlint-done:' Requires -------- lpf-spotify-client (rpmlib, GLIBC filtered): /bin/sh lpf Provides -------- lpf-spotify-client: lpf-spotify-client Generated by fedora-review 0.5.0 (920221d) last change: 2013-08-30 Command line :/usr/bin/fedora-review --mock-config fedora-19-x86_64 -b 973069 -L . Buildroot used: fedora-19-x86_64 Active plugins: Generic, Shell-api Disabled plugins: Java, C/C++, Python, SugarActivity, Perl, R, PHP, Ruby Disabled flags: EPEL5, EXARCH, DISTTAG Built with local dependencies: /home/slaanesh/Documents/fedora/./lpf-0-3.46ae0c3.fc19.src.rpm /home/slaanesh/Documents/fedora/./lpf-0-3.46ae0c3.fc19.noarch.rpm
Issues: > [!]: If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) > for the package is included in %doc. > [!]: License field in the package spec file matches the actual license. > Note: Checking patched sources after %prep for licenses. No licenses > found. Please check the source files for licenses manually. > [!]: If the source package does not include license text(s) as a separate file > from upstream, the packager SHOULD query upstream to include it. > [!]: Package does not include license text files separate from upstream. The license is MIT, but there's no license file installed. Please provide one in %doc. > [!]: Package consistently uses macros (instead of hard-coded directory names). On line 33, please use %{_datadir} instead of /usr/share. On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib. > [!]: SourceX tarball generation or download is documented. > [!]: SourceX is a working URL. > [!]: Spec file according to URL is the same as in SRPM. > Note: 0 or more than one spec file in srpm(!) > See: (this test has no URL) There is no documentation nor procedure on how to regenerate the source tarball. Please provide an external script in the source (like Mesa) or provide comments in the SPEC file. Also the versioning needs documenting, where does 0.9.4.183.g644e24e.428 come from? I assume it's a snapshot, so if you paste commands to regenerate the tarball that would be ok. I assume you can move the URL to Source0, etc. > Group: Development/Tools Please remove the Group tag, is needed only on EPEL 5. > %description Please make the first description line a bit longer so that it goes nearer to the 80 columns limit. > Package does not contain duplicates in %files. > Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles You can remove line 48; line 47 already includes everything beneath the directory listed. To make it list only one directory (so you can keep line 48) please use the %dir macro which only adds the directory and not the contents. Rpmlint issues: > lpf-spotify-client.noarch: W: invalid-url > URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec > HTTP Error 404: Not Found Please fix, see above comment for source. All the other warnings do not apply here so packages are ok.
(In reply to Simone Caronni from comment #18) > Issues: [cut] > The license is MIT, but there's no license file installed. Please provide > one in %doc. Done. > > [!]: Package consistently uses macros (instead of hard-coded directory names). > > On line 33, please use %{_datadir} instead of /usr/share. > On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib. I'd prefer not to: http://fedoraproject.org/wiki/Packaging:Guidelines#macros > > > [!]: SourceX tarball generation or download is documented. > > [!]: SourceX is a working URL. > > [!]: Spec file according to URL is the same as in SRPM. > > Note: 0 or more than one spec file in srpm(!) > > See: (this test has no URL) > > There is no documentation nor procedure on how to regenerate the source > tarball. I guess this is about spotify-client.spec? If so, there is no need for this since the Source: url is OK: http://fedoraproject.org/wiki/Packaging:SourceURL#Github > Please provide an external script in the source (like Mesa) or provide > comments in the SPEC file. Also the versioning needs documenting, where does > 0.9.4.183.g644e24e.428 come from? I assume it's a snapshot, so if you paste > commands to regenerate the tarball that would be ok. The version field is the upstream spotify version, I don't really see what kind of comment that would be? Added the fact that this is indeed upstream version. [cut] > > Group: Development/Tools Isn't Group: tag allowed?: http://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag > > %description > > Please make the first description line a bit longer so that it goes nearer > to the 80 columns limit. Done. > > > Package does not contain duplicates in %files. > > Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state > > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles > > You can remove line 48; line 47 already includes everything beneath the > directory listed. To make it list only one directory (so you can keep line > 48) please use the %dir macro which only adds the directory and not the > contents. Yes, but I need to set the permissions correct. If I remove that line I need to add a %defattr(664)+ %attr(644) to all files. Certainly possible, but better? "scratches my head" BTW, on f20 rpmlint crashes on this ;) > Rpmlint issues: > > lpf-spotify-client.noarch: W: invalid-url > > URL: http://leamas.fedorapeople.org/spotify/0.9.0/lpf-spotify-client.spec > > HTTP Error 404: Not Found> > Please fix, see above comment for source. All the other warnings do not > apply here so packages are ok. Fixed for now, need to create a better upstream on github before importing, though. In future, it would be good you mentioned which spec you are referring to.. New problem ,for sure. Updated in-place, same links, changelog updated.
(In reply to Alec Leamas from comment #19) > > On line 33, please use %{_datadir} instead of /usr/share. > > On line 47 and 48 please use %{_sharedstatedir} instead of /var/lib. > I'd prefer not to: http://fedoraproject.org/wiki/Packaging:Guidelines#macros Ok, no problem. > > > Group: Development/Tools > Isn't Group: tag allowed?: > http://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag Ok, as you prefer. Are you planning to build this also in EPEL? > > > Package does not contain duplicates in %files. > > > Note: warning: File listed twice: /var/lib/lpf/packages/spotify-client/state > > > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles > > > > You can remove line 48; line 47 already includes everything beneath the > > directory listed. To make it list only one directory (so you can keep line > > 48) please use the %dir macro which only adds the directory and not the > > contents. > Yes, but I need to set the permissions correct. If I remove that line I need > to add a %defattr(664)+ %attr(644) to all files. Certainly possible, but > better? "scratches my head" Ok.
> The version field is the upstream spotify version, I don't really see what > kind of comment that would be? Added the fact that this is indeed upstream > version. Ok after the comment you've added. I'm not following you on these comments, can you explain a bit more? > > > [!]: SourceX tarball generation or download is documented. > > > [!]: SourceX is a working URL. > > > [!]: Spec file according to URL is the same as in SRPM. > > > Note: 0 or more than one spec file in srpm(!) > > > See: (this test has no URL) > > > > There is no documentation nor procedure on how to regenerate the source > > tarball. > > I guess this is about spotify-client.spec? If so, there is no need for this > since the Source: url is OK: > http://fedoraproject.org/wiki/Packaging:SourceURL#Github I haven't look at the spec file inside the package, I'm referring to the contents of the package, in particular: Source0: spotify-client.spec Source1: eula.txt Where do they come from? Handwritten? Taken from a website? Usually Source files have a URL for downloading or comments in the SPEC file or instructions on how to generate them (http://fedoraproject.org/wiki/Packaging:SourceURL). > In future, it would be good you mentioned which spec you are referring to.. > New problem ,for sure. I haven't looked at the bundled spec file; but I assume the review is only for the package that is actually built and assembled in the Fedora infrastructure. Should I also look at the lpf spec file (Source0)?
(In reply to Simone Caronni from comment #21) > > > > I guess this is about spotify-client.spec? If so, there is no need for this > > since the Source: url is OK: > > http://fedoraproject.org/wiki/Packaging:SourceURL#Github > > I haven't look at the spec file inside the package, I'm referring to the > contents of the package, in particular: > > Source0: spotify-client.spec > Source1: eula.txt > > Where do they come from? Handwritten? Taken from a website? Usually Source > files have a URL for downloading or comments in the SPEC file or > instructions on how to generate them > (http://fedoraproject.org/wiki/Packaging:SourceURL). > OK, see your point and yes, this is the very thing here. Normally, you don't ask for the upstream for the spec, it just exists somehow. However, in this case we cant allow spotify-client to go into fedora, so I sort of wrap it into lpf-spotify-client. And spotify-client.spec becomes Source0:. From my perspective, this is just how it is, but it's not obvious. I suggest that we see this package as the spotify-client package with a lpf wrapper. From this perspective spotify-client.spec "just exists". There is no other upstream for this spec, for sure. Given this, I'll gladly accept any proposal for a comment to Source0. I just can't come up with something sensible to write. The eula needs a comment, for sure. Added. Long links is a pain. Same links, changelog updated.
It's ok, now it's clear. I think that if you add something along the line of: # There is no source, only the spec file which allows building the # non-redistributable package. or anything like that, it would be ok. Thanks for the package. APPROVED.
Thanks for the review. Will fix the source comment and add a README - how to actually use this is not really obvious :)
New Package SCM Request ======================= Package Name: lpf-spotify-client Short Description: Spotify music player native client package bootstrap Owners: leamas Branches: f19 f20 InitialCC:
Git done (by process-git-requests).
Closing, package was imported in RPMFusion months ago.