Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
On Mon, Jan 27, 2020 at 6:41 AM Ulrich Mueller wrote: > > Historically, all ebuilds in the Gentoo repository were licensed under > GPL-2+. At a later point they were relicensed [1] to GPL-2. See [2] for > a rationale (or absence of it, YMMV). I think the historical policy made sense in its context, which was a world where all copyrights were to be assigned. In that case you can already relicense at will, so you still have flexibility, but by keeping it pinned at one version you don't get pulled into something by somebody else that you didn't intend. Now, over time the whole assignment thing became fuzzier and I don't really want to get into a largely-moot debate at this point over how effective those assignments were at various points in time. Today we are in a world where our intent isn't for the default to involve assignment, and so the v2-only licenses create (IMO) more problems than they prevent. > On the other hand, we would presumably never achieve a complete > transition to GPL-2+, so we would have ebuilds with either GPL variant > in the tree. Not sure how big an issue that would be. Updating ebuilds > wouldn't be a problem (as the old header would stay), but devs would > have to spend attention to the header when copying code from one ebuild > to another. Devs already have to be careful about copying code into ebuilds that go into our repo. Somebody could attach an ebuild to a bug and stick "Copyright Joe Smith all rights reserved" at the top of it. I think it would make sense to have a call for Devs to voluntarily report in and give permission for their contributions to be licensed v2+ with no change in copyright ownership and see what happens. I wouldn't be surprised if we could relicense 80-90% of the tree quickly. If that happens then we could just require it for new contributions (if we wanted to), and then over time the problem would just go away, just like an old EAPI. We could also stick warnings in ebuild comments like "# Warning v2-only ebuild - do not copy !" and maybe copy it every 20 lines if we wanted to be super-paranoid. I do agree with the general argument that much of this code isn't really subject to copyright. We could just do both an opt-in and opt-out approach to this. Have the opt-in so that we get as much explicit approval as we can. Also do an opt-out with a prominent announcement like, "hey, we're about to adopt GPL v2+ for all our ebuilds so if you think you have contributions that are non-trivial and want to object to those contributions being relicensed please let us know." It isn't an airtight defense, but it isn't entirely unreasonable either. Or we could just see how many fish we catch with a very conservative opt-in approach and go from there. We might not need to even consider the risk of an opt-out approach. -- Rich
[gentoo-dev] Last rites: dev-python/twisted-* (the rest of split packages)
# Michał Górny (2020-01-27) # Remaining split Twisted packages. All remaining reverse dependencies # are entirely happy with merged dev-python/twisted. # Removal in 30 days. Bug #706636. dev-python/twisted-core dev-python/twisted-names dev-python/twisted-web dev-python/twisted-words -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
> Note that we could easily revert from GPL-2+ to GPL-2 if it would turn
> out to be too much trouble.
>
> Thoughts?
I would prefer a single license for all ebuilds.
GPL-2+ or GPL-2 or GPL-... does not matter to me, I am willing to sign,
that all my contributions may be licensed also as GPL-...
IANAL, but I would expect that the license does not change anything for
trivial ebuilds.
The level of creativity ("Schöpfungshöhe") is not high enough for most
ebuilds.
Most ebuild contain only an obvious recipe to install the software.
--
Best,
Jonas
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
On Mon, 2020-01-27 at 12:41 +0100, Ulrich Mueller wrote: > The following came up in #gentoo-qa yesterday, in a discussion between > mgorny, soap and myself. Hey, I was waiting for the Council agenda mail to discuss this ;-). > So, the question is, should we allow ebuilds > # Distributed under the terms of the GNU General Public License, v2 or later > in the repository, or should we even encourage it for new ebuilds? > > I have somewhat mixed feelings about this. One the one hand, I think > that GPL-2+ should generally be preferred because it offers better > compatibility. For example, the compatibility clause in CC-BY-SA-4.0 > won't work with GPL-2. It will also enable us to switch to GPL-3+ (or GPL-n+, in general) in the future, if we ever have a reason to. > On the other hand, we would presumably never achieve a complete > transition to GPL-2+, so we would have ebuilds with either GPL variant > in the tree. Not sure how big an issue that would be. Updating ebuilds > wouldn't be a problem (as the old header would stay), but devs would > have to spend attention to the header when copying code from one ebuild > to another. We should work on getting approval from as many devs as possible, then the risk of inaccurate relicensing will be safely low. Then, there's the general problem of how much of ebuilds is actually copyrightable, and I don't think there will be any reason to object to it if ebuild doesn't have some really original code. > Thoughts? > I'm (obviously) all for it. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Should we allow "GPL, v2 or later" for ebuilds?
The following came up in #gentoo-qa yesterday, in a discussion between mgorny, soap and myself. Historically, all ebuilds in the Gentoo repository were licensed under GPL-2+. At a later point they were relicensed [1] to GPL-2. See [2] for a rationale (or absence of it, YMMV). However, in GLEP 76, GPL-2+ is listed as the first choice for licensing of any Gentoo project [3]. Also, I am not aware of any official policy that would forbid the "v2 or later" variant for ebuilds (any pointers are welcome). So, the question is, should we allow ebuilds # Distributed under the terms of the GNU General Public License, v2 or later in the repository, or should we even encourage it for new ebuilds? I have somewhat mixed feelings about this. One the one hand, I think that GPL-2+ should generally be preferred because it offers better compatibility. For example, the compatibility clause in CC-BY-SA-4.0 won't work with GPL-2. On the other hand, we would presumably never achieve a complete transition to GPL-2+, so we would have ebuilds with either GPL variant in the tree. Not sure how big an issue that would be. Updating ebuilds wouldn't be a problem (as the old header would stay), but devs would have to spend attention to the header when copying code from one ebuild to another. Note that we could easily revert from GPL-2+ to GPL-2 if it would turn out to be too much trouble. Thoughts? Ulrich [1] https://dev.gentoo.org/~mgorny/articles/a-short-history-of-gentoo-copyright.html#relicensing-to-gpl-2 [2] https://archives.gentoo.org/gentoo-dev/message/7a857384b8929cb930329eb59e27636a [3] https://www.gentoo.org/glep/glep-0076.html#licensing-of-gentoo-projects signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: virtual/cargo
On Mon, 27 Jan 2020 10:48:51 +0100 David Seifert wrote: > On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote: > > On 1/26/20 9:46 PM, Georgy Yakovlev wrote: > > > # update your rust packages running emerge with the > > > # --changed-deps option if you have problems > > > > If this advice helps, you have violated the PMS. > > > > Agreed, if possible revbump any critical ebuilds, so we can avoid the > virtual/pam disaster this time round. > > All critical explicit consumers switched a while ago (mozilla & co). Consumers via eclass switched about 1 month ago. I considered revbumps, there were 44 ebuilds and 23 unique packages,about half of that with stable keywords. not that much, it's not pam after all. I did bump some meanwhile. There will be no disaster. pgpoJ8exDAmlk.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: games-action/cs2d
# Ulrich Müller (2020-01-27) # Removal requested by proxied maintainer: # "Game already available in Valve Steam." # License issues, unclear if zipball is redistributable. # Masked for removal in 30 days. Bug #703496. games-action/cs2d signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-python/twisted-* split & related, no revdep packages
# Michał Górny (2020-01-27) # Old split Twisted and related packages with no reverse dependencies # and only Python 2 support. # Removal in 30 days. Bug #706636. dev-python/axiom dev-python/epsilon dev-python/pyutil dev-python/twisted-conch dev-python/twisted-lore dev-python/twisted-mail dev-python/twisted-news dev-python/twisted-pair dev-python/twisted-runner dev-python/vertex dev-util/buildbot-slave -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: virtual/cargo
On Sun, 2020-01-26 at 21:53 -0500, Michael Orlitzky wrote: > On 1/26/20 9:46 PM, Georgy Yakovlev wrote: > > # update your rust packages running emerge with the > > # --changed-deps option if you have problems > > If this advice helps, you have violated the PMS. > Agreed, if possible revbump any critical ebuilds, so we can avoid the virtual/pam disaster this time round.
[gentoo-dev] Last rites: dev-python/zsi
# Michał Górny (2020-01-27) # Dead upstream. Last (alpha) release in 2007. Requires old version # of Twisted. Python 2-only. # Removal in 30 days. Bug #660660. dev-python/zsi -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
