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 858E3138334 for ; Mon, 11 Jun 2018 17:07:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E6742E0896; Mon, 11 Jun 2018 17:07:32 +0000 (UTC) Received: from mail-pl0-f52.google.com (mail-pl0-f52.google.com [209.85.160.52]) (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 9C910E0872 for ; Mon, 11 Jun 2018 17:07:32 +0000 (UTC) Received: by mail-pl0-f52.google.com with SMTP id 31-v6so12682140plc.4 for ; Mon, 11 Jun 2018 10:07: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=ummE6080rFs/GEtkaaOltXI5K/17LPmboahjWwlNZrI=; b=rFuP5WQ4D2WpmBa/+0NK00/mLfOxgPCJK7oOZVee53YMEVz4PlkJMKTFY3eDBmQnzm x1PKKkNA8x7uBcuoPez5tD0bkZ8oVV6uX+TjZFfv/KTwim5ZK5JsJFr3WDl82bwnKZrG f9KB0JqShKlSa3IDXXWpEJKuC6ZIYXrat1h7KQ+dtaiLDXAvkKPSzV43zm32gUgxRL23 Y4OgDLxRjCS46BHnE3sYMrfCp3u/bhL061ab+1b0vbu4p9zNneqI228Aietr/flGTwz5 DADpWCxQ3smWEeNFVZFEbb1WF1PRhUiIvcJkmeY20ImPM0ese5qghlK4GPG2F94oM7WJ 3CVw== X-Gm-Message-State: APt69E3Gu4eJKwnhHa0m1GFpxREZXXP+lfEUIpW70MQhS70MOcyxX3sl tgsMwbeIhScofeLNmvqwdGX3Lih0r6/9sPAy61Vhhg== X-Google-Smtp-Source: ADUXVKK8YwqAzLwfjCEs+aU40WPhz/OQQpeRxhPgLynuW+YNv3eqKKCXZy61IlXOe/Bwn/lb0qlMHxGODbtqvG+BR8k= X-Received: by 2002:a17:902:bb8d:: with SMTP id m13-v6mr57602pls.46.1528736850998; Mon, 11 Jun 2018 10:07: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: <23325.35685.793702.267278@a1i15.kph.uni-mainz.de> In-Reply-To: From: Rich Freeman Date: Mon, 11 Jun 2018 13:07:19 -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: 9005d64e-1acf-495b-bfe9-d09979a7221d X-Archives-Hash: c55b89e12038c155798a442ca0f7d60c On Mon, Jun 11, 2018 at 12:25 PM NP-Hardass wrote: > > On 06/10/2018 04:34 PM, Ulrich Mueller wrote: > > > Copyright Attribution > > --------------------- > > > > All files included in Gentoo projects must contain an appropriate > > copyright notice, as defined by this policy. > > > > A proper copyright notice appears near the top of the file, and reads:: > > > > Copyright YEARS LARGEST-CONTRIBUTOR [OTHER-CONTRIBUTORS] and others > > > > The largest contributor is whatever entity owns copyright to some > > portion of the largest number of lines in the file. Additional > > contributors can be listed, but this is neither required nor > > recommended. The "and others" text may be omitted if the explicitly > > listed contributors hold copyright to the entire file. > > Why is this not recommended? So, I came up with this to try to keep it as simple as possible. My concern was basically analogous to the BSD advertising clause problem. If you start accumulating authors on this line then it gets unwieldy. How do you draw the line? I suggested drawing the line at whoever touched the most lines, mainly because it is simple. IMO ANY solution is going to be imperfect, so simple trumps all. But, it certainly isn't the only possible solution to this problem. Keep in mind that notice is not the same as authorship/copyright/credit/etc. The "and others" is important. Being #2 doesn't in any way diminish your rights under the law. The law simply requires a notice, so we need to come up with one. It shouldn't be viewed as "this is the only important contributor to this file." If we could not have any notice at all legally then that would be simpler still. Git already tracks who did what, and should always be the place to go for this info. > If developer A writes 51% of the lines of an ebuild and developer B > writes 49%, should B not be listed? Under the policy, no. > What if all the metadata lines defining variables consists of 75% of the > file and was written by A, but the core functionality of the ebuild (25% > by size) was written by B? Under the policy, "A and others" is listed. > If A writes an ebuild, and B replaces a majority (>50%) of the ebuild, > should B remove A from attribution? Under the policy, yes, assuming this is noticed. The policy does not require checking on every commit, but only when the issue is escalated. That is actually a change from the wording which tried to keep things more strict. > I think that specifying that substantial (though not necessarily > specific in defining this) contributions/contributors should included in > the copyright attribution and that substantial contribution attribution > *is* recommended. So, the issue then becomes whether we have to define "substantial." The goal is to have something actionable. Anybody can run git blame easily enough. Figuring out what is "substantial" is harder. But, the other change to the policy was to relax this and not worry about keeping it as up to date. So, in that spirit maybe we can be more vague and let it be dealt with via escalation. That seems to be the approach the Linux Foundation takes. As far as I can tell they have no policy regarding copyright notice - and the contents of their files are all over the place. Presumably committers make their own judgement calls, and if somebody has a problem with it they point it out to the Linux Foundation. That said, the fact that this is basically happened with the eudev copyright notices didn't prevent it from turning into a bit of a tempest in a teapot with all kinds of accusations being tossed around. It was dealt with upon escalation, but people tend to go crazy over this stuff so some kind of policy that an ordinary dev can understand wouldn't hurt, so that the issue is prevented. That was the goal of the policy. A big goal here was to keep it simple and understandable but not too vague. It shouldn't need constant appeals to Trustees/Council/whoever to apply to individual situations. To the extent that the notice doesn't truly give credit to contributors I'd call it a feature and not a bug. I'd rather have the notices viewed as useless for that purpose, because then people won't constantly squabble about how does/doesn't get included on them. The ideal choices would be listing everybody or nobody, but everybody is cumbersome, and nobody doesn't seem to be legally valid. So, listing one by name preserves the nonsensical nature of the notice while still meeting the legal requirement. Or something like that... -- Rich