From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 070CE138334 for ; Mon, 11 Jun 2018 18:08:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8581DE0880; Mon, 11 Jun 2018 18:08:44 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37A58E087B for ; Mon, 11 Jun 2018 18:08:44 +0000 (UTC) Received: from [192.168.10.30] (ool-4571a16e.dyn.optonline.net [69.113.161.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: np-hardass) by smtp.gentoo.org (Postfix) with ESMTPSA id 2E10E335C91; Mon, 11 Jun 2018 18:08:43 +0000 (UTC) Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy To: gentoo-project@lists.gentoo.org, Rich Freeman References: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> From: NP-Hardass Openpgp: id=862040BE422755F27FDE13D5671C52F118F89C67; url=https://sks-keyservers.net/pks/lookup?op=get&search=0x671C52F118F89C67 Autocrypt: addr=NP-Hardass@gentoo.org; prefer-encrypt=mutual; keydata= xsFNBFTkWCYBEADjDSP3/MDba3hDgUjy/8w2PU/kzx+AWwWkXuA3zUhBnS7AVK2Zh5gajysZ OWAkmZ0VmrzSHICQzYosyhq+YVIdTg5LvIxsG1fj2rSEMbqk9mtjdNDsoUmzUkECOL/Txph1 u46vtnMy97Gs82imE3uCBIQkxc+aUesePXeQGOh6EDcxMvFcn8x1lhXE244lES5Spu72Wen4 cYRpPboRTbuUxXUwrOIAOzF2eX5BDipZVKmrV9i5SC3oQIG1MnJdHDLWhDm3XQjlEsvH5Rge 55bvXFVs6Hzdv3SUI330E6W15kLt0Ij94nJqOgWCPfKu+7Tb2UYlVlCkiIFujIWxLGaQRXU2 3wOu7TuGJ0NQzP1lwCImdydEF+BL61l6awFI1ixwgZQGkzaEvXMhc6PltM12y5poFvcQXK+P aLdztY0cLSlhg36HZb+E8bavNLLIw4tJ2LKx8YmMNFfoIVAN33wU2QZ08SyT5VTCi8svU0U+ 2n8e3TA23gx+OHyUvjwNdFm5NDi0sIpeYpgMfUSjTO7pq0JEAQLTY//9MjqmmicXpvMnqA2X NrZZXaxs19yApzxfbFQegg9tgNiSeYONtIXWQinznfv+h3GY7K6zKhyq5IL0ji/Gf2l/+1WD VB/h6OJGbKqydPZnBiQRC6mt/lpkE5/Z1qHzzrNlTT0RTdNDlQARAQABzSJOUC1IYXJkYXNz IDxOUC1IYXJkYXNzQGdlbnRvby5vcmc+wsGWBBMBCABAAhsDBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AWIQSGIEC+QidV8n/eE9VnHFLxGPicZwUCWi8lgwUJCQ00XQAKCRBnHFLxGPic Z7toD/9BlYZ9Lk7ejlvkenz+EPqySkZAHERwUS5hqBiOTarVJZtjm7uGCbzhCltInsWKHREN jIboWsCzHPdnqeQ7BiRjUCbLXctqsW9kWvxBxJaCKqy9XqG7WWqgm7gxqYxDp9EM4mV1JeU4 aSXkLJu/JlLaC0FWvQNFJZhhK7VQwcMmz1mmFZayXFce/lpKn2NWwqQc6gKRQlBvKaY+ohpP 0Ixt7SiU2FqgsfR8tsGxiMaZnq4ULbfzOtee3zSzIaPpF1EzoKmnNKzVdSW7QY94OJQKkFmt KWi0+yk2lYfMVPiYC+Ph8FXe0Cqk//nECA+OGtvLo5bc7mtgCdCqfQVo7ds0HQ9gdW8Hq55u evrVN+6TwoPr0n50wckJ3cQy9Yj1gKWJO/XNciLJoZ2fJ9jAsaP9LlITKeLI1yWqt2LaNMfP gVn4eS/jNstuMvyA0qgmELQ/VItDrC30ow7I8yarPlBpywIW8jpBZQeujujshDfmYJJatt72 ETT6Us5f/zDpb7V8g+feReUzo1bDsIlXxhSC/hrJIQUdsRj5kM2cHgMttdj5/+9mMhxLVXkK AlgJs2evnp3WmrOovYoLfN/pkVyxAbXKu0Y/c7L+NMPRHW+V3oUXGrphw+Uh/S+d3NHG3gGz 1Y0H6OyHHai9f8iXu4aTqhVatNZFmYlywlS3/Wz/Lc7BTQRU5FgmARAA4ThPsCyVb6QBhtRU 5vUuWMuzhXpdUr151ccXYqYBXn1h45hW9qoZo8Y7xQp6cGJSECSNmTkJU9FMN48Ewn3+YIxa uJOWar+eCvh++TvPVqjo/UQZqTK29NUBiL5aSC0pU49Z5Ve2TXYGhdcZT0OQM4A1MTlRfIaV tqlPfoqifsNGjiwpjRoo4AWYADIfhajvHCDJ5ITka+T07DBFOBSy98SaoKNfdaClb6tmLBs7 hroKpCCijfBe20UMeaKN6zQuhW8GR3VzpRC/G9HBEmH6GxiVmBkhEQjgX5aTS7T/jz2YZrI6 mS3zKZ7gEByjhxUOS83UON99aOqnMPUphXnjIPIPydBHYVlY4egLKPI91nFAZv5DYIzyERux KE2w2f9Xns7wyEOYhqddOTZ0lio4oQCc/sR040rKtL6qOciC1z3jDeYTrQE410eGF71SvuiN ceThbAty26zYQAFxvlimrgTTVkLOSsCz6+/SWoD42gwVYwQ4hRoCwYzuC/ILGmECoiJXFgtR A/gK/5g7c05depLSo9VH8/+b4Cxqt+U9+beqfxtr+9b5w9ut6AZcZLj25s40gc19nJQkEl49 S2XfJ7lkczuBj2K8T0ZZ82woPDu2W3UORYU0iW+0WuEZ5DIZsOy5g8YWYFoeWfzI9TPkHAAd ccZtE8r1h2IoQ7RBSr0AEQEAAcLBfAQYAQIAJgIbDBYhBIYgQL5CJ1Xyf94T1WccUvEY+Jxn BQJaLyVzBQkJDTRNAAoJEGccUvEY+Jxnf8YP+wQlCLyFetSuMHd3ZO36HE1ohU+Mvspa6Z1a 97K1ECG9xDNNodHtQ7j1qCTYqKH2N2RWgErowk9RT8y8ok+1fJHD/94qYpmb++R1g2m1XmEC tssGv40uHI0TxVdwu3xpfdGTW8roQOMngoTP0RW5BNWTqfAv7+LEMbD9kber1AbyLJzxYdgU sxwHnQ6pRdcyb75drG9Mo1br8s6knTvW2i+5JCKSud/oexvSC0w2SegPvlsrqPWJoWQ5Yo7g IAQQG6KjdYoVy3m/goNcXiIHnuFv5dWfnOyP+Th2sVgy2VX3M9jsejFvXABYwVyslkIXFudm UqofjSD7OAz9jMOrAgMKdI6ez40GJaK9/aCEynm1ckwzEBpjB9H3TtXuhxwsFB/HqIMxYRCw 7vrKh7of3kzc6nsmn07Nd8sPElx/4wTc6QXyM4OXqmIE5tSgKYt3ns2o6PALqBpWx8FaHafg 4zFRY3+tEx0/lw8/yYDYiRRFfqkuiaqItL6ugSfUXdB13um+606IexFZCiwla1CtnGUx3Byw NQnAYOdUKHkKeQ9mYXGnScl6P6OJBXV5xBmINNmzaRGQWQAXN1/f3AJ7ZLqWdzOT96yKR1RY Qtfcn5WlfuZfjQBVNEWzzTZb/8hAlrFJLMwPUDl9AWz+surEACrh46BT4W2voigsA7dibW6E Message-ID: Date: Mon, 11 Jun 2018 14:08:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c1NnCwBmX1Vv6jnkOHxNd43rIlyW1xO4H" X-Archives-Salt: 7e17011d-a6b9-480c-af3a-c00131db4275 X-Archives-Hash: 6c937867dd3f387650365869000ecea2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c1NnCwBmX1Vv6jnkOHxNd43rIlyW1xO4H Content-Type: multipart/mixed; boundary="upWD4unufG3JDZ3K4myknOh5lLFvyrtUu"; protected-headers="v1" From: NP-Hardass To: gentoo-project@lists.gentoo.org, Rich Freeman Message-ID: Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy References: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> In-Reply-To: --upWD4unufG3JDZ3K4myknOh5lLFvyrtUu Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/11/2018 01:07 PM, Rich Freeman wrote: > On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass wro= te: >> >> On 06/10/2018 04:34 PM, Ulrich Mueller wrote: >> >>> Copyright Attribution >>> --------------------- >>> >>> All files included in Gentoo projects must contain an appropriate >>> copyright notice, as defined by this policy. >>> >>> A proper copyright notice appears near the top of the file, and reads= :: >>> >>> Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and othe= rs >>> >>> The largest contributor is whatever entity owns copyright to some >>> portion of the largest number of lines in the file. Additional >>> contributors can be listed, but this is neither required nor >>> recommended. The "and others" text may be omitted if the explicitly >>> listed contributors hold copyright to the entire file. >> >> Why is this not recommended? >=20 > So, I came up with this to try to keep it as simple as possible. >=20 > My concern was basically analogous to the BSD advertising clause > problem. If you start accumulating authors on this line then it gets > unwieldy. How do you draw the line? >=20 > I suggested drawing the line at whoever touched the most lines, mainly > because it is simple. >=20 > IMO ANY solution is going to be imperfect, so simple trumps all. >=20 > But, it certainly isn't the only possible solution to this problem. >=20 > Keep in mind that notice is not the same as > authorship/copyright/credit/etc. The "and others" is important. > Being #2 doesn't in any way diminish your rights under the law. The > law simply requires a notice, so we need to come up with one. It > shouldn't be viewed as "this is the only important contributor to this > file." If we could not have any notice at all legally then that would > be simpler still. Git already tracks who did what, and should always > be the place to go for this info. >=20 >> If developer A writes 51% of the lines of an ebuild and developer B >> writes 49%, should B not be listed? >=20 > Under the policy, no. >=20 >> What if all the metadata lines defining variables consists of 75% of t= he >> file and was written by A, but the core functionality of the ebuild (2= 5% >> by size) was written by B? >=20 > Under the policy, "A and others" is listed. >=20 >> If A writes an ebuild, and B replaces a majority (>50%) of the ebuild,= >> should B remove A from attribution? >=20 > Under the policy, yes, assuming this is noticed. The policy does not > require checking on every commit, but only when the issue is > escalated. That is actually a change from the wording which tried to > keep things more strict. >=20 >> I think that specifying that substantial (though not necessarily >> specific in defining this) contributions/contributors should included = in >> the copyright attribution and that substantial contribution attributio= n >> *is* recommended. >=20 > So, the issue then becomes whether we have to define "substantial." > The goal is to have something actionable. Anybody can run git blame > easily enough. Figuring out what is "substantial" is harder. >=20 > But, the other change to the policy was to relax this and not worry > about keeping it as up to date. So, in that spirit maybe we can be > more vague and let it be dealt with via escalation. >=20 > That seems to be the approach the Linux Foundation takes. As far as I > can tell they have no policy regarding copyright notice - and the > contents of their files are all over the place. Presumably committers > make their own judgement calls, and if somebody has a problem with it > they point it out to the Linux Foundation. >=20 > That said, the fact that this is basically happened with the eudev > copyright notices didn't prevent it from turning into a bit of a > tempest in a teapot with all kinds of accusations being tossed around. > It was dealt with upon escalation, but people tend to go crazy over > this stuff so some kind of policy that an ordinary dev can understand > wouldn't hurt, so that the issue is prevented. That was the goal of > the policy. >=20 > A big goal here was to keep it simple and understandable but not too > vague. It shouldn't need constant appeals to Trustees/Council/whoever > to apply to individual situations. >=20 > To the extent that the notice doesn't truly give credit to > contributors I'd call it a feature and not a bug. I'd rather have the > notices viewed as useless for that purpose, because then people won't > constantly squabble about how does/doesn't get included on them. The > ideal choices would be listing everybody or nobody, but everybody is > cumbersome, and nobody doesn't seem to be legally valid. So, listing > one by name preserves the nonsensical nature of the notice while still > meeting the legal requirement. Or something like that... >=20 Keeping it simple is fine by me. As mentioned in my other reply to Ulm, I think I was conflating contribution attribution and copyright assignment. As long as "and others" (being unnamed) doesn't prevent others from retaining their copyright (in practice as opposed to in principle), SGTM. --=20 NP-Hardass --upWD4unufG3JDZ3K4myknOh5lLFvyrtUu-- --c1NnCwBmX1Vv6jnkOHxNd43rIlyW1xO4H Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEv526yLNI+t7RHfJZHNlBHbKvGPsFAlseuqcACgkQHNlBHbKv GPthLQ/+MWHjaFH7LyOraqZ87WkVcy88kxusjiTkDVFVDLjgkO+O+d07SWBEv/5g Boav9icha+nHRr+zYcpCUcfKdtyFZJ3OZ9lpwF8CC+146oJfj+woJZSVgWF8UtE4 x3BWeSTwwbX5DOsGmMyVs+/naHw1r95+xGhE00ipgM6+0QR0u519ZVw3ZsCeQfpb A5nFgotgYyMWV3BY5wIcYtJDBC9EomwO6tESdasjmYa0r35Z9ZoqPH012rmS1zdk CbYTzglkB7+YplD+uT4Seq9QBrfHrQ0+p+8Kt+z3VDvWSNPJ7tBaZNDq+bXZi8Du 05a94wy1MBauwoxu4eF1LiNGWvEssJt95g52YcIzkkLjig2w8Ql0BfU/J5lVe3G8 zO6bxMTyMGyz95lpdjRKMFr1D8nTayQQF+z++WHV/SmecBtUlnba4mKsNkpiR05g cHra7Qydw4T8LLFMrC4QSCIUCk4Uz74wJEx2YCJy1ih06eM2AFfci665LIo0/P30 OpYN6vvNoVx4v367VNwrOnDodVwUERoIjJyiPTGlWwQJnWKLDEfZYmxT770xHR7o 60M740AfvCA+jHmzIlDsKoTVFr9UKCXkJEg5JXhqgFp8Q9A1Oz7htwnFVsE7wPCd QVUNwZ19y4lgzIp4JjQTnr1XlHC1Tavm4rz3ZovXgspOrtO/TMQ= =uiwE -----END PGP SIGNATURE----- --c1NnCwBmX1Vv6jnkOHxNd43rIlyW1xO4H--