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 6C5F7138334 for ; Sun, 17 Jun 2018 02:15:08 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B2D30E0848; Sun, 17 Jun 2018 02:15:06 +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 66029E0835 for ; Sun, 17 Jun 2018 02:15:04 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id 34DE8335C7F for ; Sun, 17 Jun 2018 02:15:03 +0000 (UTC) Date: Sun, 17 Jun 2018 14:14:36 +1200 From: Kent Fredric To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy Message-ID: <20180617141436.2745dcaa@katipo2.lan> In-Reply-To: References: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> <20180617123737.122ef070@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/TQ5QeM43B5Kz_FwrEJy4zxe"; protocol="application/pgp-signature" X-Archives-Salt: 9be79c76-216a-4c0c-a3a8-da40bb066751 X-Archives-Hash: 8eebe462d1c1c197c2d7512ec0b6f251 --Sig_/TQ5QeM43B5Kz_FwrEJy4zxe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 16 Jun 2018 21:39:49 -0400 Rich Freeman wrote: > On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric wrote: >=20 > There really isn't any negative consequence to the person listed on a > copyright notice being "wrong" as far as I can tell. I use quotes > because as long as the person listed contributed SOMETHING to the file > the statement is still accurate, even if non-ideal. I doubt a court > is going to decide a case differently because the person listed on the > copyright notice wrote 20% of a file vs somebody else who wrote 40%. > As far as I'm aware the name listed on a copyright notice isn't > binding at all on a court - the court is free to determine who > actually owns the copyright based on the facts of the situation. The > notice simply serves to inform the recipient of a work that it IS > copyrighted, so that they can't claim innocent infringement. The work > remains copyrighted all the same if the notice is not present, and > future infringement after receiving notice would not be innocent > regardless. Surely then, the most effective and usefully correct copyright notice (for portage trees at least), would be: "Copyright Gentoo Foundation and Contributors" Or similar, instead of abandoning the Gentoo Foundation Copyright and using a random persons name? Otherwise most of the proposal in regards to portage trees, is mostly a waste of time. > (So the "Copyright Gentoo Foundation" lines will be > phased out.) Because otherwise, the objective of putting a humans name there is misleading at best, and serves no objective purpose. If the objective is to simply denote the file has a copyright, that format should do the job. ( Additionally, I have no opposition to generating a package-wide file that notates contributors, such an approach is routinely satisfactory for debian with regards to marking up which files have which licenses without needing to inject the license in the file, and has the benefit of exposing that metadata to consumers who only access via rsync or tarballs, its just in-band in-git data that I find most obnoxious due to being functionally redundant ) --Sig_/TQ5QeM43B5Kz_FwrEJy4zxe Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAlslxBwACgkQ6FQySxNm qCAMUBAAl1hKWY5COnVS29CtjajGx7TqomUcSGUhXWI2K1c7qitI5F/kyh5CRlHJ /1rC4AHb7ayQ5JYYjMDwQPf4PDF97H6/dVzFcvFY/nU5CE86OyaQgAU2M4KoRuvZ 0A43HoYJSiD4xVXb4iUR76TnjmC0+czXsUA467SmXvDBJ3VDIQSuolLInNo26fdH hHlkVAnI24nTc0V07Mkic/x1OFJ19AtGMgi/zeFZMDd7bXX9elZnR2tBL0LgLCDc jyfKIDbQDF0k3SkbZWbeP+u4tvHz+ashGjZruOg71HVFi8bQNPQ9DiCD0ft5HFqA y4obhScwET2epD5SpnjxIE02aageybcc9LDHdEXGT0VS/5xzQSc8Au6XtFO5vEQa tc5ZOEFLVzI4kuPkKIpOH/3z79p3mLP6E8F/wOUbKsDyN3OtiEs/qzoeNJExD0wu SO8UwfM50+QvqSVJPJYT0ChlKERT3JajdX8MCFweGsuZLhYK1fx2ND/v/FvNMmvl 2ntTSVsMmvJeoc6ukcPxhW2VtpjDU+VIvjikhwx+6HVvML+AwRqnVzVMcDxmqlxy RPpqDWeoS8d0JJuJoEOukwD08gajJlHIoK+pzZw1NDTMOBKIkPeq361Lk0JIXldg bEyTMg2UNCTFWe8DmcJLIgvUL+Mpr0olcXFg9G2Vu/bcouhC3cU= =PCjD -----END PGP SIGNATURE----- --Sig_/TQ5QeM43B5Kz_FwrEJy4zxe--