From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9D348138247 for ; Thu, 2 Jan 2014 12:41:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8825EE0B19; Thu, 2 Jan 2014 12:40:58 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 82004E0AFD for ; Thu, 2 Jan 2014 12:40:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D66BE33F68B for ; Thu, 2 Jan 2014 12:40:56 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5.5 tests=[AWL=-0.981, RP_MATCHES_RCVD=-0.137, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2560sBo9smuI for ; Thu, 2 Jan 2014 12:40:48 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id AFC7133F737 for ; Thu, 2 Jan 2014 12:40:45 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VyhZr-00022d-Gp for gentoo-dev@gentoo.org; Thu, 02 Jan 2014 13:40:43 +0100 Received: from 71-17-69-121.yktn.hsdb.sasknet.sk.ca ([71.17.69.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jan 2014 13:40:43 +0100 Received: from dirtyepic by 71-17-69-121.yktn.hsdb.sasknet.sk.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jan 2014 13:40:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: RFC: new global USE flag "srcdist" Date: Thu, 2 Jan 2014 06:50:06 -0600 Organization: Gentoo Message-ID: <20140102065006.59a2bad9@caribou.gateway.pace.com> References: <21188.38566.180273.751353@a1i15.kph.uni-mainz.de> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/uaaPM44k9H0tauxNI=gVu7y"; protocol="application/pgp-signature" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 71-17-69-121.yktn.hsdb.sasknet.sk.ca X-Newsreader: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) X-Archives-Salt: 9fef8f91-6563-4056-9377-78724215143b X-Archives-Hash: 1646f45e1569e88cd41530b5dd403d1a --Sig_/uaaPM44k9H0tauxNI=gVu7y Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 1 Jan 2014 23:28:54 +0100 Ulrich Mueller wrote: > Hi, > According to GLEP 23 [1], the LICENSE variable regulates the software > that is installed on a system. There is however some ambiguity in > this: should it cover the actual files installed on the system, or > everything that is included in the package's tarball? This question > was asked several times in the past and arose in bug 492424 [2] again. >=20 > I've always preferred the first interpretation, because the second one > would inevitably require us to repack many tarballs, in order to keep > their license in @FREE. This would for example include the Linux > kernel, where we could no longer use deblobbing, but would have to > provide our own tarball with firmware blobs removed. Not sure if users > would be happy if we wouldn't install from pristine sources any more. > We also have mirror and fetch restrictions which allow us to control > what tarballs we distribute, independent of the LICENSE variable. I've always believed that when it comes down to it all Gentoo basically does is provide a link to some source code and a script to build and install it. Unless we violate someone's license by redistributing that source then we r= eally don't have to worry about it, and as you said we already have mechanisms to deal with that. What the user does with that source is their business, and they are solely responsible for following the terms of the license(s). IIRC this is the stance we took back in 2006 with the cdrtools debacle [1]. So I don't understand why we would have to remove anything from the tarball= s. Unless there's a license in there that forbids mirroring then there's no ne= ed to list other licenses that aren't relevant. The user wants to know what conditions he needs to follow to build and use the package, not what the tarball happen to contain. If you tell him that he can't install something because of a license on a piece of code that is never used, built, or installed, he isn't going to be very happy. > Within existing EAPIs we have only one LICENSE variable available. > (Extending it would be possible in future EAPIs, but we would end up > with a very long transition period.) USE conditional syntax is allowed > in LICENSE, though. So I wonder if this couldn't be used for the > intended purpose. For example, for specifying licenses of distfiles: >=20 > LICENSE=3D" > srcdist? ( )" >=20 > This idea was discussed within the licenses team, and the overall > reaction was positive. >=20 > What do you think? Wouldn't that just prevent you from installing the package altogether? Some people might be okay with that, but if it's a package you need then you are forced to choose between either disabling the USE flag or stop filterin= g the license for that package. Either way you end up with non-distributable stuf= f in your distfiles. Maybe we could add RESTRICT=3Dsrcdist which would cause ebuilds to save their distfiles in a separate directory controlled by PORTDIR_NODIST or something. If the variable is unset then it's business as usual. --=20 Ryan Hill psn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 --Sig_/uaaPM44k9H0tauxNI=gVu7y Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCgAGBQJSxWCDAAoJEO04vUmVeoRjiwQIALzH6XC5+2PO30wa9Qni2Rb6 NzKY4buSHpgxwwsogStpfbHSbJ68JHAkWDZCs7rOD9DhfL9TYMikDFmayYWXxJmZ TOys8GmIVZw9qcAXtjO9dZtQk8gylEIsdSHhWhUGGuPYe8U+3d/b6p3xQicPUVgA KyealUJD09EAewY9SfvOyJfkAJkP7YfdI6HXqm9EotWbnkj3x+6H7v9rX8ApVhM9 QyFANcPwrNay6GjAvieFzpJfdC+EYPNIFq/tlhR6vmFojW3Pp1aGd6l6qDMi4O5Q uGhSqNqXFoEldWikx2BuOJuhiapznqkqZ2+VEYIr9OP5ElxxArrwHeeAXKN/3QA= =aIXw -----END PGP SIGNATURE----- --Sig_/uaaPM44k9H0tauxNI=gVu7y--