[Bug 45391] New: winehq.org is distributing compiled LGPL code packages but withholding their sources
https://bugs.winehq.org/show_bug.cgi?id=45391
Bug ID: 45391 Summary: winehq.org is distributing compiled LGPL code packages but withholding their sources Product: Packaging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: wine-packages Assignee: wine-bugs@winehq.org Reporter: forestcode@ixio.org CC: michael@fds-team.de, sebastian@fds-team.de Distribution: ---
The source code tarballs and package build scripts for winehq's ubuntu and debian packages are not published. They are not where they are supposed to be according to the official debian/ubuntu sources.list file (the deb-src entry that gets created when someone follows the official apt-add-repository instructions), they don't seem to be referenced anywhere else obvious, and nobody at the wine project has been forthcoming about how to get them. [1][2][3]
So, winehq.org is distributing binary packages without making their sources available. This makes it impossible for the people using those packages to audit the code, reproduce the packages, test patches on known-good packaged versions, or port them to different OS releases (the latter leading to issues like bug 45085).
From what I can tell, this is also likely an LGPL violation:
"4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code"
What will it take to remedy this situation?
[1] Notice the absence of an answer in this thread: https://www.winehq.org/pipermail/wine-devel/2018-May/127507.html [2] Nobody had an answer for me on the two occasions when I asked on #winehackers irc this week. [3] Nobody responded when I emailed the package maintainers listed at https://wiki.winehq.org/Download
https://bugs.winehq.org/show_bug.cgi?id=45391
Qwerty Chouskie asdfghrbljzmkd@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asdfghrbljzmkd@outlook.com
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #1 from Michael Müller michael@fds-team.de --- The build system does not generate source packages for Debian / Ubuntu and instead directly compiles the binary package. The scripts that are run inside of the virtual machines to build the packages are available at https://github.com/wine-compholio/wine-packaging. So you got everything you need to rebuild the packages in the same way as done on our build server. This does not imply that this method is the same as you would do it locally on your machine.
Btw, I am also pretty sure that publishing the build files is not a requirement of the LGPL. You have to provide the source code for the compiled binary files, which is obviously done as all packages use an unpatched version of the corresponding wine source code. However, you are not required to tell someone how you build it. The LGPL only requires you to publish modifications of the original source code, but the build files are not part of it. We could even link against something proprietary during the build and this would still be fine. The LGPL allows linking against non LGPL code, as long as the LGPL part can be replaced with a self compiled version.
https://bugs.winehq.org/show_bug.cgi?id=45391
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #2 from Forest forestcode@ixio.org --- Thanks, Michael. Yours is the first constructive response I've found from anyone, after weeks or months of multiple people asking about this problem.
With respect to the license and the intent of the LGPL, it seems worth pointing out that reproducing binary packages requires more than access to wine's git repo. At the very least, it requires knowing exactly what build configuration options were used, and what wine changeset was checked out for the build. In the vast majority of binary packages that I've seen, there are quite a few additional components involved, including patches, install scripts, distribution-specific dependencies, and the like. I don't fancy myself an expert in how the LGPL is interpreted, but from a purely task-oriented perspective, all of these things are parts of the source code for a binary package, yet none of them have been made known to the people to whom the binaries are being distributed.
https://bugs.winehq.org/show_bug.cgi?id=45391
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #3 from Fabian Maurer dark.shadow4@web.de --- Now, IANAL, but these are my 5 cents:
it seems worth pointing out that reproducing binary packages requires more than access to wine's git repo.
Sure, but I doubt reproduceable builds are a requirement of the LGPL. You only need the source code to make the program, and that's available. I personally wouldn't consider the buildsystem a part of the programs source code.
That said, I'd be in favor for making the build process transparent, too.
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #4 from Forest forestcode@ixio.org ---
You only need the source code to make the program, and that's available.
None of winehq's packages are accompanied by a statement identifying the git changeset or build configuration options required to make the packaged program. Without those things, you're expecting a user who wants to modify what you sent him to first find a needle in a haystack and reverse engineer the build. So, I suppose you might be technically correct in saying that the source code is "available", in the same sense that one Mr. Prosser was correct in a certain novel.
“But the plans were on display…” “On display? I eventually had to go down to the cellar to find them.” “That’s the display department.” “With a flashlight.” “Ah, well, the lights had probably gone.” “So had the stairs.” “But look, you found the notice, didn’t you?” “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
I'd be in favor for making the build process transparent, too.
Cheers.
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #5 from Austin English austinenglish@gmail.com --- As Michael said, the source used is unmodified, so your concerns about patching are irrelevant. Either the wine or wine-staging tarball, as appropriate, can be used with the provided build scripts.
Insert obligatory statement that I'm in favor of a more open process here.
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #6 from Forest forestcode@ixio.org --- Okay, I took the time to investigate and report a problem that several others have been struggling with, but I'm now tired and discouraged by the dismissive comments. I think I'm done here. Thanks again for the info, Michael. I hope someone shares it someplace visible.
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #7 from Austin English austinenglish@gmail.com --- I think a request to provide source packages is valid (and we could rename the bug as such). That doesn't mean there's a license violation, however.
What do others think?
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #8 from Rosanne DiMesio dimesio@earthlink.net --- There's already a bug requesting source packages for Debian (bug 39782). One of the comments in it has instructions for creating a source package using the scripts published on https://github.com/wine-compholio/wine-packaging, but those instructions were written before the move to the current build system, so I don't know if they are still valid.
https://bugs.winehq.org/show_bug.cgi?id=45391
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #9 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Austin English from comment #7)
I think a request to provide source packages is valid (and we could rename the bug as such). That doesn't mean there's a license violation, however.
What do others think?
I think there is no violation of the LGPL and this bug should be marked INVALID.
I agree with Michael Müller on the extents of the LGPL.
The tool chain used for the making of the modified binaries is irrelevant to the LGPL license of the modified software. [1]
The packages are binary archive files. They are not object code or executable. They are not a derivative work of the software they contain and are not subject to the source code requirement.
As far as I can tell the LGPL makes no provision on the toolchain used to build the binaries. They can be built with any tools, even non-public proprietary ones that are available to nobody but the one who build the modified binaries.
The only LGPL requirement is that the source code must be sufficient to build a binary that can replace the distributed one in term of functionality. That's all. Compile flags, optimization and such is not covered by the LGPL.
Other people have to deal with the source code themselves.
Since the wine source code is available and it can be used "as is" to build binaries that can be packaged in .deb files, the requirements of the LGPL are met, IMO.
Only the copyright holders can act against violations of their copyrights. [2]
As a wine contributor, I know that my code and any modification to it is in the source tree, and since the winehq.org packages are built from the source tree, I see no violation of the LGPL.
The OP cannot invoke violation of the LGPL if he's not a copyright holder of a LGPL'd library.
[1] "Which programs you used to edit the source code, or to compile it, or study it, or record it, usually makes no difference for issues concerning the licensing of that source code." https://www.gnu.org/licenses/gpl-faq.en.html#NonFreeTools
[2] "Note that the GPL, and other copyleft licenses, are copyright licenses. This means that only the copyright holders are empowered to act against violations." https://www.gnu.org/licenses/gpl-violation.en.html
https://bugs.winehq.org/show_bug.cgi?id=45391
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED
--- Comment #10 from Rosanne DiMesio dimesio@earthlink.net --- Marking duplicate per comments 7 & 8.
*** This bug has been marked as a duplicate of bug 39782 ***
https://bugs.winehq.org/show_bug.cgi?id=45391
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Rosanne DiMesio dimesio@earthlink.net --- Closing duplicate.
https://bugs.winehq.org/show_bug.cgi?id=45391
--- Comment #12 from Forest forestcode@ixio.org --- For the record, Section 0 of LGPL-2.1 says this:
""" "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. """
The phrase "scripts used to control compilation and installation of the library" is relevant here. Anyone who still thinks that build scripts and packaging files are not covered might want to contact the FSF for clarification.
For what it's worth, the GPL FAQ reinforces the above:
""" GPLv3 explicitly requires redistribution to include the full necessary “Installation Information.” GPLv2 doesn't use that term, but it does require redistribution to include "scripts used to control compilation and installation of the executable" with the complete and corresponding source code. """
https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html https://www.gnu.org/licenses/gpl-faq.html#InstInfo
-
wine-bugs＠winehq.org -
WineHQ Bugzilla