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 254D8138334 for ; Thu, 11 Oct 2018 18:05:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E4114E093B; Thu, 11 Oct 2018 18:05:32 +0000 (UTC) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) (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 A4736E093A for ; Thu, 11 Oct 2018 18:05:32 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id c10-v6so4549062pgq.4 for ; Thu, 11 Oct 2018 11:05:32 -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; bh=iOmxNmnbLN65wMh3dkLq1xcuaXnjd73UjOSps0E6eXA=; b=hmt30QLiLEm2KI/8s44f0Yk3pUHEqR9IfRmPs76yT3IYNyKoa2zdKQ47irk8mD5fIt g7MnFjtqDJwTyCvM5J7wn6bsEVpy76K955Nd791NZ7iSHzG/qE+KKY6+T/NZ8K3w6a5h V4bSHEE6HRwCF3bCB6rDQ7btNxHR986rjbpVCPZCE5i+a6tT2glMPfCMs2RPY4KTbIFt X7dn+wk7rcQrObUimwkwKC3rxfxfGvCjXNBaH+hNVpLCdTkv71zYO2TnM+En4gSp/EZX u0rOr4LZJx8OL+YStamYPq+epZt0kUvEPhQ4Fd88dk53thvw/4j9sbxqsIefCqPsEVh5 JaYA== X-Gm-Message-State: ABuFfoiueYMHWAkxoMcp28HvEUtGPUkVXnwAUAWLAJUSJJ/yhTGf7eY9 nE+jblRTQ7JzTdNxToVmatv8He88UGajPPGWxmYWrQ== X-Google-Smtp-Source: ACcGV60qA6SOWI9sNfdbqpsfbOYx2D4PDMHFcKhxX9gukijfUZZzjfXMR3K5ykIqNOkbiVZ0X2iwizqy4TSy1MOuMQU= X-Received: by 2002:a62:c252:: with SMTP id l79-v6mr2536305pfg.141.1539281130612; Thu, 11 Oct 2018 11:05:30 -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 MIME-Version: 1.0 References: <20180930140524.015249f0@sf> <20181011153139.7700484dc6c452ed570df66a@gentoo.org> <20181011081208.00646646@professor-x> In-Reply-To: From: Rich Freeman Date: Thu, 11 Oct 2018 14:05:18 -0400 Message-ID: Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2018-10-14 To: gentoo-project Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 5d05532f-2885-4770-9aac-ff6a9c951037 X-Archives-Hash: 9b3b723aa81fb212c7bf0e75efdffe05 On Thu, Oct 11, 2018 at 1:49 PM Ulrich Mueller wrote: > > >>>>> On Thu, 11 Oct 2018, Brian Dolbec wrote: > > > My employer sponsors a lot of Gentoo ebuild and project work. We are > > currently waiting for approval from the legal department to be able to > > continue after the Glep 76 approval and subsequent enforcement. It > > very well may include a requirement to include a company copyright > > notice for the work done on comapny time and equipment. > > > I have prepared a patch to repoman which fully implements Glep 76. [1] > > It adds a COPYRIGHT_OWNER variable to make.conf which can be set. > > The COPYRIGHT_OWNER is only ever ensured (possibly added) to the > > existing copyright line if the --copyright option is given on the cli. > > It is also used to generate a new copyright line if one did not exist. > > As I've already commented in the pull request [1], I think this isn't > something that should be automated in a QA tool like repoman. > > IMHO, repoman should accept both forms of the copyright notice, as long > as they're syntactically well-formed. Otherwise, it should leave the > copyright holder alone (with the possible exception of updating Gentoo > Foundation to Gentoo Authors). > > > This option should only ever be used for significant changes to an > > ebuild. > > Right, but I think there is the danger that the feature will be abused, > e.g. that people will use it also for non-copyrightable changes. > Also, unless we want some kind of endlessly-concatenating copyright notice, I don't think we want repoman just changing the line. Suppose I change an existing ebuild, and for the sake of argument let's assume that my changes are sufficient to be "copyrightable." Existing ebuild says "Copyright Gentoo Authors" / etc. I want it to say "Copyright Rich Freeman and Others" / etc. Whether adding an extra 10% to an ebuild really warrants that change is debatable, but let's let that slide. Now suppose ulm comes along with similar demands, does he just wipe out my name and substitute his own? Or does this turn into the BSD advertising clause where we start accumulating names? The GLEP has been through many iterations, but the intent was always to avoid turning the copyright notice into some kind of authors list because it fails pretty badly at that. It gets unwieldy very quickly, and if everybody wants to stamp their names all over everything presumably they're going to cry foul if somebody else wants to stamp their name over top. We already ran into a bit of a PR issue when somebody overwrote the udev authors with the Gentoo Foundation when forking eudev. There was no ill intent - they were just trying to comply with a policy. But, suppose I make a 20% change to a file - am I going to upset some outsider whose code I borrowed by "stripping" their copyright notices. I believe when I looked up the laws regarding this it is actually only a crime to do so when it is used to conceal infringement, which isn't happening if we're sticking to the FOSS license, but people get really sensitive about these things. The intent around being flexible with copyright notices is so that we can do things like forking eudev, because the policy basically will accept the previous copyright notices if they are sane. However, the intent isn't for people to be having wars over whether they're getting "credit." You already have credit in git. Outsiders should also be getting credit in git (you can ack them in the commit, just as the kernel does). And major contributors have sometimes been known to ask the Foudation to write a note to affirm their contributions for job applications and such. There are better ways to give people credit than copyright notices, which also serve a legal purpose (which is far simpler). So, having repoman stamp names all over things seems like a bad idea, because we have to deal with what happens when multiple people start stamping over each other's stuff. If a company cares THAT much about having their name in the notice, then will they care when their competitor who also has the same policy stamps their name over top? How can repoman handle that sanely short of concatenating, presumably avoiding duplication in a text field with poor structure/etc... -- Rich