[gentoo-dev] Re: RFC: new global USE flag "srcdist"
> 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 pgpDS40rx2lsP.pgp Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 16:07:22 -0600 Ryan Hill wrote: > On Thu, 2 Jan 2014 16:20:09 -0500 > Rich Freeman 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 16:20:09 -0500 Rich Freeman wrote: > On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, Jan 2, 2014 at 4:11 PM, Ryan Hill 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"
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 19:17:50 +0100 Ulrich Mueller 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> 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.
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, Jan 2, 2014 at 1:17 PM, Ulrich Mueller 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"
On Thu, 02 Jan 2014 12:13:47 -0500 Ian Stakenvicius 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> 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 pgpUAkgIM_KBT.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
-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 > 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"
On Thu, 2 Jan 2014 17:53:45 +0100 Ulrich Mueller 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Fri, 3 Jan 2014 05:37:33 +1300 Kent Fredric 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
> 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 pgp8RYngpebjb.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 05:28, Luis Ressel 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
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 02 Jan 2014 11:10:54 -0500 Ian Stakenvicius 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
On Thu, Jan 2, 2014 at 10:25 AM, Michael Orlitzky 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] Re: RFC: new global USE flag "srcdist"
-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] RFC: new global USE flag "srcdist"
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] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 02:18, Ulrich Mueller 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
Re: [gentoo-dev] Re: RFC: new global USE flag "srcdist"
On 3 January 2014 01:50, 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. > 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
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
> 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 pgp7lfWsih_Dy.pgp Description: PGP signature
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
> 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 pgpoMsPCZ2uTk.pgp Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Thu, 2 Jan 2014 06:50:06 -0600 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/ -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
> 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 pgpY4dNOmSM_Q.pgp Description: PGP signature
[gentoo-dev] Re: RFC: new global USE flag "srcdist"
On Wed, 1 Jan 2014 23:28:54 +0100 Ulrich Mueller wrote: > Hi, > According to GLEP 23 [1], the LICENSE variable regulates the software > that is installed on a system. There is however some ambiguity in > this: should it cover the actual files installed on the system, or > everything that is included in the package's tarball? This question > was asked several times in the past and arose in bug 492424 [2] again. > > 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=" > srcdist? ( )" > > 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 Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
> On Wed, 1 Jan 2014, Rich Freeman wrote: > On Wed, Jan 1, 2014 at 8:51 PM, Michael Orlitzky > 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 pgpT7iRKgvQPa.pgp Description: PGP signature
Re: [gentoo-dev] RFC: new global USE flag "srcdist"
Dnia 2014-01-01, o godz. 23:28:54 Ulrich Mueller napisał(a): > LICENSE=" > srcdist? ( )" > > 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 signature.asc Description: PGP signature
