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 92607138239 for ; Wed, 19 May 2021 13:59:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 480CCE0823; Wed, 19 May 2021 13:59:41 +0000 (UTC) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 DD0A8E0822 for ; Wed, 19 May 2021 13:59:40 +0000 (UTC) Received: by mail-ot1-f45.google.com with SMTP id 69-20020a9d0a4b0000b02902ed42f141e1so11818527otg.2 for ; Wed, 19 May 2021 06:59:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+NHivuAgiDc9vY26Fa+fTH2BIf7/0girNnZm1vbEvs=; b=n2/0ZCJwSQy8hCI+AxNuBjXWQmzeCt78kALf8l6v6JJ+Jyt7V2XcX5JjtUa69087Qy IkiSRUkgcNWOt0wgfOPK1gsrqLbGALL7+3SHf2tX+MB+m6UwMb8j28x6KAPQlAxCrxCY Znhi3mDCMdKZACQsju++js2p888jrET0tPY2sf4BznL4QID38Bld0Iq+lgQJfBGvgxgd tW4CH+ojYBXjVm9mBL8kwV5o/x889N8XTTys9XZZAaRKu04ITa+gVQAeQU/PkOsPriJM Z7HqoJqZ8GaqCsC/NnwCDGjmLpXZbiljKmZpTj0mdQFF07zBHuPn1eUd4X90KpoA77rx KDwA== X-Gm-Message-State: AOAM530vzInjr2eC2MUxSEyDWjULbpvcRopqdmcx5uSB+MD3Rjzj+jpy aUM6OTfHSai1LzkCnbK9r2uO8ZAGlt/r8XnWCbZbUEF4COI= X-Google-Smtp-Source: ABdhPJxm/adMbAIi1oHqHtVCl+PPYDe1ecBXPzbmqbPDwIXZyZ516iQb0UTZKuLYwJdyBUnTJzLW1x+5ZZVieZFiRIY= X-Received: by 2002:a9d:51c7:: with SMTP id d7mr8937234oth.51.1621432779374; Wed, 19 May 2021 06:59:39 -0700 (PDT) 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 References: <68e2876e-f500-210c-8bc5-f9d147dd6d09@gentoo.org> In-Reply-To: <68e2876e-f500-210c-8bc5-f9d147dd6d09@gentoo.org> From: Rich Freeman Date: Wed, 19 May 2021 09:59:28 -0400 Message-ID: Subject: Re: [gentoo-project] RFC: Re-evaluate GLEP-0076 and copyright policy To: gentoo-project Cc: Gentoo Council , Gentoo Trustees Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 5746fea4-e40f-4f81-abfe-80bb99009f1d X-Archives-Hash: 2d0726a83d42aea686005dbdcf233b95 On Wed, May 19, 2021 at 1:03 AM Joonas Niilola wrote: > > This causes few misunderstandings with the requirements. Is the legal > name sign-off required from the *committer*, or from the *contributor*? So, you are probably referring to case 4, where a contributor makes a certification to the committer. I think it is a fair point that the policy doesn't state whether the contributor has to also provide a sign-off using their real name, or if some other way of providing this certification is acceptable. > What about a contribution where the author just adds a patch from > upstream, how much is covered by the Gentoo copyright policies? Well, I'd think that most of these are going to fall under case #3 ("The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate free software license..."), unless we're talking about patches to non-FOSS code. That seems pretty unlikely to come up, but has it? > We've turned down many contributions in the past because the contributor > did not wish to share their real name. Too many. We've also merged > contributions from Github accounts with no history, and absolutely no > way for us to determine whether the affiliated name is real. This is a fair point - we basically assume that if upstream accepts it then we can accept it, but I don't think anything else is practical. If upstream distributes a tarball under an FOSS license, and we mirror it, we can't really go auditing every upstream to ensure every one of them actually has the rights to their code. I think the concept is that we weigh the actions of projects above the actions of random individuals. > Heck, you can't even tell if the name I use is real. This has been discussed a fair bit already I believe. The policy is intended to cover Gentoo with a reasonable amount of due diligence, and also generally create a professional atmosphere not full of random pseudonyms. However, we didn't want to get into a situation where we're harvesting a lot of sensitive private info like identity docs, especially since validating these requires some expertise and probably isn't practical online. Ultimately the policy was intended to find a balance. No doubt you could make it slightly more strict or slightly less strict and the argument could be made that either is acceptable. Much of it was based on what the Linux Kernel and other projects do. That doesn't make it automatically correct, and the kernel doesn't redistribute random stuff from random other projects, so we can't conform completely to it. > Therefore I suggest we update the GLEP to *clearly* state that *only* > committer's sign-off is required. Well, either way it probably is reasonable to make it explicit whether a real-name sign-off by the contributor is necessary in case #3, and whether that needs to make its way into the commit itself as an additional signed-off-by line. > (And I feel like even that is > debatable, but at least a start for now) It certainly was debated when the policy was enacted. I'm not sure that rehashing the debate is going to change much - the arguments haven't changed, and I don't think the Council has changed all that much either. However, they could speak for themselves... > Then a small note about ebuild's copyright header. The GLEP states: > "All copyrightable files included in Gentoo projects must contain > appropriate copyright and license notices" > > but do ebuilds, at least most of the ebuilds, contain copyrightable > innovative work? Most ebuilds are just following the basic skeleton form > and calling functions from eclasses and EAPI. Therefore I suggest the > copyright headers in ebuilds shouldn't be mandatory, but opt-in, if the > author feels like it contains innovative work. So, only a court can make this determination, and courts in different jurisdictions could make the determination differently. IMO it is a MUCH simpler solution to just leave the line there for everything than to have debates and escalations over just how much content it takes to make an ebuild copyrightable, especially when you start throwing eclasses and so on into the mix, where setting a variable changes the behavior of the ebuild. There is little harm to have the additional copyright line, but not including it could limit our rights. Also, in the case where the ebuild at some point in history was part of somebody else's repository (perhaps in an earlier revision the maintainer isn't aware of offhand), removing the copyright notice might provoke offense. I'd strongly recommend keeping the current policy if only to keep it simple. Really the only inconvenience is updating the year. > And why couldn't we use the ./header.txt to indicate this copyright for > every ebuild, why must it be replicated to each .ebuild file? Including it in every file is generally considered a best practice - you can google that in policies from various reputable sources. Not giving sufficient notice can limit rights under copyright law in some jurisdictions. Just about every FOSS project does it this way. > We also have the metadata/AUTHORS file whose purpose I still don't know. You can find a lot of debate on this on the list archives. Basically it exists for a few reasons: 1. Some contributors work for employers who have a requirement to list their name in copyright notices. 2. Some files were sourced in a way that they contain non-Gentoo copyright notices already. (Eudev had a bit of a delicate situation resulting from this.) 3. Some developers wanted to have their own names in the copyright notices for their contributions. In these situations the options are to accumulate copyright notices (adding Gentoo plus others), or have the AUTHORS file where we can put all that in one place and keep the per-file details simple. The full history is found in git regardless, but the topic of copyright notice is sensitive to some. IMO it isn't intended to be a "credit" for work done, but some feel otherwise, and this policy was a way to keep the files simple and keep everybody happy. It basically requires nobody to do anything but tolerate a small file in the repository, but those who wish to be listed can ask. -- Rich