Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 524584 - dev-qt/qtwebkit: redistribution of non-free redistribution disallowed images
Summary: dev-qt/qtwebkit: redistribution of non-free redistribution disallowed images
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Licenses team
URL:
Whiteboard:
Keywords:
Depends on: 524518 qtwebkit4-removal
Blocks:
  Show dependency tree
 
Reported: 2014-10-06 02:58 UTC by Mart Raudsepp
Modified: 2018-01-13 00:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mart Raudsepp gentoo-dev 2014-10-06 02:58:00 UTC
See https://lists.webkit.org/pipermail/webkit-gtk/2014-October/002093.html
We are redistributing on our mirrors the following files that we must not:

webkitgtk-2.2.6.tar.xz
webkitgtk-2.4.4.tar.xz

2.4.6 is clean, but 2.2.6 is last stable on arm for both SLOTs and 2.4.4 is last stable on every other arch.
We need to hurry up 2.4.6 stabilization or more realistically convert old ebuilds with same keywords on a revbump to the "a" suffixed tarballs as explained in the upstream mailing list post.
Comment 1 Mart Raudsepp gentoo-dev 2014-10-06 03:00:39 UTC
This was also CCed to distributor-list@gnome.org, we should follow it better :)
Comment 2 Pacho Ramos gentoo-dev 2014-10-06 09:29:43 UTC
I followed it... but I needed near a night for compiling 2.4.6 for both slots on my laptop, later I bumped it but didn't call for fast stabilization as I wanted to give it at least a week to catch any new problems that could appear and also to try to drop more stable keywords due arches other than amd64/x86 being really really slow to stable it (we depend in ago's availability for them)
Comment 3 Ulrich Müller gentoo-dev 2014-10-06 09:35:19 UTC
In the meantime, could 2.2.6 and 2.4.4 be mirror restricted, please?
Comment 4 Pacho Ramos gentoo-dev 2014-10-06 09:42:54 UTC
+  06 Oct 2014; Pacho Ramos <pacho@gentoo.org> webkit-gtk-2.2.6-r200.ebuild,
+  webkit-gtk-2.2.6.ebuild, webkit-gtk-2.4.4-r200.ebuild,
+  webkit-gtk-2.4.4.ebuild:
+  Restrict mirror for old versions due bug 524584
+
Comment 5 Mart Raudsepp gentoo-dev 2014-10-06 10:31:56 UTC
They promise the a suffixed tarballs have no other changes. We should just revbump each with same keywords and use the suffixed tarball if it comes to restricting mirroring otherwise (which is understandable).
With the mirror restriction effectively webkit-gtk is not installable on any architectures stable tree at the moment. These bad tarballs are not available anywhere else for manual fetching.
Comment 6 Mart Raudsepp gentoo-dev 2014-10-06 10:32:42 UTC
That is, SRC_URI target does not exist anymore either; RESTRICT=mirror will wipe them out of our mirrors too (which we do need to do)
Comment 7 Pacho Ramos gentoo-dev 2014-10-06 10:38:54 UTC
+  06 Oct 2014; Pacho Ramos <pacho@gentoo.org> webkit-gtk-2.2.6-r200.ebuild,
+  webkit-gtk-2.2.6.ebuild, webkit-gtk-2.4.4-r200.ebuild,
+  webkit-gtk-2.4.4.ebuild:
+  Upstream also dropped the old tarballs (#524584#c6)
+

Revert that then, but I don't have just now time to rebuild all them to verify we can bump them safely (not sure if bumping them "blindly" would be safe...)
Comment 8 Mart Raudsepp gentoo-dev 2014-10-06 11:15:30 UTC
I still had 2.4.4. I'll do a 2.4.4-r1 locally with the only change in SRC_URI.
If that goes fine, I'll just do the same for everything and commit revbumps at same keywords (to get people off of the non-redistributable images) blindly.
I'm sure people will love us for a stable revbump just for that.
Off for 1-3 hours now on business, it will be building meanwhile
Comment 9 Ulrich Müller gentoo-dev 2014-10-06 12:20:39 UTC
(In reply to Pacho Ramos from comment #7)
> Revert that then, but I don't have just now time to rebuild all them to
> verify we can bump them safely (not sure if bumping them "blindly" would be
> safe...)

I fear the mirror restriction must stay in place, even if that means that tarballs cannot be downloaded by users any more. The tarball contains copyrighted material that is not redistributable, and from the link posted in comment #0, I conclude that the copyright holder (which happens to be Apple) has been informed of the copyright violation.

We are also aware of the situation now, so if we continue redistributing the tarballs then it could be argued that we are no longer acting in good faith.

Disclaimer: IANAL, TINLA.

CCing trustees.
Comment 10 Ulrich Müller gentoo-dev 2014-10-06 12:25:54 UTC
OTOH, I wonder what these guys at Apple Computer thought, declaring their Webkit project as Open Source (see http://www.webkit.org/) and then hiding such an easter egg of copyrighted material deeply in it. :(
Comment 11 Mart Raudsepp gentoo-dev 2014-10-06 14:12:04 UTC
I have committed revbumps with equal keywords for each version and SLOT, that uses the fixed tarballs, and immediately removed the previous revisions. So from GNOME's side, we should be done, but licensing/trustees and Gentoo collectively should probably check the following:

1) Make sure the bad tarballs leave our mirroring system, potentially speeding that process up if needed?
2) Check all the other webkit libraries we have in our trees for the same issue and handle any issues found appropriately

To that effect, I'll leave the bug open. licenses@ might want to reassign to self, or create a clone bug for this.
I will try to help a bit with 2) though, preferably collaborating over IRC if appropriate.
Comment 12 Mart Raudsepp gentoo-dev 2014-10-06 14:15:47 UTC
Oh, and to avoid any doubt these images from old revisions were present in a supposedly free software library:

webkit-gtk optimizes the images into the library itself via the GResource system instead of having them all as separate files in the filesystem, so you can't find them via qlist or similar -- https://developer.gnome.org/gio/stable/gio-GResource.html

You can see them present there with e.g

gresource list /usr/lib64/libwebkitgtk-3.0.so.0 |grep UserInterface/Images
gresource list /usr/lib64/libwebkit2gtk-3.0.so |grep UserInterface/Images
Comment 13 Ulrich Müller gentoo-dev 2014-10-06 15:25:35 UTC
(In reply to Mart Raudsepp from comment #11)
> I have committed revbumps with equal keywords for each version and SLOT,
> that uses the fixed tarballs, and immediately removed the previous
> revisions. So from GNOME's side, we should be done,

Thanks.

> but licensing/trustees and Gentoo collectively should probably check the
> following:
> 
> 1) Make sure the bad tarballs leave our mirroring system, potentially
> speeding that process up if needed?

CCing infra for this.

> 2) Check all the other webkit libraries we have in our trees for the same
> issue and handle any issues found appropriately
> 
> To that effect, I'll leave the bug open. licenses@ might want to reassign to
> self, or create a clone bug for this.
> I will try to help a bit with 2) though, preferably collaborating over IRC
> if appropriate.
Comment 14 Mart Raudsepp gentoo-dev 2014-10-06 16:16:01 UTC
(In reply to Mart Raudsepp from comment #11)
> 2) Check all the other webkit libraries we have in our trees for the same
> issue and handle any issues found appropriately

Pretty sure qtwebkit-opensource-src-5.3.2.tar.xz has similar problems. Some of the SVG files are a bit different XML, but carry a copyright notice and the Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf file is also present.

The webkit fork in qt-everywhere-opensource-src-4.8.5.tar.gz src/3rdparty/webkit/Source/WebCore/inspector/front-end/Images is less obvious. It might be an earlier iteration of those icons in there and really have the issue, but I can't find any apple license file in there to claim different license than the whole. Though what license files happen to claim might not necessarily reflect reality. Visually they look somewhat similar, but differently sized and relatedly different level of visual detail. Unfortunately I can't really look through 132 image files right now, as can't exactly byte-compare PNG files and claim difference in face of pngcrush, new files being in original SVG form and whatnot.
Comment 15 Mart Raudsepp gentoo-dev 2014-10-06 16:17:57 UTC
Forgot to CC qt@.
qt: You need to fix licensing issues discussed above (do not mirror qtwebkit-5.3.2) and hopefully help identifying the situation with qtwebkit-4.8.5
Comment 16 Davide Pesavento gentoo-dev 2014-10-06 21:53:22 UTC
Would RESTRICT=mirror in all dev-qt/qtwebkit versions in tree be enough?
Comment 17 Ulrich Müller gentoo-dev 2014-10-07 05:23:03 UTC
(In reply to Davide Pesavento from comment #16)
> Would RESTRICT=mirror in all dev-qt/qtwebkit versions in tree be enough?

qtwebkit-5.3.2 should be mirror restricted, and the issue should be sorted out upstream.

For qtwebkit-4.8.5 we need to know where the icons originate from and if we can distribute them (and under what license). If it turns out that they are not redistributable, then all packages using the qt-everywhere-opensource-src-4.8.5.tar.gz tarball would have to be mirror restricted.
Comment 18 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2014-10-07 06:29:12 UTC
<hat type="infra">
Files removed from primary mirror, please allow some hours for propagation.
</hat>
Comment 19 Davide Pesavento gentoo-dev 2014-10-07 16:24:36 UTC
(In reply to Ulrich Müller from comment #17)
> qtwebkit-5.3.2 should be mirror restricted, and the issue should be sorted
> out upstream.

  07 Oct 2014; Davide Pesavento <pesa@gentoo.org> qt5-build.eclass:
  Restrict mirror for qtwebkit wrt bug #524584
Comment 20 Ulrich Müller gentoo-dev 2014-10-08 05:02:30 UTC
(In reply to Davide Pesavento from comment #19)
>   07 Oct 2014; Davide Pesavento <pesa@gentoo.org> qt5-build.eclass:
>   Restrict mirror for qtwebkit wrt bug #524584

This doesn't look correct:

[[ ${PN} == qtwebkit ]] && RESTRICT="mirror" # bug 524584
[[ ${QT5_BUILD_TYPE} == release && ${QT5_MINOR_VERSION} -le 3 ]] && RESTRICT="test" # bug 457182

For qtwebkit-5.3.2-r1 the second test evaluates as true, so RESTRICT will be overwritten again.
Comment 21 Davide Pesavento gentoo-dev 2014-10-09 16:57:13 UTC
(In reply to Ulrich Müller from comment #20)

You're right, sorry. Should be fixed now.
Comment 22 Ulrich Müller gentoo-dev 2014-10-11 10:33:20 UTC
CCing infra again. Please remove also the following file from mirrors:

qtwebkit-opensource-src-5.3.2.tar.xz
Comment 23 Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2014-10-11 13:39:00 UTC
(In reply to Ulrich Müller from comment #22)
> CCing infra again. Please remove also the following file from mirrors:
> 
> qtwebkit-opensource-src-5.3.2.tar.xz

With my infra hat on, file removed from master mirror. Please wait a few hours for propagation.
Comment 24 Mart Raudsepp gentoo-dev 2014-12-29 13:43:25 UTC
Any news on qt4 situation..?
Comment 25 Davide Pesavento gentoo-dev 2015-01-08 23:29:10 UTC
(In reply to Mart Raudsepp from comment #24)
> Any news on qt4 situation..?

No. I contacted upstream ~3 months ago but received no reply.
Comment 26 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2016-03-27 23:08:14 UTC
Nothing further for the trustees here.
Comment 27 Davide Pesavento gentoo-dev 2018-01-13 00:45:02 UTC
(In reply to Mart Raudsepp from comment #24)
> Any news on qt4 situation..?

qtwebkit:4 has been treecleaned, so I suppose we can close this one.