[gentoo-dev] Should mirror restriction imply bindist restriction?

[gentoo-dev] Should mirror restriction imply bindist restriction?

[Ulrich Mueller]

Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
other. I wonder if the former should imply the latter.

Is there any package where the files in SRC_URI cannot be mirrored
(i.e., redistributed), but where the built package can be distributed?

Ulrich

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Peter Stuge]

Ulrich Mueller wrote:
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?

All of them, when distributing binaries within a legal entity.


//Peter

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 12:05 PM, Ulrich Mueller wrote:
> Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
> other. I wonder if the former should imply the latter.
> 
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?

I agree with you entirely, but there is one major bit of information
missing... What exactly does RESTRICT=bindist do?  AFAICT it does
exactly nothing.  If we are going to address merging the two restriction
(which I'm all for) then we might want to have it documented how it all
works.

thanks,
Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJReql9AAoJEKXdFCfdEflKn0YP/i1/pcwQsFqpsOvqzt+/NiEZ
GeAq+K80/ai7OouZt6OYOye72hv6eGISlIGYtDDoZ5RumatLl3cRF2iwXwnAiAMb
h99s4xpiMLuf2q2F9OJ8ekK/FDI6PIRdCqJmNLiGukvPrQG8w8/u6tSk3fo2s7px
y4vLN6A4E6MhgbJYAyliCjGRTzipbuVeKI5blV8TtqOJ6OqUbpm4ZhRteQ0b3S9T
NO4AMklJ+qvSKTRqbcUpJ83skkZLcuTIhsud2UWUf50y0Z0dnn/aU4yzT3DsjTV6
gW9NrOK3Dyacdelc3YN/wu7xYWkn7qolwKw26MkyBXseg65PaeqPSvF9ZOkcusRj
8hBRDBugbc7BGZsEpM0z+4JDsfAgdgNtSOOeAaX8OeXliQ7TLKKqugL8puE2tHft
RF0L+yFZgmJFPcsGS+Gk11Rg4fcWz56sKCYsLI3zyxmUdfWfjo91MHKfTdnn98Vj
n1baRWlq2Yb7CcFxKevdIByCqXLoLe0SbdNKbx7mF0S+RRybeFxgVwODGYCePm5U
cSIXb1KmVw/I08dqHWKrnhYCv7/7/D1WU0zofnXxQGiS/UfHcHmH4M6b6rz76VPO
d93ufZ1/SXHAfWKnfNiinbHmXU2zKE+xsj0MmNk9JUI2BDC2PkZkKVImunCZF4ES
4+iDcW6jQ6FHpFO62/es
=UU/A
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Jeroen Roovers]

On Fri, 26 Apr 2013 12:21:17 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> I agree with you entirely, but there is one major bit of information
> missing... What exactly does RESTRICT=bindist do?  AFAICT it does
> exactly nothing.  If we are going to address merging the two
> restriction (which I'm all for) then we might want to have it
> documented how it all works.

# quickpkg x11-drivers/nvidia-drivers
 * x11-drivers/nvidia-drivers-304.88: package has RESTRICT=bindist!
 * x11-drivers/nvidia-drivers-304.88: it might not be legal to
redistribute this.
 * Building package for
   x11-drivers/nvidia-drivers-304.88 ...                   [ ok ]

It issues a severe warning against distributing the built package.

use.desc:bindist - Flag to enable or disable options for prebuilt
(GRP)  packages (eg. due to licensing issues)

*cough* bug #460460 *cough*


    jer

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 12:56 PM, Jeroen Roovers wrote:
> On Fri, 26 Apr 2013 12:21:17 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> I agree with you entirely, but there is one major bit of information
>> missing... What exactly does RESTRICT=bindist do?  AFAICT it does
>> exactly nothing.  If we are going to address merging the two
>> restriction (which I'm all for) then we might want to have it
>> documented how it all works.
> 
> # quickpkg x11-drivers/nvidia-drivers
>  * x11-drivers/nvidia-drivers-304.88: package has RESTRICT=bindist!
>  * x11-drivers/nvidia-drivers-304.88: it might not be legal to
> redistribute this.
>  * Building package for
>    x11-drivers/nvidia-drivers-304.88 ...                   [ ok ]
Honestly in my life I've never used quickpkg to generate a package,
portage just builds packages for me with FEATURES=buildpkg.  Glad to
know there is a warning for quickpkg users at least.

I think it needs to be a bit more severe than that though.  Catalyst has
a feature for bindist, as does portage, but niether seem to care at all
about RESTRICT=bindist enforcement at all.  I see this as something to
be improved upon, if I tell portage/catalyst that I am going to bindist
the package it shouldn't allow me to build restricted things at all.
> 
> It issues a severe warning against distributing the built package.
> 
Yes warnings are nice, but building a few thousand packages a day I
honestly don't read all the warnings...  I trust that when I tell
portage/catalyst I am going to bindist that it would attempt to help
keep me on the right side of the law.  It is simple enough to disable
bindist if I want to, well you know, distribute the binary illegally.

- -ZC

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRerXeAAoJEKXdFCfdEflKm7IQALMZstOAU+8lL6+yfxPxhlP7
Q3lN0EUxu/bXwQLXj7XS52NOqUopBrK99JbLCfdvSqrNO7wtDyyXVvv6pNkt8a5h
5LBGm9kyLZ3fEiy4YuKk9TNbvEr8EeFfBAZD69MEwutkUoPMU0UpNXXDFAdLgw0I
w+iabf11ltvBwOSUC7qb0m37lWJZyMzvvtKFmrqgd4U7k4VTLtJNrQBAbiiJj1QT
O6boLbWQvfJqOzlzoTEtv01EjSaV+Bl13daVQYOX+YboVBQlJHqJAeLgUZRR5jss
mhLWG5r/0LXSm1fvjCtvhy3aWj7BMwAxOanCUCZiYRmQkgqPh/pPsniA0lu6XdjP
vv4LJND6qfc52fivbfrbPmCHJ3tehXgs7Tikwee2vBHoeCbKKFvHoLwzxwhmGnDs
BCrmDN/BbaS2+1+L6gVwYE/ZMreKe8L6RdsI8Kwwp7gYsZbsR1E56SuzO46+zAjs
T2uIetXfJnM82sE/8YZ76CUg5dPld95edKGxPHcfeqCQr2XXcqjWVlHCFuShrvTA
gHDnLV/eVCvakhQY/tTnGgtxUcEkP9hj6tJzaW7sK8wsen1/sVa/EtVtppPfrKpI
s3wKAHLzzw+R+IfI3rFsyEIulpp9NS3Vlx3WkTmJmGx67GvlH+102j0xW0VLCZUo
vs4wUfqjp46R/MvPa2/3
=lrxt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Jeroen Roovers]

On Fri, 26 Apr 2013 13:14:07 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> Yes warnings are nice, but building a few thousand packages a day I
> honestly don't read all the warnings...  I trust that when I tell
> portage/catalyst I am going to bindist that it would attempt to help
> keep me on the right side of the law.  It is simple enough to disable
> bindist if I want to, well you know, distribute the binary illegally.

ebuild(5):
              bindist
                     Distribution of built packages is restricted.


That means you shouldn't do it. But maybe you're right. emerge/catalyst
should be able to distinguish right from wrong, not you.


     jer

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:
> Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
> other. I wonder if the former should imply the latter.
>
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?

I vaguely remember some cases of large proprietary packages which were
legal to redistribute, but we did not want them on Gentoo mirrors. After
all, the description according to ebuild(5) does not contain a reference
to what you can or cannot do:
mirror
     files in SRC_URI will not be downloaded from the GENTOO_MIRRORS.

Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 01:15 PM, Jeroen Roovers wrote:
> On Fri, 26 Apr 2013 13:14:07 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> Yes warnings are nice, but building a few thousand packages a day I
>> honestly don't read all the warnings...  I trust that when I tell
>> portage/catalyst I am going to bindist that it would attempt to help
>> keep me on the right side of the law.  It is simple enough to disable
>> bindist if I want to, well you know, distribute the binary illegally.
> 
> ebuild(5):
>               bindist
>                      Distribution of built packages is restricted.
> 
> 
> That means you shouldn't do it. But maybe you're right. emerge/catalyst
> should be able to distinguish right from wrong, not you.

Maybe I'm being too simplistic here but when I wrote the FEATURE=bindist
for catalyst the intent was to help the user maintain an obviously
desired compliance to law and legally redistribute what they are making.
 There are numerous packages that have USE=bindist to allow legal
redistribution of content, honestly I'm a bit surprised to hear that I'm
supposed to read every ebuild to see that a package has
RESTRICT=bindist... emerge certainly doesn't seem to care.

RESTRICT=bindist really needs to be more assertive, especially if the
user has USE=bindist set.  A warning from quickpkg simply isn't enough
here in my eyes.

The user is distinguishing right from wrong by setting things like
USE=bindist, portage simply doesn't seem to be respecting that in the
case of RESTRICT=bindist.  It seems simple enough to me for portage to
check the environment and refuse to build packages with RESTRICT=bindist
when USE=bindist is set... I mean it's supposed to RESTRICT me from
bindist and I'm telling portage I intend to bindist....

- -ZC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJResfIAAoJEKXdFCfdEflKCWIQAK4Zp7z9nGjdALm/SaliBiZR
j0/obRd0x6iI9WbAiaUxM5dIx2D9yNdSl+2951uHlJRahtzVakPLk6GKzDkl78uq
Rg/5guvZIvCp+ey+HxNpbSRKAkGPIF6zrBp70JyhBUyQmiaxj2ebXci12oNmtZ1Z
HBdBG9Y4rRsRspPKqqgRIdP0ssA+0ZWCJUltGA1KTHj7JFGPimY45glBmYje5rhL
HT+M5hR/mgkaWASCtGmwI63LZd95ngwbNqImO1rD44QfZT56l022pZ2WrG363VL9
6YKU3uPxIPx4jGqAIMnM8DxCP70F5kNFgK3OY35G+8QmCflR4whPntbAXbk5PGbQ
KArn1nPOCvlzdnlnqPIXgfFkzi1YaA21SWJQj5wQdLVqro05tDj1pXIqsNg+gryu
s6c21adGK8LuJo8vV21qX3nwokpfkFgCSldPHQzRWznV9/ll+93fZKAAptTzq0rU
iQhKSGGEUU+vu+OV11EWTraP7BtoDepi5EMDngjGqup2LH0NgSVxRhuYBzJUhtP5
3mrjS5X9c77T10JXXdce26xcC7GWILHQtmLhghfnChYhiEw+Axa3j3n6ChwjOQ0u
GCDAmrb9fQzCyO5cxgObiZ/BUH6C/I1/yTerUh1JYs43+bflRxwJc5B2xOipEfjB
WcP5nzk/6FgqEVsR++gG
=+vLg
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rich Freeman]

On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> The user is distinguishing right from wrong by setting things like
> USE=bindist, portage simply doesn't seem to be respecting that in the
> case of RESTRICT=bindist.

I think what is missing is a clear set of definitions.

USE=-bindist means build a package that the maintainer thinks isn't
legal to distribute under some set of circumstances (which might or
might not be the user's circumstances).

RESTRICT=bindist in an ebuild means what?  Let's look at the devmanual:
RESTRICT - A space-delimited list of portage features to restrict.
Valid values are fetch, mirror, strip, testand userpriv. See man 5
ebuild for details.
man 5 ebuild:
bindist - Distribution of built packages is restricted.

And how does a user tell portage whether they intend to redistribute
something in the first place?  The fact that an ebuild sets
RESTRICT=bindist does not have anything to do with whether it will in
fact be redistributed.  It sounds like we would need a
FEATURES=bindist to go along with it.  Oh, and it sounds like
RESTRICT=bindist often should be conditional based on USE=-bindist,
but you can't set RESTRICT conditionally, so that won't work.

Also, isn't all of this somewhat redundant with ACCEPT_LICENSE?  It is
the license that allows you to redistribute something in the first
place, though with some licenses it might be conditional upon how the
package is built/branded.

The last thing we need on any of this stuff is a hard error.  What is
needed first is for those who care about such things to cleanly
specify a sane set of definitions and behavior.

Rich

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 669 bytes --]

On Friday 26 April 2013 12:05:10 Ulrich Mueller wrote:
> Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
> other. I wonder if the former should imply the latter.
> 
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?

i've used RESTRICT=mirror in the past when the files were really large (like 
games or toolchain source tarballs) and upstream already had a good mirroring 
system.  in both cases, there was no binary redistribution restrictions.

so my answer would be no: we have two independent knobs and let's keep them 
that way.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 02:44 PM, Rich Freeman wrote:
> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina
> <zerochaos@gentoo.org> wrote:
>> The user is distinguishing right from wrong by setting things like
>> USE=bindist, portage simply doesn't seem to be respecting that in the
>> case of RESTRICT=bindist.
> 
> I think what is missing is a clear set of definitions.
> 
> USE=-bindist means build a package that the maintainer thinks isn't
> legal to distribute under some set of circumstances (which might or
> might not be the user's circumstances).
> 
> RESTRICT=bindist in an ebuild means what?  Let's look at the devmanual:
> RESTRICT - A space-delimited list of portage features to restrict.
> Valid values are fetch, mirror, strip, testand userpriv. See man 5
> ebuild for details.
> man 5 ebuild:
> bindist - Distribution of built packages is restricted.
> 
> And how does a user tell portage whether they intend to redistribute
> something in the first place?  The fact that an ebuild sets
> RESTRICT=bindist does not have anything to do with whether it will in
> fact be redistributed.  It sounds like we would need a
> FEATURES=bindist to go along with it.  Oh, and it sounds like
> RESTRICT=bindist often should be conditional based on USE=-bindist,
> but you can't set RESTRICT conditionally, so that won't work.
> 
> Also, isn't all of this somewhat redundant with ACCEPT_LICENSE?  It is
> the license that allows you to redistribute something in the first
> place, though with some licenses it might be conditional upon how the
> package is built/branded.
> 
> The last thing we need on any of this stuff is a hard error.  What is
> needed first is for those who care about such things to cleanly
> specify a sane set of definitions and behavior.
> 
I really appreciate your input here, I think you may be onto something.
 Maybe the best thing to do would be to drop RESTRICT=bindist entirely
and just make a new license group for it? Maybe it would even be
possible to automatically ACCEPT_LICENSE=bindist when USE=-bindist and
vice-versa?  This seems a more productive direction than anything I was
able to come up with.

Thanks!
Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRetB0AAoJEKXdFCfdEflKpJUP/jvGcTA7K+i/22ljUmVCqb5/
aVperRWG1lpPOoLWZHsZG8/ic9+F0O0gEYQEx4yBObZFQGU10D8DiLzVdyKh2J83
pxIC+pNC4vlgjAIznq1pl5YvIJ/JOmU3G05JIdxWYg17IGYDuy08IJc0g6LGSGpQ
dkNNdsAd8D3Xx9+SfFXl1cpzu8qfjzOubSdBpkdDuKR4fvorar4p9dT5ruWDW4KZ
Rt+n0DOSGyWSGpB0KNhOJIbkVjbW0oPnYmsosbmYkfF/dN0eYE9Zyb5E7hgOT9c6
WWF9Lg0f16xcjJS0RnZ/4PbzNYNfjIf/bx9KXfR5wQFpqEnhzK/oMqUs12JnHL3r
4mdzg/DG6jfBsO+IlyTP+2P4NUQVjSKZXC/gPDgSG4U7PpcE7ZtDqO+A/An3jxcG
5BBA1ZoTx4dEPLSqlau1+MKLIWQ2xl5ei8Y9PrWvZd0fGTZxwmWKb667AgyI94ar
83g6gprPM2EXnAyH1G0Krdt44aEccjfgjqyf0dOX/hUh64kvILxvdCrNxTqGjvQq
z2OkluSyzUF7cHa5MxOcqPaetDwsFdCeV85PJ3q0vPm//saLX6TlnD6bzB+ynNXl
JhZH+6qKbifIjPdVvq1GkXMDzF5/KSE6YUyHTXbQOhBBhLh6PgosE/81H1P55ZxG
lvcW5DWzwl72B7KkI8/9
=ssUj
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Ulrich Mueller]

>>>>> On Fri, 26 Apr 2013, Mike Frysinger wrote:

>> Currently RESTRICT=mirror and RESTRICT=bindist are independent of
>> each other. I wonder if the former should imply the latter.
>> 
>> Is there any package where the files in SRC_URI cannot be mirrored
>> (i.e., redistributed), but where the built package can be
>> distributed?

> i've used RESTRICT=mirror in the past when the files were really
> large (like games or toolchain source tarballs) and upstream already
> had a good mirroring system. in both cases, there was no binary
> redistribution restrictions.

> so my answer would be no: we have two independent knobs and let's
> keep them that way.

Right. And as was pointed to me on IRC, another legitimate case for
mirror restriction are packages in overlays whose distfiles are not on
mirrors. Then it obviously makes no sense to check mirrors for it.

Ulrich

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/04/13 03:07 PM, Rick "Zero_Chaos" Farina wrote:
> On 04/26/2013 02:44 PM, Rich Freeman wrote:
>> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina 
>> <zerochaos@gentoo.org> wrote:
>>> The user is distinguishing right from wrong by setting things
>>> like USE=bindist, portage simply doesn't seem to be respecting
>>> that in the case of RESTRICT=bindist.
> 
>> I think what is missing is a clear set of definitions.
> 
>> USE=-bindist means build a package that the maintainer thinks
>> isn't legal to distribute under some set of circumstances (which
>> might or might not be the user's circumstances).
> 
>> RESTRICT=bindist in an ebuild means what?  Let's look at the
>> devmanual: RESTRICT - A space-delimited list of portage features
>> to restrict. Valid values are fetch, mirror, strip, testand
>> userpriv. See man 5 ebuild for details. man 5 ebuild: bindist -
>> Distribution of built packages is restricted.
> 
>> And how does a user tell portage whether they intend to
>> redistribute something in the first place?  The fact that an
>> ebuild sets RESTRICT=bindist does not have anything to do with
>> whether it will in fact be redistributed.  It sounds like we
>> would need a FEATURES=bindist to go along with it.  Oh, and it
>> sounds like RESTRICT=bindist often should be conditional based on
>> USE=-bindist, but you can't set RESTRICT conditionally, so that
>> won't work.
> 
>> Also, isn't all of this somewhat redundant with ACCEPT_LICENSE?
>> It is the license that allows you to redistribute something in
>> the first place, though with some licenses it might be
>> conditional upon how the package is built/branded.
> 
>> The last thing we need on any of this stuff is a hard error.
>> What is needed first is for those who care about such things to
>> cleanly specify a sane set of definitions and behavior.
> 
> I really appreciate your input here, I think you may be onto
> something. Maybe the best thing to do would be to drop
> RESTRICT=bindist entirely and just make a new license group for it?
> Maybe it would even be possible to automatically
> ACCEPT_LICENSE=bindist when USE=-bindist and vice-versa?  This
> seems a more productive direction than anything I was able to come
> up with.
> 
> Thanks! Zero
> 
> 

erm..  OK just to back up on things a little bit..:

IUSE="bindist" tends to be for adjusting a particular package so that
it either is generic and CAN be binary-distributable, or will build as
upstream intended (with, for instance, upstream branding) and
therefore is not.  Right?

So, in essence, the use flag can allow for an exception of a 'bindist'
LICENSE.  Would it make more sense then to have LICENSE= contents
controlled conditionally?  ie:

www-client/firefox:
LICENSE="MPL-2.0 GPL-2 LGPL-2.1
	!bindist? ( MPL-2.0-bindist-restriction )"

Of course for other packages there is no USE="bindist" functionality
as it's not possible to allow any binary redistribution.  These
probably should just go into the 'bindist' license group.

I think it would make a lot of sense to NOT let a use flag suddenly
adjust ACCEPT_LICENSE.  However, it -would- i think make a lot of
sense to ebuilds that implement a bindist use flag to adjust the
licenses that apply to the emerged result.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlF61FsACgkQ2ugaI38ACPBDIgEAj5QCD3sKZcrsQpaA/4OTRdfs
jlhH0owE4epqvYlHgqUBAJ+eUsKPUBfgnKK7MfzGhvzdACgnb1UlMJ4Ax35L8iKY
=kdJW
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rich Freeman]

On Fri, Apr 26, 2013 at 3:24 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> IUSE="bindist" tends to be for adjusting a particular package so that
> it either is generic and CAN be binary-distributable, or will build as
> upstream intended (with, for instance, upstream branding) and
> therefore is not.  Right?

Correct.

>
> So, in essence, the use flag can allow for an exception of a 'bindist'
> LICENSE.  Would it make more sense then to have LICENSE= contents
> controlled conditionally?  ie:
>

I'm not sure if this is really necessary.

If a user doesn't want to accidentally install something that isn't
redistributable they can start with
ACCEPT_LICENSE=@BINARY-REDISTRIBUTABLE, which already exists.

Then they can augment that by manually overriding it for packages
where they've decided they're not impacted, or where they're using
USE=-bindist.

There are really only a small number of situations where this will
happen.  I'm not sure if we need to implement conditional licensing
with a pseudo-license on top of that just to cover them.  The license
itself doesn't actually change when you USE -bindist - you're simply
complying with it.

Rich

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/26/2013 03:24 PM, Ian Stakenvicius wrote:
> On 26/04/13 03:07 PM, Rick "Zero_Chaos" Farina wrote:
>> On 04/26/2013 02:44 PM, Rich Freeman wrote:
>>> On Fri, Apr 26, 2013 at 2:30 PM, Rick "Zero_Chaos" Farina 
>>> <zerochaos@gentoo.org> wrote:
>>>> The user is distinguishing right from wrong by setting things
>>>> like USE=bindist, portage simply doesn't seem to be respecting
>>>> that in the case of RESTRICT=bindist.
> 
>>> I think what is missing is a clear set of definitions.
> 
>>> USE=-bindist means build a package that the maintainer thinks
>>> isn't legal to distribute under some set of circumstances (which
>>> might or might not be the user's circumstances).
> 
>>> RESTRICT=bindist in an ebuild means what?  Let's look at the
>>> devmanual: RESTRICT - A space-delimited list of portage features
>>> to restrict. Valid values are fetch, mirror, strip, testand
>>> userpriv. See man 5 ebuild for details. man 5 ebuild: bindist -
>>> Distribution of built packages is restricted.
> 
>>> And how does a user tell portage whether they intend to
>>> redistribute something in the first place?  The fact that an
>>> ebuild sets RESTRICT=bindist does not have anything to do with
>>> whether it will in fact be redistributed.  It sounds like we
>>> would need a FEATURES=bindist to go along with it.  Oh, and it
>>> sounds like RESTRICT=bindist often should be conditional based on
>>> USE=-bindist, but you can't set RESTRICT conditionally, so that
>>> won't work.
> 
>>> Also, isn't all of this somewhat redundant with ACCEPT_LICENSE?
>>> It is the license that allows you to redistribute something in
>>> the first place, though with some licenses it might be
>>> conditional upon how the package is built/branded.
> 
>>> The last thing we need on any of this stuff is a hard error.
>>> What is needed first is for those who care about such things to
>>> cleanly specify a sane set of definitions and behavior.
> 
>> I really appreciate your input here, I think you may be onto
>> something. Maybe the best thing to do would be to drop
>> RESTRICT=bindist entirely and just make a new license group for it?
>> Maybe it would even be possible to automatically
>> ACCEPT_LICENSE=bindist when USE=-bindist and vice-versa?  This
>> seems a more productive direction than anything I was able to come
>> up with.
> 
>> Thanks! Zero
> 
> 
> 
> erm..  OK just to back up on things a little bit..:
> 
> IUSE="bindist" tends to be for adjusting a particular package so that
> it either is generic and CAN be binary-distributable, or will build as
> upstream intended (with, for instance, upstream branding) and
> therefore is not.  Right?
> 
> So, in essence, the use flag can allow for an exception of a 'bindist'
> LICENSE.  Would it make more sense then to have LICENSE= contents
> controlled conditionally?  ie:
> 
> www-client/firefox:
> LICENSE="MPL-2.0 GPL-2 LGPL-2.1
> 	!bindist? ( MPL-2.0-bindist-restriction )"

It was not my intention to switch valid licenses based on a use flag.
I'm pretty sure that isn't valid and the same license applies whether or
not you are going to redistribute it, the license doesn't change.

For the packages which already have USE=bindist they are conditionally
restricting binary redistribution and that is already handled well.  The
issue is that nothing prevents (or even really alerts) the user in the
case of things which are ALWAYS restricted.  Honestly I'm very happy
with the current USE=bindist behavior, I'm not happy with RESTRICT=bindist.

Based on Rich's suggestion my thought is have a new license group for
things which are ALWAYS binary restricted, accepted by default, but
removed from ACCEPT_LICENSE when USE=bindist.  That is just what is
rolling around in my head right now, but it is semi-sane.

Thanks,
Zero
> 
> Of course for other packages there is no USE="bindist" functionality
> as it's not possible to allow any binary redistribution.  These
> probably should just go into the 'bindist' license group.
> 
> I think it would make a lot of sense to NOT let a use flag suddenly
> adjust ACCEPT_LICENSE.  However, it -would- i think make a lot of
> sense to ebuilds that implement a bindist use flag to adjust the
> licenses that apply to the emerged result.
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRetj8AAoJEKXdFCfdEflKsdwP/3z7yFPpZm3zBynGzNNuviyz
pq1svrwZQL82gptTQoWt+/KyLGu+1sHgW4nLW7mPSzYbLWiu+/1fyOQWcAhQT2j8
kGW5vlLgz5Mb7SJWNEP0xcHtV3/OZPWj5KkKrsmjka4qf69XJ9KAXDka0joxO05O
uXAxzhAbaODKlmAF4oMqpNuEVmFTxk+hko05m4tIxTD1MbTBys8UR7EwwdcqZCTP
nVkDEanwgIOrVwc18t4DRr7gKkPc/dbcr9GYQtWlywPdQpUBfkdwaFCTk/gG6FQ+
Sq/3LLciU2+8JZgq1tROwYYboxXPNTjIE3KRxViIWddPo4/sZnrU+bv53zvusduw
t4WZ5ODZRttM+M/8Hx5E30EhMP5hF8IqvsxFYNNQJGcJa5B6vPMh1jK7TV9srGNx
IJkmufYR2SApzpBdn4Sx6VVmjSwpEOrCzNyNg029Zdrmlg+Ggv9h6YV7J05TCDhU
bCdeIP9Kq2IlZkVjLOJeDp8gS7hJpUvqH2Ky9wophbikTbQjnDVhBGlK9+WW4K5z
bH0MKRJCh4j3YqIlPyvIct2BH1Lzbh0O2ztB2w74AmE1INvuwtRdpUQLxGMr1XO+
9tOeIH/80dyseJSRCBULSlHtNqudM/0x15SIpJ6kxvTn5oZjC8uG8/rI6JbeY3OD
9lGtUSiLLys5mK1BFCR2
=vtqG
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Rich Freeman]

On Fri, Apr 26, 2013 at 3:43 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> Based on Rich's suggestion my thought is have a new license group for
> things which are ALWAYS binary restricted, accepted by default, but
> removed from ACCEPT_LICENSE when USE=bindist.  That is just what is
> rolling around in my head right now, but it is semi-sane.

We already have the BINARY-REDISTRIBUTABLE group.  So, if you just set
ACCEPT_LICENSE=@BINARY-REDISTRIBUTABLE you'll only get packages you
can redistribute.  Then you can just set ACCEPT_LICENSE=FOO in
/etc/portage/env for packages you are handling with USE=-bindist or
whatever.

Sure, it might be a little nicer to have a bit more automation, but
the existing license group lets you set things conservatively so
you'll never be burned by accidentally redistributing something you
can't.  I'd be interested in hearing from anybody who actually has the
need to redistribute things and thinks that this is insufficient.

Rich

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Michael Weber]

On 04/26/2013 09:23 PM, Ulrich Mueller wrote:
>>>>>> On Fri, 26 Apr 2013, Mike Frysinger wrote:
> 
>>> Currently RESTRICT=mirror and RESTRICT=bindist are independent of
>>> each other. I wonder if the former should imply the latter.
>>>
>>> Is there any package where the files in SRC_URI cannot be mirrored
>>> (i.e., redistributed), but where the built package can be
>>> distributed?
> 
>> i've used RESTRICT=mirror in the past when the files were really
>> large (like games or toolchain source tarballs) and upstream already
>> had a good mirroring system. in both cases, there was no binary
>> redistribution restrictions.
> 
>> so my answer would be no: we have two independent knobs and let's
>> keep them that way.
> 
> Right. And as was pointed to me on IRC, another legitimate case for
> mirror restriction are packages in overlays whose distfiles are not on
> mirrors. Then it obviously makes no sense to check mirrors for it.

And sunrise suggested to not set it, to make the move into main tree
less error prone.

I think, all the legal terms "no mirror" and "no branded redistribution"
are clear, but portage might get problems to check/recognise "within a
legal entity". DNS zones, netblocks and so on are all optional and do
not necessarily represent these boundaries.
trusted computing platform ... please no.
GPG keys sets with encrypted tarballs would raise the awareness, all of
them bypass-able

In the end, legally speaking, it's the user pushing buttons and portage
is no licensed lawyer.

   Michael
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1034 bytes --]

On Friday 26 April 2013 15:23:42 Ulrich Mueller wrote:
> >>>>> On Fri, 26 Apr 2013, Mike Frysinger wrote:
> >> Currently RESTRICT=mirror and RESTRICT=bindist are independent of
> >> each other. I wonder if the former should imply the latter.
> >> 
> >> Is there any package where the files in SRC_URI cannot be mirrored
> >> (i.e., redistributed), but where the built package can be
> >> distributed?
> > 
> > i've used RESTRICT=mirror in the past when the files were really
> > large (like games or toolchain source tarballs) and upstream already
> > had a good mirroring system. in both cases, there was no binary
> > redistribution restrictions.
> > 
> > so my answer would be no: we have two independent knobs and let's
> > keep them that way.
> 
> Right. And as was pointed to me on IRC, another legitimate case for
> mirror restriction are packages in overlays whose distfiles are not on
> mirrors. Then it obviously makes no sense to check mirrors for it.

ah, yeah, we do this a lot in ChromiumOS
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Should mirror restriction imply bindist restriction?

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

So years ago, we had GRP (the Gentoo Reference Platform.) My understanding
of USE=bindist was that when building packages whose binaries were illegal
to distribute, the build system would take some action. For instance, for a
while we were not allowed to brand a source build of firefox as firefox, so
debian made iceweasel and we ourselves add USE=bindist so we could build
custom builds and replacing the branding.

I'm not sure RESTRICT=bindist actually does anything. My guess is that the
intention of the restriction is to warn users that when building binaries
packages of a given package, there are 'legal issues' with such
distribution. That being said, as some have noted in the thread, the legal
issues are diverse and are unlikely to be covered in one flag.

-A


On Fri, Apr 26, 2013 at 9:05 AM, Ulrich Mueller <ulm@gentoo.org> wrote:

> Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
> other. I wonder if the former should imply the latter.
>
> Is there any package where the files in SRC_URI cannot be mirrored
> (i.e., redistributed), but where the built package can be distributed?
>
> Ulrich
>
>

[-- Attachment #2: Type: text/html, Size: 1595 bytes --]

[gentoo-dev] Re: Should mirror restriction imply bindist restriction?

[Duncan]

Chí-Thanh Christopher Nguyễn posted on Fri, 26 Apr 2013 19:19:32 +0200 as
excerpted:

> Ulrich Mueller schrieb:
>> Currently RESTRICT=mirror and RESTRICT=bindist are independent of each
>> other. I wonder if the former should imply the latter.
>>
>> Is there any package where the files in SRC_URI cannot be mirrored
>> (i.e., redistributed), but where the built package can be distributed?
> 
> I vaguely remember some cases of large proprietary packages which were
> legal to redistribute, but we did not want them on Gentoo mirrors. After
> all, the description according to ebuild(5) does not contain a reference
> to what you can or cannot do:
> mirror
>      files in SRC_URI will not be downloaded from the GENTOO_MIRRORS.

IIRC, one case was several gigs of data-files for some game or other.  It 
was legal to redistribute, but several gigs of files was thought too much 
for the mirrors, for a single game only a small fraction of gentoo users 
would be interested in.  Additionally, the game data wasn't likely to 
change as development had long since ceased, so it tended to be a one-
time download, meaning even users that used it would probably only do so 
once.

It's quite possible that some bit of that is incorrect, however.  Perhaps 
someone from games can confirm/correct as necessary.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman