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 EE942138334 for ; Sun, 17 Jun 2018 01:40:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F4D2E086D; Sun, 17 Jun 2018 01:40:02 +0000 (UTC) Received: from mail-pg0-f44.google.com (mail-pg0-f44.google.com [74.125.83.44]) (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 18560E0848 for ; Sun, 17 Jun 2018 01:40:01 +0000 (UTC) Received: by mail-pg0-f44.google.com with SMTP id z1-v6so5985767pgv.12 for ; Sat, 16 Jun 2018 18:40:01 -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=84XEUpulfxzOl406kIH5wn0G7HZIV+l+oXMo6Pxy5OE=; b=uQDAQ46XIe50LS/EhlYuZEAh5rM7n6DGLToopJ0YikcYO13o8J+EFG37RrP5g+/PMj OUcwMcKGEcX924Kyw16h8HFA4sVMOgFXhD0kMNwRVIc3a2ZqLzGxBfuqjMVOBD1WPcfb rEOizyPHaba5gk/W8Ya3rWSHuzSMwFesDGD3S3NTRFPtVNrNvmWrTJ95JjS//rCo2/6j NzZsYckXqPDirN6efMlrwJ2USNSL8/4JB7/aUBGZbk+VpCYzPm0kGaky3BkYPH52LYLk wvD910ugbeh9eMEb2K2iqn/EqUEAoLaLmGzWSUXbf473s7AjfPGxSJFlsWe7BhGZTTKb 6BkA== X-Gm-Message-State: APt69E0353uT/dOh3HFEe2EG2BWY0lh2QSczGR/lak8sYnhnSqtQIS1C i95aCIV0Vb1scoDgRVvdwmxbCXrLKWALX/M2APu49Lgg X-Google-Smtp-Source: ADUXVKIgs/sCr/s9vrp31bPrQeGbOOXXAO6iXOVnUde6/1HmYn+s/NaI+FqpZAbenIJDd7eiNfC/h43p6oyzGzNpnO4= X-Received: by 2002:a63:61d6:: with SMTP id v205-v6mr6580901pgb.432.1529199600516; Sat, 16 Jun 2018 18:40:00 -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: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> <20180617123737.122ef070@katipo2.lan> In-Reply-To: <20180617123737.122ef070@katipo2.lan> From: Rich Freeman Date: Sat, 16 Jun 2018 21:39:49 -0400 Message-ID: Subject: Re: [gentoo-project] [RFC] GLEP 76: Copyright Policy To: gentoo-project Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 8200f08c-8a04-447a-8c06-1bc8cd4e512f X-Archives-Hash: 3d095741f622aa0b2271a466b2e5f055 On Sat, Jun 16, 2018 at 9:03 PM Kent Fredric wrote: > > This idea to me is just asking for trouble, given the aformentioned > factors. > What kind of, "trouble?" > Reliably handling contribution factors however seems difficult, given > the stock output given by "git blame" is routinely wrong due to how or > workflow operates. Why does this have to be reliable? > So given that, as it stands, automating this is either: > > a) hard > b) impossible > > And subsequently, manually doing it will tend towards those entries > quickly becoming wrong. How is that a problem? Also, this assumes that the main copyright holder on something we distribute actually changes often. 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. > And to add insult to injury, changing these entries via either > mechanism produces source of commit churn and conflicts Only if you try to constantly adjust things. If you just wait until somebody points out an inaccuracy (which is all the policy requires), then these commits will be rare. > And around about here you ask "what's the point?". A lot of work, for > negligible benefit. The policy doesn't require much work. The parts that suggested that it needed to be maintained in realtime were removed, for exactly the reasons you have elaborated on. The intent here is not to have devs constantly checking the copyright notices on every commit. It simply states what they are intended to contain. > > The nature of the proposed changes seems strongly in conflict with the > technology we have to use, and will produce no benefit, at the expense > of real problems. > Well, one of the main benefits is that people won't feel like they have to replace all the copyright notices with ones that reference Gentoo when they put these files on Gentoo infra (such as what happened with eudev). As far as real problems go, just don't touch the copyright lines except to add "and others" and there won't be many issues. If somebody makes a huge rewrite they can always add themselves to the notice as the main contributor if they wish. I definitely don't think automating the notices is a good idea. For example, in the eudev repository the file src/scsi_id/scsi_id.c has IBM/SUSE copyright notices on it, and that isn't what your git log command would output. That was just the first random file in that repository I checked. Overall the intent of the policy (after the various rewrites) was to try to give reasonable instructions as to how the notice should be written, but not to suggest that developers need to put a great deal of effort into making it precise. -- Rich