[gentoo-dev] RFC: new global USE flag "srcdist"

[gentoo-dev] RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

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.

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.

Nevertheless, I also see the point for covering the distfiles
contents.

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:

	LICENSE="<licenses of installed stuff>
		srcdist? ( <licenses of unused stuff in distfiles> )"

This idea was discussed within the licenses team, and the overall
reaction was positive.

What do you think?

Ulrich

[1] http://www.gentoo.org/proj/en/glep/glep-0023.html
[2] https://bugs.gentoo.org/show_bug.cgi?id=492424#c3

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rick "Zero_Chaos" Farina]

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

On 01/01/2014 05:28 PM, 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.
> 
> 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.
> 
> Nevertheless, I also see the point for covering the distfiles 
> contents.
> 
> 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:
> 
> LICENSE="<licenses of installed stuff> srcdist? ( <licenses of
> unused stuff in distfiles> )"
> 
> This idea was discussed within the licenses team, and the overall 
> reaction was positive.
> 
> What do you think?

Assuming this flag is not set by default on user systems (since they
obviously are not all distributing sources) I think it's a very
positive change.  I myself would need to have this flag set on my
build box and it would help me better adhere to the correct licensing
terms.

- -Zero
> 
> Ulrich
> 
> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html [2]
> https://bugs.gentoo.org/show_bug.cgi?id=492424#c3
> 

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

iQIcBAEBAgAGBQJSxL8cAAoJEKXdFCfdEflK4bQQAKwJmkeDgm3IBcX06QqcDmJ+
QqYyE+SLJdJw2Fs9iXExEDa+nc9/6QOZkE1E6AA4wji/jKHDpp7ddnXCVfgNALaS
KaAlsG+eiJk27C/sfpyT+Nmvd+FPzLcm9cNp8YjOn50BlDfVFUxoE5M3woJiIn/m
gRbwHZhNVWYnqzHjOwiEhs3mUC6quu9N3c3QPY2k0lKspGW+3yqEqy8wZng9Wli6
8nMa1DXg92fk9gcmgpHAYTl0+gBtvv0LVa70fYu5Y+aGJAQEUclaMAlSi0ES4DYi
7YpEjB2HJOWXFH30DJdhv2E4v5MTHzARgjCGHv6jXvHZfIoS7PbDIbQ2IBpkOpSP
kyOF2Aj/bWoIvFKzMGPWcDzwQwnfvJ/M615NTgGMZL/Iv04Pdki8W2qTvxsH17m3
NvEtdoMrtyT1gvJaLg8/Vsx2EaBYp47iwK81vPHgqQ7TsypO2v5G70Nqk6ogARgF
gqp524/LUca/mfhKp6LlWT9TXvu2QziE24QYtHQ0mlWer9+KBKX+++dcDyXmF+ww
KAiz9wsHmMdXsCb5/C2xA3RQk+4lePlFJiYeYs4Ix6/CgdW35w+BjtfAiWNz5rpy
M5IRAtKQO/VJQlLjfERDfyC2hdSPAqoW/wrmAZ15VqoPnsNabrp8O3fO0+j5kEWq
WZS6YVfKSghARUAzyP4g
=7nB6
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michael Orlitzky]

On 01/01/2014 05:28 PM, 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.

Why do I as a user care about the license of a package? I want packages
to be in @FREE in case I need to modify (and redistribute) them. But I
only need to modify the parts that I use.

If an otherwise-GPL package pulls in the latest Justin Bieber CD with
USE=badtaste, that's not really an issue for me, because I'm not using
it. I'm happy to install the rest of the package with the USE flag
unset. The CD might as well be a separate package with a different
license as far as I'm concerned.

In essence, I don't want to *use* code that isn't @FREE. This includes
the installed files, of course, but also the build system (that I use
temporarily). We could generalize this to "any file accessed during
emerge" to be on the safe side. That ensures that if I need to modify
(and redistribute) any part of the software that I use, I can.

What use case is there for having the LICENSE apply to anything else?


> 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 think a better solution here, since these files are *installed*, is to
introduce a new local flag (e.g. unfreeblobs) for the kernel that would
append to LICENSE by the mechanism described below.


> Nevertheless, I also see the point for covering the distfiles
> contents.
> 
> 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:
> 
> 	LICENSE="<licenses of installed stuff>
> 		srcdist? ( <licenses of unused stuff in distfiles> )"
> 
> This idea was discussed within the licenses team, and the overall
> reaction was positive.
> 
> What do you think?
> 
> Ulrich
> 
> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html
> [2] https://bugs.gentoo.org/show_bug.cgi?id=492424#c3
> 

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rich Freeman]

On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
> In essence, I don't want to *use* code that isn't @FREE. This includes
> the installed files, of course, but also the build system (that I use
> temporarily). We could generalize this to "any file accessed during
> emerge" to be on the safe side. That ensures that if I need to modify
> (and redistribute) any part of the software that I use, I can.
>
> What use case is there for having the LICENSE apply to anything else?

If you want to redistribute the source tarball (such as on an internal
mirror) then you might care what license pertains to the tarball.
RESTRICT=mirror only prevents mirrors using the standard Gentoo
software from distributing a file.  If you just have a server fetch
sources and share distfiles via NFS/rsync/etc then you're sharing
everything.  I actually use this approach for my VMs/etc to cut down
on network traffic and mirror load (my main Gentoo box is listed as
the first mirror, and also is used for SYNC).

> I think a better solution here, since these files are *installed*, is to
> introduce a new local flag (e.g. unfreeblobs) for the kernel that would
> append to LICENSE by the mechanism described below.

Well, sure, any USE flag that controls the installation of the blobs
should append the appropriate string to LICENSE.  However, that is a
separate (and also important) issue.

I'm trying to think of any issues the new approach would cause and I
can't think of any - it seems like a good move to me.  Those who don't
do anything get the current behavior, and those who care about
redistributing distfiles can filter licenses if they care to do so.
This also settles the ambiguity in what LICENSE means.  It is probably
worth noting that most packages wouldn't be impacted by this.

Has anybody tested whether ACCEPT_LICENSE handles USE conditionals
correctly?  If it is in PMS and it doesn't than that would be a
Portage bug, but we should probably be aware of what it does before
setting it all over the tree.

Rich

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michael Orlitzky]

On 01/01/2014 09:10 PM, Rich Freeman wrote:
> On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>> In essence, I don't want to *use* code that isn't @FREE. This includes
>> the installed files, of course, but also the build system (that I use
>> temporarily). We could generalize this to "any file accessed during
>> emerge" to be on the safe side. That ensures that if I need to modify
>> (and redistribute) any part of the software that I use, I can.
>>
>> What use case is there for having the LICENSE apply to anything else?
> 
> If you want to redistribute the source tarball (such as on an internal
> mirror) then you might care what license pertains to the tarball.
> RESTRICT=mirror only prevents mirrors using the standard Gentoo
> software from distributing a file.  If you just have a server fetch
> sources and share distfiles via NFS/rsync/etc then you're sharing
> everything.  I actually use this approach for my VMs/etc to cut down
> on network traffic and mirror load (my main Gentoo box is listed as
> the first mirror, and also is used for SYNC).
> 

Is there a real example where the license matters for something
redistributed to yourself?

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rich Freeman]

On Wed, Jan 1, 2014 at 9:19 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> Is there a real example where the license matters for something
> redistributed to yourself?

Well, "yourself" is a loose term.  If I were to redistribute MS
Windows across 300 PCs for my employer I suspect some people would
have something to say about that.  Heck, the RIAA wants you to re-buy
music if you want to load a song on an mp3 player that you already own
on CD.

However, for most packages in the tree the issue is going to be how
"free" as in whatever you want the package to be.  If we're going to
have ACCEPT_LICENSE in the first place it seems like this is just a
logical extension of it.

Rich

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michael Orlitzky]

On 01/01/2014 09:38 PM, Rich Freeman wrote:
> On Wed, Jan 1, 2014 at 9:19 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>>
>> Is there a real example where the license matters for something
>> redistributed to yourself?
> 
> Well, "yourself" is a loose term.  If I were to redistribute MS
> Windows across 300 PCs for my employer I suspect some people would
> have something to say about that.  Heck, the RIAA wants you to re-buy
> music if you want to load a song on an mp3 player that you already own
> on CD.
> 
> However, for most packages in the tree the issue is going to be how
> "free" as in whatever you want the package to be.  If we're going to
> have ACCEPT_LICENSE in the first place it seems like this is just a
> logical extension of it.

But Gentoo can't distribute MS Windows to you in the first place. Is
there a package that Gentoo can distribute to you, but you can't
redistribute within your organization?

As I said in another reply, more license metadata is good and we should
make it available. But a USE flag that changes the meaning of an
important global variable is a little hacky, especially if it doesn't
solve a real problem within Gentoo/Portage. If the problems are
theoretical (or aren't Gentoo package management problems), maybe it's
better to wait and do it right in an EAPI.

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rich Freeman]

On Wed, Jan 1, 2014 at 9:50 PM, Michael Orlitzky <mjo@gentoo.org> wrote:
>
> But Gentoo can't distribute MS Windows to you in the first place. Is
> there a package that Gentoo can distribute to you, but you can't
> redistribute within your organization?

Well, ACCEPT_LICENSE is about more than just whether a package is
USE=bindist. There is also nothing that prevents Portage from
conceptually installing something like Windows (this stuff isn't
limited to the main portage tree, and we have had proprietary software
in portage before (user had to provide their own distfiles)). However,
I would tend to think that any package with RESTRICT=mirror would have
potential legal concerns, since we obviously set it for a reason.  The
specifics of any particular package are of course going to vary.

>
> As I said in another reply, more license metadata is good and we should
> make it available. But a USE flag that changes the meaning of an
> important global variable is a little hacky, especially if it doesn't
> solve a real problem within Gentoo/Portage. If the problems are
> theoretical (or aren't Gentoo package management problems), maybe it's
> better to wait and do it right in an EAPI.

Well, the LICENSE that applied to the installed files for a package
could very well change due to USE flags (for example, a de-blobbed
kernel).  I don't think you're disputing that, and I do realize that
this is a bit more "virtual."

Rich

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Wed, 01 Jan 2014, Michael Orlitzky wrote:

> As I said in another reply, more license metadata is good and we
> should make it available. But a USE flag that changes the meaning of
> an important global variable is a little hacky, especially if it
> doesn't solve a real problem within Gentoo/Portage.

A srcdist flag wouldn't be that much different from the bindist flag
that we already have, and which is also of a non-technical nature.

> If the problems are theoretical (or aren't Gentoo package management
> problems), maybe it's better to wait and do it right in an EAPI.

As I said, this would leave us with a long transition period. And what
syntax would you propose? Additional license variables? Or Exherbo
style depend syntax? TBH, I don't want to open this can of worms. ;-)

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michael Orlitzky]

On 01/02/2014 07:54 AM, Ulrich Mueller wrote:
>>>>>> On Wed, 01 Jan 2014, Michael Orlitzky wrote:
> 
>> As I said in another reply, more license metadata is good and we
>> should make it available. But a USE flag that changes the meaning of
>> an important global variable is a little hacky, especially if it
>> doesn't solve a real problem within Gentoo/Portage.
> 
> A srcdist flag wouldn't be that much different from the bindist flag
> that we already have, and which is also of a non-technical nature.

Two wrongs don't make a right =)

I don't have a problem with bindist, but I don't buy its existence as an
argument for USE=srcdist.


>> If the problems are theoretical (or aren't Gentoo package management
>> problems), maybe it's better to wait and do it right in an EAPI.
> 
> As I said, this would leave us with a long transition period. And what
> syntax would you propose? Additional license variables? Or Exherbo
> style depend syntax? TBH, I don't want to open this can of worms. ;-)

An additional variable, similar to RDEPEND/DEPEND. We'd have one for
"I'm using this" LICENSE and one for "I want to redistribute the source
tarball" LICENSE.

If you think the transition period for that is long, how long do you
think it will take for people to become aware of the magic USE flag and
begin populating the other-LICENSE-contained-within-LICENSE variable?
How long until it has 100% coverage?

If maintainers don't use it, the feature is useless, because you can't
rely on it and have to audit everything yourself anyway. For it to
actually serve its purpose (e.g. to be useful for Pentoo), it would need
to be in the PMS and skel.ebuild where people have to pay attention to
it. How well would ACCEPT_LICENSE work if LICENSE was optional and
controlled by a USE flag?

If I intend to automatically redistribute the source tarballs that
portage downloads, I have a few options:

  1. Audit everything myself (impossible)
  2. Ignore the licensing issues (used in practice)
  3. Only ship packages that declare an acceptable source
     distribution license

There's no easy way to do (3) when using conditionals inside of LICENSE.
If there's a new required license variable in EAPI=$next, however, it
becomes tractable.

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rich Freeman]

On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky <mjo@gentoo.org> wrote:
> If you think the transition period for that is long, how long do you
> think it will take for people to become aware of the magic USE flag and
> begin populating the other-LICENSE-contained-within-LICENSE variable?
> How long until it has 100% coverage?

Well, there is no guarantee that the existing LICENSE field is 100%
accurate.  In fact, the whole reason this came up was that somebody
noticed some issues with a package.

>
> If maintainers don't use it, the feature is useless, because you can't
> rely on it and have to audit everything yourself anyway. For it to
> actually serve its purpose (e.g. to be useful for Pentoo), it would need
> to be in the PMS and skel.ebuild where people have to pay attention to
> it. How well would ACCEPT_LICENSE work if LICENSE was optional and
> controlled by a USE flag?

Well, LICENSE IS controlled by a USE flag - that's the point.  We
would simply announce the change and update the devmanual and if a
maintainer doesn't comply it is a bug, just like if they stick "GPL"
on a package that is really proprietary.

>
> If I intend to automatically redistribute the source tarballs that
> portage downloads, I have a few options:
>
>   1. Audit everything myself (impossible)
>   2. Ignore the licensing issues (used in practice)
>   3. Only ship packages that declare an acceptable source
>      distribution license
>
> There's no easy way to do (3) when using conditionals inside of LICENSE.
> If there's a new required license variable in EAPI=$next, however, it
> becomes tractable.

Sure you can - just use the conditional inside the license.  If you
don't trust that, then I don't know why you're trusting the LICENSE
field at all.  No law of nature makes it infallible.

Sure, you could have a SRCLICENSE field and 99% of ebuilds could
contain SRCLICENSE=$LICENSE just like 99% of them contain
DEPEND=$RDEPEND.  That doesn't make it any more or less accurate - we
have bugs in dependencies all the time, and we'll have bugs on
licenses all the time too.  The key is that we do due diligence and
fix them when we find them.

Rich

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Wed, 1 Jan 2014, Rich Freeman wrote:

> On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky <mjo@gentoo.org>
> wrote:

>> I think a better solution here, since these files are *installed*,
>> is to introduce a new local flag (e.g. unfreeblobs) for the kernel
>> that would append to LICENSE by the mechanism described below.

> Well, sure, any USE flag that controls the installation of the blobs
> should append the appropriate string to LICENSE. However, that is a
> separate (and also important) issue.

The kernel does this already. kernel-2.eclass (basically) assigns:

LICENSE="GPL-2 !deblob? ( freedist )"

So with USE=deblob you get GPL-2 because only GPL-2 files will be
installed on your system. (Of course, "freedist" is only a crude
approximation of the actual firmware licenses. But this is a separate
issue, see https://bugs.gentoo.org/show_bug.cgi?id=318841#c9).

> Has anybody tested whether ACCEPT_LICENSE handles USE conditionals
> correctly? If it is in PMS and it doesn't than that would be a
> Portage bug, but we should probably be aware of what it does before
> setting it all over the tree.

Ack. It is specified in GLEP 23 and PMS, and Portage does handle it
correctly.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rick "Zero_Chaos" Farina]

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

On 01/01/2014 08:51 PM, Michael Orlitzky wrote:
> On 01/01/2014 05:28 PM, 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.
> 
> Why do I as a user care about the license of a package? I want packages
> to be in @FREE in case I need to modify (and redistribute) them. But I
> only need to modify the parts that I use.
> 
> If an otherwise-GPL package pulls in the latest Justin Bieber CD with
> USE=badtaste, that's not really an issue for me, because I'm not using
> it. I'm happy to install the rest of the package with the USE flag
> unset. The CD might as well be a separate package with a different
> license as far as I'm concerned.
> 
> In essence, I don't want to *use* code that isn't @FREE. This includes
> the installed files, of course, but also the build system (that I use
> temporarily). We could generalize this to "any file accessed during
> emerge" to be on the safe side. That ensures that if I need to modify
> (and redistribute) any part of the software that I use, I can.
> 
> What use case is there for having the LICENSE apply to anything else?

Some of us do redistribute the entire source package, so it does matter.
 If it doesn't matter to you as a user then you can always leave it
unset and you remain completely oblivious to the change.

- -Zero

> 
> 
>> 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 think a better solution here, since these files are *installed*, is to
> introduce a new local flag (e.g. unfreeblobs) for the kernel that would
> append to LICENSE by the mechanism described below.
> 
> 
>> Nevertheless, I also see the point for covering the distfiles
>> contents.
>>
>> 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:
>>
>> 	LICENSE="<licenses of installed stuff>
>> 		srcdist? ( <licenses of unused stuff in distfiles> )"
>>
>> This idea was discussed within the licenses team, and the overall
>> reaction was positive.
>>
>> What do you think?
>>
>> Ulrich
>>
>> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html
>> [2] https://bugs.gentoo.org/show_bug.cgi?id=492424#c3
>>
> 
> 
> 

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

iQIcBAEBAgAGBQJSxMtZAAoJEKXdFCfdEflK4uIP/RAl9JWej7SInRWRkMRFTiWe
SAGcvNUm7qbVKCPYWDKp82+3fN6wEXSWLRcB2nCS8jZy8adzEOF0Oqvym17J3sEI
wfiB3lI5VNCkx7lX0wJiYIbCmKVR6PgwTdeBGcDIzdgU2TPygXLADbBu7n+54f7U
XAWcKPQRcuAzBFxCzuL1yWQzBuovhTU9HMelPaYPkXUGvi+LWlfmDBXe2mG1gfD+
U8sNOyHjwuidR6slr9RjxFAkH5ItVzeRBMiE92kHurZpm06sVaqezj0Oj1PovgqS
ap/S/ncTQa7BrhmdzEIAqaLko/bpxJkjdWvEhj+MPQ453Et5+RvztE1h5KUdXrFj
QU/oKS2Pmh75cROlipSfN628cdBDYQ8x/eB8XIZDPKd4uc7i43tpYf8njbNNrLlG
jdioBnXEowJ+UQ/5vDM1s8ev3FToIfZRU1nFxREdJEYXx4qVhrZ/8yBlv7RWGcbs
IsCJEtbrUFAcNBMowQ6eN2SfWGrx8lpB+Qoh8WhsUR7XMuyBQYB0jCOOfeV8qDWd
kZn/t2+0daTxo70KRTLiVutHbqAaBjG1BF0iwZhS5YGmDufc2hm0fKgu7tzZb/HU
Q0jA9hgWLvAj4dqek7qp1j21af993tZadIR1gjU0WgY0HiEHFYmY1xqy8GF09ZgX
39Jvtx4tu9UEpgk0ERYA
=aSba
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michael Orlitzky]

On 01/01/2014 09:13 PM, Rick "Zero_Chaos" Farina wrote:
> 
>> What use case is there for having the LICENSE apply to anything else?
> 
> Some of us do redistribute the entire source package, so it does matter.
>  If it doesn't matter to you as a user then you can always leave it
> unset and you remain completely oblivious to the change.

I know, but if you take a pristine source tarball from upstream and
distribute it to some third party, why should portage be involved?

More metadata about the licenses is obviously a good thing and I'm not
saying we shouldn't figure out a way to make it available in the tree
(we should). But LICENSE is first and foremost a user interface to the
package manager. I don't like the idea of overloading the portage user
interface for use cases entirely outside the purview of portage.

My objection is not strong, in any case, if this solves some real
problem and is the best available way to do it.

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Rick "Zero_Chaos" Farina]

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

On 01/01/2014 09:40 PM, Michael Orlitzky wrote:
> On 01/01/2014 09:13 PM, Rick "Zero_Chaos" Farina wrote:
>>
>>> What use case is there for having the LICENSE apply to anything else?
>>
>> Some of us do redistribute the entire source package, so it does matter.
>>  If it doesn't matter to you as a user then you can always leave it
>> unset and you remain completely oblivious to the change.
> 
> I know, but if you take a pristine source tarball from upstream and
> distribute it to some third party, why should portage be involved?

Portage fetches the files for me, and I assume if I am not prompted for
license issues when it does, then I can redist the source and bins.
Clearly that is not always the case.

- -Zero

> 
> More metadata about the licenses is obviously a good thing and I'm not
> saying we shouldn't figure out a way to make it available in the tree
> (we should). But LICENSE is first and foremost a user interface to the
> package manager. I don't like the idea of overloading the portage user
> interface for use cases entirely outside the purview of portage.
> 
> My objection is not strong, in any case, if this solves some real
> problem and is the best available way to do it.
> 
> 

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

iQIcBAEBAgAGBQJSxNJvAAoJEKXdFCfdEflK2TsP/iIsgz/DQ8DEG7er+aqslg3z
LJFbEQ0/lBJ5/eSWrDcPeFhgHrHkXIuliZFgQJ2saMqLY9FnyZA1vIHwOIHlC14E
hs43qyU2rfT2VwzrUIMjvwOBP9EzDFi/dSEYWxy9WnLKSEWgXADGNLMw42LujAGg
s2f3UFTULdTaQUr9lhrbx1Vh91WtJrUBTkbkks0u2yuJSHZBMNFDrPqJ/LhqjHda
ZlhW18RXH/dsy/gCtYBfKysiiiY/jiKiAGMnVW5N597LO2jT7G3BBvexYe3tIyFi
96jhGLXQB2G1GzsNGw9f09VoCIvRz2OfXNZhHzMtDwIbjAvNxof9uAlHirAtlm7s
9K6OTdVt/zPsakosiCASQZm1mmde1rF0zy3x5/AKm6l9O3fuLZlJaQ60oJsVGKie
z9FPJW9tJRRGNdHBzoL3PBuvavKQKlVF8IbhpE/7BCJQl5hcUmaV1K0when0FiGH
koOLo4iR6llPfTMk17GMQ+RQINA9uauFJoSemUSjgM4haMxveZ8QcN+nXvJDUDX6
vbd4ywprX9S4/O5whk1M99CzvUJkjb9WjqGYtZgzxQy+THwnJ/O8CPCXSRa5Ig0Z
KehsdJ6tf2U6y6BxBFSNaOTM56kSNijBg8hhtBXJEE/7JB+AEVDmRV3+psXIZSa9
PcJPp65fClCzPTa7fWU0
=CklE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Michał Górny]

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

Dnia 2014-01-01, o godz. 23:28:54
Ulrich Mueller <ulm@gentoo.org> napisał(a):

> 	LICENSE="<licenses of installed stuff>
> 		srcdist? ( <licenses of unused stuff in distfiles> )"
> 
> This idea was discussed within the licenses team, and the overall
> reaction was positive.
> 
> What do you think?

How does this interact with other flags? Say, I have:

  LICENSES="A utils? ( B )"

Do I do:

  LICENSES="A utils? ( B ) srcdist? ( B )"

if they both are in the same tarball? Similarly, what if they come from
different tarball, with tarball B being conditional to 'utils?'

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Thu, 2 Jan 2014, Michał Górny wrote:

> How does this interact with other flags? Say, I have:

>   LICENSES="A utils? ( B )"

> Do I do:

>   LICENSES="A utils? ( B ) srcdist? ( B )"

Yes.

> if they both are in the same tarball? Similarly, what if they come
> from different tarball, with tarball B being conditional to 'utils?'

You mean if SRC_URI itself contains a USE conditional? Then it would
be LICENSE="A utils? ( B )".

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Wed, 1 Jan 2014 23:28:54 +0100
Ulrich Mueller <ulm@gentoo.org> 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.
> 
> 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 really
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 tarballs.
Unless there's a license in there that forbids mirroring then there's no need
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:
> 
> 	LICENSE="<licenses of installed stuff>
> 		srcdist? ( <licenses of unused stuff in distfiles> )"
> 
> This idea was discussed within the licenses team, and the overall
> reaction was positive.
> 
> 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 filtering the
license for that package. Either way you end up with non-distributable stuff in
your distfiles.

Maybe we could add RESTRICT=srcdist 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.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Thu, 2 Jan 2014 06:50:06 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> 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
> really 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].

[1]  http://lwn.net/Articles/199061/



-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Thu, 2 Jan 2014, Ryan Hill wrote:

> 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 really 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].
> [1]  http://lwn.net/Articles/199061/

I completely agree with you.

> So I don't understand why we would have to remove anything from the
> tarballs. Unless there's a license in there that forbids mirroring
> then there's no need 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.

IMHO, we normally shouldn't remove anything from tarballs. We have
mirror and fetch restrictions which should cover most cases where we
are not allowed to redistribute a distfile.

> 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 filtering the license for that
> package. Either way you end up with non-distributable stuff in your
> distfiles.

Of course, the srcdist USE flag would be disabled by default, so it
would make no difference for users' ACCEPT_LICENSE filtering. See it
as a way to provide additional information about license terms of
distfiles, or the part of distfiles that is not going to be installed.

> Maybe we could add RESTRICT=srcdist 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.

Interesting idea, but how would RESTRICT=srcdist be different from
RESTRICT=mirror?

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Kent Fredric]

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

On 3 January 2014 02:18, Ulrich Mueller <ulm@gentoo.org> wrote:

> > Maybe we could add RESTRICT=srcdist 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.
>
> Interesting idea, but how would RESTRICT=srcdist be different from
> RESTRICT=mirror?
>

I'd suggest we don't even need multiple variables for this, RESTRICT=mirror
seems clear enough.

The only change required would be overloading the meaning of that RESTRICT
verb to mean new things with regard to disk storage.

ie:

/distfiles/  # Normal
/distfiles-nomirror/ # RESTRICT=mirror
/distfiles-nofetch/  # RESTRICT=fetch

I guess you could make it still search for distfiles in all 3 locations in
case end users want to do silly things like violate Java's mirroring
policies and replicate java things via distfiles/ shared,  or you could
make it straightfoward enough to use all 3 paths with a single distfiles
dir.

But as it stands, the tooling isn't too friendly for people who want/need
to closely adhere to upstream distribution policies.

-- 
Kent

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

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Kent Fredric]

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

On 3 January 2014 01:50, Ryan Hill <dirtyepic@gentoo.org> wrote:

> Maybe we could add RESTRICT=srcdist 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.
>

I was going to suggest similar.

Though I hadn't thought about it at a global RESTRICT level, but I had
envisioned that potentially, the redistribubility should be a property of a
source file, not of en ebuild.

For example, if there was something such as java, which would likely be
mirror-restricted,  it the java binaries themselves would be mirror
restricted.

However, if there were any tools/patches provided by gentoo and also in
src_uri, marking them as no-mirror seems counter productive.

Just the RESTRICT based interface seems more obvious, where as spicing
SRC_URI values properly could be nuanced and complicated.


-- 
Kent

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

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ian Stakenvicius]

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

On 02/01/14 07:50 AM, Ryan Hill wrote:
> 
> Maybe we could add RESTRICT=srcdist 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.
> 

..or we could just do this, using the existing RESTRICT="mirror"
that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then
distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR.


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

iF4EAREIAAYFAlLFj44ACgkQ2ugaI38ACPAmmQD/TB04vOHgqsxXsB3pfeIKULL7
jrtgN3G/BHLPGlcL1D0A/i4o5Be+/wbqD+eBG8NPcZgfKOaS8SG4+c0vBZBQNKVl
=PilO
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Luis Ressel]

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

On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> ..or we could just do this, using the existing RESTRICT="mirror"
> that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
> NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then
> distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR.

IMHO, this is the best solution proposed so far. It doesn't need a new
USE flag duplicating information which is already in RESTRICT (or am I
missing some corner cases here?), and it doesn't bother those who don't
care about this issue with new distfiles-*/ dirs, as with Kent's
proposal.

@Kent: Why do you think another distinction for RESTRICT=fetch is
neccessary? If it really is, it could also be integrated into this
solution, but I don't get the point -- either you're allowed to
redistribute it, or you're not. RESTRICT=fetch just signals Portage
that it won't be *technically* able to download the distfiles.


Luis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Kent Fredric]

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

On 3 January 2014 05:28, Luis Ressel <aranea@aixah.de> wrote:

>
> @Kent: Why do you think another distinction for RESTRICT=fetch is
> neccessary? If it really is, it could also be integrated into this
> solution, but I don't get the point -- either you're allowed to
> redistribute it, or you're not. RESTRICT=fetch just signals Portage
> that it won't be *technically* able to download the distfiles.


Fair point. I was more seeing a pattern emerging and exploring where that
might lead.

Though I figure it a useful distinction for convenience sake.

Consider if you wanted to archive some files to make a subsequent gentoo
installation easier.

It would be optimal to backup and replicate the nofetch directory for the
subsequent installation, because that's the only directory that portage
would be unable to populate itself from upstream sources.

so it becomes:

/distfiles  # Gentoo Replicated and Fetchable from upstream
/distfiles-normirror # Fetch from upstream only
/distfiles-nofetch  # manual fetching only

So it was more a practical benefit than a legal one =).

( Also if you were tight on space, you'd obliterate  distfiles/ first,
distfiles-nomirror/ second, and distfiles-nofetch/ last )


-- 
Kent

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

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Luis Ressel]

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

On Fri, 3 Jan 2014 05:37:33 +1300
Kent Fredric <kentfredric@gmail.com> wrote:

> Fair point. I was more seeing a pattern emerging and exploring where
> that might lead.
> 
> Though I figure it a useful distinction for convenience sake.
> 
> Consider if you wanted to archive some files to make a subsequent
> gentoo installation easier.
> 
> It would be optimal to backup and replicate the nofetch directory for
> the subsequent installation, because that's the only directory that
> portage would be unable to populate itself from upstream sources.
> 
> so it becomes:
> 
> /distfiles  # Gentoo Replicated and Fetchable from upstream
> /distfiles-normirror # Fetch from upstream only
> /distfiles-nofetch  # manual fetching only
> 
> So it was more a practical benefit than a legal one =).
> 
> ( Also if you were tight on space, you'd obliterate  distfiles/ first,
> distfiles-nomirror/ second, and distfiles-nofetch/ last )

These are good arguments. Just to be clear: Would you favor if the
default setup did this separation? I personally also like the idea, but
I'd prefer to leave the default at "one distdir for *", and just make
it configurable via the proposed variables.


Luis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Kent Fredric]

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

On 3 January 2014 06:02, Luis Ressel <aranea@aixah.de> wrote:

> These are good arguments. Just to be clear: Would you favor if the
> default setup did this separation? I personally also like the idea, but
> I'd prefer to leave the default at "one distdir for *", and just make
> it configurable via the proposed variables.
>

Yeah, that seems fine to have them all default to the same directory, and
document that end users can set these variables and get certain reactions.

The only ambiguity I think creeps in is when you're say, jdk, and you're
telling users to download a file to a directory somewhere, you want to tell
them "Download to ${DISTDIR_NOFETCH}" , which may not necessarily be
available in all PMS implementations, and there's no real way around that.

As it is,we have the best I could expect, pkg_nofetch() + error message,
because you can't really give a generic response to RESTRICT=fetch ,
because fetch restrictions are not straight forward to resolve, and the
only plausible way to enhance on this circumstnace would be to have a
standard PMS feature that appended to the pkg_nofetch() with a list paths
it was expecting to exist.

Not to mention, supporting "Check all of $DISTDIR/$NOFETCH/$NOMIRROR" would
be a nightmare, because it appears lots of ebuilds manually use the
$DISTDIR variable, and would have to be ported somehow to use the new
variables.

find /usr/portage/ -name "*.ebuild" -print0 | xargs -0 -P3 grep 'DISTDIR'
-l | wc -l

> 1523

So essentially, the feature set I've suggested have rather complex
implications that I can't see being entirely viable without it being a
future EAPI feature.

There's ways of smoothing this out in portage land by dynamically changing
where DISTDIR points, but thats a similarly ugly problem.


-- 
Kent

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

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Thu, 2 Jan 2014, Luis Ressel wrote:

> IMHO, this is the best solution proposed so far. It doesn't need a
> new USE flag duplicating information which is already in RESTRICT
> (or am I missing some corner cases here?), and it doesn't bother
> those who don't care about this issue with new distfiles-*/ dirs, as
> with Kent's proposal.

RESTRICT is somewhat complementary to LICENSE and cannot provide as
much information. Especially, RESTRICT="mirror" doesn't say under
what license the restricted pieces are, and doesn't allow for
ACCEPT_LICENSE filtering.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Luis Ressel]

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

On Thu, 2 Jan 2014 17:53:45 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> RESTRICT is somewhat complementary to LICENSE and cannot provide as
> much information. Especially, RESTRICT="mirror" doesn't say under
> what license the restricted pieces are, and doesn't allow for
> ACCEPT_LICENSE filtering.

But is this detailed information really neccessary? The use-case is
ensuring the legality of distfiles mirroring -- you're either allowed to
do it nor not, the exact license doesn't matter here.


Luis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Thu, 2 Jan 2014, Luis Ressel wrote:

>> RESTRICT is somewhat complementary to LICENSE and cannot provide as
>> much information. Especially, RESTRICT="mirror" doesn't say under
>> what license the restricted pieces are, and doesn't allow for
>> ACCEPT_LICENSE filtering.

> But is this detailed information really neccessary? The use-case is
> ensuring the legality of distfiles mirroring -- you're either
> allowed to do it nor not, the exact license doesn't matter here.

This is not primarily about distfiles mirroring, about about giving
users a choice what distfiles they will accept on their systems (for
whatever reasons, e.g. legal or philosophical). Besides, not all users
are under the same legislation, which may affect their choice.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Rich Freeman]

On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> This is not primarily about distfiles mirroring, about about giving
> users a choice what distfiles they will accept on their systems (for
> whatever reasons, e.g. legal or philosophical). Besides, not all users
> are under the same legislation, which may affect their choice.

++

One could argue we don't need LICENSE at all since RESTRICT=mirror
already tells you something.  Gentoo is about choice and this is just
one more choice we're giving users.  The proposal is a NOOP for
anybody who doesn't do anything special, and those who want to use the
new flag can do so.  It also helps document the state of the tree so
that when we look at some ebuild and wonder why it is set to
RESTRICT=mirror we have more clues.

Rich

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ulrich Mueller]

>>>>> On Thu, 2 Jan 2014, Ulrich Mueller wrote:

> This is not primarily about distfiles mirroring, about about giving

s/about about/but about/

> users a choice what distfiles they will accept on their systems (for
> whatever reasons, e.g. legal or philosophical). Besides, not all
> users are under the same legislation, which may affect their choice.

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Thu, 2 Jan 2014 19:17:50 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 2 Jan 2014, Luis Ressel wrote:
> 
> >> RESTRICT is somewhat complementary to LICENSE and cannot provide as
> >> much information. Especially, RESTRICT="mirror" doesn't say under
> >> what license the restricted pieces are, and doesn't allow for
> >> ACCEPT_LICENSE filtering.
> 
> > But is this detailed information really neccessary? The use-case is
> > ensuring the legality of distfiles mirroring -- you're either
> > allowed to do it nor not, the exact license doesn't matter here.
> 
> This is not primarily about distfiles mirroring, about about giving
> users a choice what distfiles they will accept on their systems (for
> whatever reasons, e.g. legal or philosophical). Besides, not all users
> are under the same legislation, which may affect their choice.

Well, your subject line says "srcdist" ;).

That's only possible if we enumerate every license in every distfile we
distribute, which I don't think is a good idea.  Or at least not on the
basis of a theoretic user that might not actually exist.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Rich Freeman]

On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> That's only possible if we enumerate every license in every distfile we
> distribute, which I don't think is a good idea.  Or at least not on the
> basis of a theoretic user that might not actually exist.

Why would we need to do that when we don't specify a LICENSE for every
single file we install from a package.  LICENSE is a string of
licenses that apply to all of the files installed by a package, and
USE=srcdist LICENSE is a string of licenses that apply to all of the
SRC_URIs.

Personally I don't have any use for ACCEPT_LICENSE at all, and having
to specify the LICENSE for every single package in the tree is a lot
more work than additionally specifying additional licenses for the
rare tarball that contains extra stuff under a different license that
we don't install.  I don't really see a downside to this approach - if
you don't need the extra info then don't look at it - it won't pertain
to 98% of the packages in portage anyway.

Rich

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Thu, 2 Jan 2014 16:20:09 -0500
Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> > That's only possible if we enumerate every license in every distfile we
> > distribute, which I don't think is a good idea.  Or at least not on the
> > basis of a theoretic user that might not actually exist.
> 
> Why would we need to do that when we don't specify a LICENSE for every
> single file we install from a package.  LICENSE is a string of
> licenses that apply to all of the files installed by a package, and
> USE=srcdist LICENSE is a string of licenses that apply to all of the
> SRC_URIs.

That's what I said (or meant I guess).  When I say distfile it means
tarball/SRC_URI.  In order to make a decision about what distfiles you will
allow on your system, you need to know the licenses in those distfiles.  So we
would have to list all the licenses in that distfile, whether they apply or
not.  

> Personally I don't have any use for ACCEPT_LICENSE at all, and having
> to specify the LICENSE for every single package in the tree is a lot
> more work than additionally specifying additional licenses for the
> rare tarball that contains extra stuff under a different license that
> we don't install.  I don't really see a downside to this approach - if
> you don't need the extra info then don't look at it - it won't pertain
> to 98% of the packages in portage anyway.

I don't think it's that rare, but I don't know.  To find out for sure we'd have
to check every distfile we distribute. :p


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Thu, 2 Jan 2014 16:07:22 -0600
Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Thu, 2 Jan 2014 16:20:09 -0500
> Rich Freeman <rich0@gentoo.org> wrote:

> > Personally I don't have any use for ACCEPT_LICENSE at all, and having
> > to specify the LICENSE for every single package in the tree is a lot
> > more work than additionally specifying additional licenses for the
> > rare tarball that contains extra stuff under a different license that
> > we don't install.  I don't really see a downside to this approach - if
> > you don't need the extra info then don't look at it - it won't pertain
> > to 98% of the packages in portage anyway.
> 
> I don't think it's that rare, but I don't know.  To find out for sure we'd
> have to check every distfile we distribute. :p

In case it's helpful here's what FOSSology[1] has to say about some common
packages that people have uploaded to their demo server.

gcc-4.7.2.tar
ACAA ,ATT ,BSD ,BSD-2-Clause ,BSD-3-Clause ,BSD-lite ,BSD-possibility ,BSD-style ,BSL-1.0 ,CC-BY-SA-3.0 ,CPL ,Docbook ,Dual-license ,FSF ,FSF-possibility ,GFDL-1.1 ,GFDL-1.2+ ,GFDL-1.3 ,GNU-Manpages ,Gov't-rights ,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-2.0-with-bison-exception ,GPL-2.0-with-classpath-exception ,GPL-3.0 ,GPL-3.0+ ,GPL-3.0-with-autoconf-exception ,GPL-3.0-with-GCC-exception ,GPL-exception ,GPL-possibility ,IETF ,info-zip ,IPL-1.0 ,ISC ,JPEG/netpbm ,LGPL ,LGPL-2.0+ ,LGPL-2.1 ,LGPL-2.1+ ,LGPL-3.0 ,LGPL-3.0+ ,Microsoft-possibility ,MIT ,MIT-style ,MPL-1.1 ,No_license_found ,Non-commercial! ,Non-profit! ,NOT-public-domain ,NotreDame-style ,Public-domain ,Public-domain-ref ,Same-license-as ,SAX-PD ,See-doc(OTHER) ,See-file(COPYING) ,See-file(README) ,Sun-possibility ,SunPro ,Sun(tm) ,TeX-exception ,Trademark-ref ,UnclassifiedLicense ,W3C ,W3C-IP ,W3C-possibility ,W3C-style ,X11 ,X11-possibility ,Zlib ,Zlib-possibility

eglibc-2.17
Artistic-1.0 ,BSD-3-Clause ,BSD-lite ,BSD-style ,BSL-1.0 ,Cisco-style ,CMU ,FSF ,GNU-style(EXECUTE) ,GPL ,GPL-2.0 ,GPL-2.0+ ,GPL-3.0+ ,GPL-3.0+-with-bison-exception ,GPL-exception ,GPL-possibility ,IBM ,IBM-possibility ,IETF ,InnerNet-2.00 ,ISC ,LGPL ,LGPL-2.0 ,LGPL-2.0+ ,LGPL-2.1 ,LGPL-2.1+ ,LGPL-3.0+ ,LGPL-possibility ,Microsoft-possibility ,MIT ,MIT-style ,No_license_found ,Oracle-Berkeley-DB ,Public-domain ,Public-domain-ref ,Same-license-as ,See-doc(OTHER) ,Sun-possibility ,SunPro ,Trademark-ref ,X11-possibility

apache2 version 2.2
Apache-2.0 ,Apache-possibility ,Bellcore ,BSD-2-Clause ,BSD-3-Clause ,BSD-4-Clause-UC ,BSD-possibility ,Cisco ,CMU ,FSF ,GPL ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-exception ,ISC ,MIT ,MIT-style ,MPL ,No_license_found ,OLDAP ,Public-domain ,Public-domain-ref ,RSA-Security ,See-doc(OTHER) ,See-file(COPYING) ,See-file(LICENSE) ,Zeus ,Zlib

Ghostscript
AFPL-Ghostscript ,Aladdin(Closed-Source!) ,Aladdin-Ghostscript ,ATT-style ,Bitstream ,BSD-style ,GNU-Ghostscript ,GPL ,GPL-2.0+ ,No_license_found ,Not-for-sale! ,NOT-public-domain ,Public-domain ,See-doc(OTHER) ,UnclassifiedLicense ,zlib/libpng

Perl
Apache-2.0 ,Artistic ,Artistic-2.0 ,Artistic-possibility ,Bellcore ,BSD ,BSD-lite ,BSD-possibility ,BSD-style ,FSF ,GFDL-1.1 ,GPL ,GPL-1.0 ,GPL-1.0+ ,GPL-2.0+ ,GPL-3.0 ,GPL-Bison-exception ,LGPL ,LGPL-2.1 ,LGPL-3.0 ,MIT ,MIT-possibility ,MIT-style ,MPL ,MPL-1.1 ,No_license_found ,Non-commercial! ,Perl-possibility ,Public-domain ,Public-domain-ref ,RSA-Security ,Same-license-as ,See-doc(OTHER) ,See-file(LICENSE) ,See-file(README) ,Trademark-ref ,UnclassifiedLicense ,Unicode ,zlib/libpng ,zlib/libpng-possibility

util-linux-2.23.1.tar
BSD ,BSD-3-Clause ,BSD-4-Clause ,BSD-lite ,BSD-style ,Debian-SPI-style ,FSF ,FSF-possibility ,GNU-Manpages ,GPL ,GPL-1.0+ ,GPL-2.0 ,GPL-2.0+ ,GPL-2.0-with-autoconf-exception ,GPL-3.0+ ,GPL-exception ,LGPL ,LGPL-2.0 ,LGPL-2.0+ ,LGPL-2.0-possibility ,LGPL-2.1 ,LGPL-2.1+ ,MIT ,MIT-style ,No_license_found ,NOT-public-domain ,Public-domain ,Public-domain(C) ,Public-domain-ref ,Same-license-as ,UnclassifiedLicense ,X11

[1] http://www.fossology.org/projects/fossology


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ulrich Mueller]

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

>>>>> On Thu, 2 Jan 2014, Ryan Hill wrote:

> In case it's helpful here's what FOSSology[1] has to say about some
> common packages that people have uploaded to their demo server.

I don't get your point here. The licenses of a package have to be
checked in any case. Why would it be more complicated to check the
full set of files in the tarball, instead of the subset of files that
the package will actually install?

Ulrich

> [1] http://www.fossology.org/projects/fossology

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Fri, 3 Jan 2014 00:53:17 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> >>>>> On Thu, 2 Jan 2014, Ryan Hill wrote:
> 
> > In case it's helpful here's what FOSSology[1] has to say about some
> > common packages that people have uploaded to their demo server.
> 
> I don't get your point here. The licenses of a package have to be
> checked in any case. Why would it be more complicated to check the
> full set of files in the tarball, instead of the subset of files that
> the package will actually install?

I was trying to see how many packages contain licenses that aren't already in
LICENSES, assuming these would be ones that we would have to have a srcdist USE
flag for.  Rich said that is was rare.  I'm finding every package I've checked
so far would need one.

Either way I don't care what you do.


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ian Stakenvicius]

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

On 02/01/14 11:28 AM, Luis Ressel wrote:
> On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius
> <axs@gentoo.org> wrote:
> 
>> ..or we could just do this, using the existing RESTRICT="mirror" 
>> that's already in ebuilds -- have a DISTDIR and a
>> NODISTCACHEDIR, NODISTCACHEDIR defaults to DISTDIR; if
>> RESTRICT="mirror" then distfiles are saved to NODISTCACHEDIR,
>> otherwise are saved to DISTDIR.
> 
> IMHO, this is the best solution proposed so far. It doesn't need a
> new USE flag duplicating information which is already in RESTRICT
> (or am I missing some corner cases here?), and it doesn't bother
> those who don't care about this issue with new distfiles-*/ dirs,
> as with Kent's proposal.
> 
> @Kent: Why do you think another distinction for RESTRICT=fetch is 
> neccessary? If it really is, it could also be integrated into this 
> solution, but I don't get the point -- either you're allowed to 
> redistribute it, or you're not. RESTRICT=fetch just signals
> Portage that it won't be *technically* able to download the
> distfiles.
> 
> 
> Luis
> 

RESTRICT="fetch" requires the user to do their own fetching; since
they're doing that, it should be pretty obvious that the distfile is
restricted somehow.  Of course, they are still able to do whatever
they want, but I expect anyone that is keeping DISTDIR and
NODISTCACHEDIR as separate targets would know to not place the fetched
distfile in their self-distributing directory, or at least know to
read the license restrictions already present in the listed LICENSEs


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

iF4EAREIAAYFAlLFnksACgkQ2ugaI38ACPCI6gEAmBwKJ3+ce0zkrimGeb6oORVv
a2WteMNC9VVeZ+Jce4oA/2ys6+VPZ5AGheVrfL9eakupDPGwbxif78qC6PQ2D28k
=gqBF
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Luis Ressel]

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

On Thu, 02 Jan 2014 12:13:47 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> RESTRICT="fetch" requires the user to do their own fetching; since
> they're doing that, it should be pretty obvious that the distfile is
> restricted somehow.  Of course, they are still able to do whatever
> they want, but I expect anyone that is keeping DISTDIR and
> NODISTCACHEDIR as separate targets would know to not place the fetched
> distfile in their self-distributing directory, or at least know to
> read the license restrictions already present in the listed LICENSEs

Yes, I totally forgot that. Portage doesn't download these files, so
there's no point in creating a variable telling it where to put them...


Luis

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-dev] Re: RFC: new global USE flag "srcdist"

[Ryan Hill]

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

On Thu, 02 Jan 2014 11:10:54 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> On 02/01/14 07:50 AM, Ryan Hill wrote:
> > 
> > Maybe we could add RESTRICT=srcdist 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.
> > 
> 
> ..or we could just do this, using the existing RESTRICT="mirror"
> that's already in ebuilds -- have a DISTDIR and a NODISTCACHEDIR,
> NODISTCACHEDIR defaults to DISTDIR; if RESTRICT="mirror" then
> distfiles are saved to NODISTCACHEDIR, otherwise are saved to DISTDIR.

This I like (except the name, but mine sucks too ;p).  Portage should probably
check both dirs when searching for distfiles so it can find manually fetched
files the user may have dropped into the wrong one, and also to maybe warn if
sources are found in distdir for a mirror-restricted package (or just move them
to the right place itself).


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]