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 8B8F7138334 for ; Tue, 9 Apr 2019 21:01:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3F507E08FE; Tue, 9 Apr 2019 21:01:36 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 CCAC4E08FB for ; Tue, 9 Apr 2019 21:01:35 +0000 (UTC) Received: from localhost (pool-72-66-49-205.washdc.east.verizon.net [72.66.49.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: bman) by smtp.gentoo.org (Postfix) with ESMTPSA id 18922335D3C for ; Tue, 9 Apr 2019 21:01:34 +0000 (UTC) Date: Tue, 9 Apr 2019 17:01:30 -0400 From: Aaron Bauman To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14 Message-ID: <20190409210130.GG8129@monkey> References: <20190401032055.GA9497@linux1.home> <4bbfc34f-335f-5521-310a-b66ffd0d9a9a@gentoo.org> <5e30d658-80c8-b608-1505-dc08db3625bf@gentoo.org> 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 X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 02e077f6-e205-40b1-be8b-6f248df977d5 X-Archives-Hash: 593f25d5feaf65bc1f558ce8d651f234 --GdbWtwDHkcXqP16f Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 09, 2019 at 08:46:00PM +0000, Gokturk Yuksek wrote: > Hi, >=20 > Alec Warner: > > On Wed, Apr 3, 2019 at 10:04 AM NP-Hardass wrot= e: [snip] >=20 > I don't doubt people's good faith in proposing this policy and I'm sure > it's done with the best interest in mind. I apologize for not doing the > homework for the following question: did the Foundation pay for any kind > of legal counsel on this matter? I think one thing most of us struggle > with is that we are not lawyers. It would help to put people's mind at > ease if the Foundation consulted a lawyer that clearly explained: >=20 > - What exactly is the legal liability being addressed here? > - Have there been any precedent cases of copyright infringement > (constrained to the context of copyrighted ebuilds, or code of similar > nature) to make this a more realistic threat for the Foundation? > - In the case of a potential court case, how is the liability > distributed among involved parties? Would we be legally required to > track down the contributor (whose identity we may or may not have > confirmed yet)? > There is precent with the Linux Foundation and the DCO being enforced. That is why they spent so much time and effort in preparing the DCO... to guard the Linux Foundation from any copyright cases. I think it is safe to say that other precendents wrt copyrights can be seen in recent things like VMWare (sued in German court), SCO, etc. There are plenty of situations out there. > The reason why I'm suggesting this is because I've talked to a friend of > mine, who is a software patent lawyer, about the DCO and GLEP. Their > first impression was that the DCO itself has no clause for requiring a > legal name, so signing it with a fake name may not violate the DCO > itself. So the (informal) conclusion is that as long as nobody sues you > for copyright infringement, there is no legal problem with using a fake > name to sign the DCO. I know it sounds very obvious but the point is > that legal people have a better grip of the situation than we do, and > the community is more likely to take their word and justification for it. >=20 Is your friend interested in being retained? :) No, the DCO does not have an *explicit* clause mandating that a "real name" be used. I am not going to debate the interpretation of it by others, but if I *certify* something under a pseudonym or false name then how can I possibly be held responsible for it? The very essence of names are to associate things to someone. Drivers licenses, passports, library cards, and the list goes on... Note: If found to be using a pseudonym to sign the Linux Kernel DCO... I am quite sure you will be dismissed (I will find the real world example of that happening). If someone were too take you to court could you be held responsible under the guise of a pseudonym or false name? I am not aware of any countries that allow such proceedings, but ultimately I believe the first task would be to *prove* that you were the one involved before proceeding further. Of course, that most likely is some sort of physical attestation that must occur. This is all circumvented by simply using a "believeable" name and staying silent. I could easily submit patches to Gentoo as someone else and certify the DCO. Of course, this simply means that Gentoo can claim some form of ignorance/plausible deniability in the end. Ultimately, this would likely result (IANAL) in the false contributor being held accountable for any potential wrong-doing. --=20 Cheers, Aaron --GdbWtwDHkcXqP16f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEiDRK3jyVBE/RkymqpRQw84X1dt0FAlytCCoACgkQpRQw84X1 dt0PUQf/RjkBVLJeW/aMKasOBQaYJMZiqwF7D186bXuXaADPJExjEJc9aVFvdYgW 2uubM7tWmQYoewciDl0qXpFhRZIlXXjddcukTw1fo4z9LsD0MtJbW6tz7ymDLjf1 xncp+nhxhB35mHhKKurRZtivb4LIk21YpxC+opNecsQ+rG2DzutTo9LpiK/Nc7lf vtLZHN+8Xnm6h2KaXbWqBbw6pujYLNtRrtwhOcwsWMxfgnWl2xaL618dKZUTzpfg k+FPoXk+5mZ2za5CPqnO/EKbabJyTGW90bl45g2g7293/zEB5BDk0mk/eQ7F665p R4whMdMZXdfrK7aDUwVTfl0F9JjwTw== =XHa5 -----END PGP SIGNATURE----- --GdbWtwDHkcXqP16f--