From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 77738198005 for ; Mon, 25 Feb 2013 22:45:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E2476E08BD; Mon, 25 Feb 2013 22:45:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D95F2E07CA for ; Mon, 25 Feb 2013 22:29:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id D609E33DC21 for ; Mon, 25 Feb 2013 22:29:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.176 X-Spam-Level: X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5.5 tests=[AWL=-0.476, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrL09R7QE1Xe for ; Mon, 25 Feb 2013 22:29:09 +0000 (UTC) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 883C733DC3A for ; Mon, 25 Feb 2013 22:29:09 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so2930459iaf.14 for ; Mon, 25 Feb 2013 14:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:cc:content-type; bh=J07X2a9wYyHFgQ2PcrkpfILtG4Co9X/hTVLT6G+OFHw=; b=KgCVrPu3w8OXylTWrnubyAAnMZTuPCxDWiii6OPFEpreJbbls8iG6xOr7IaXCoKmiF 00ZUjoP1dFCmvcdBILmoh9lD8GvhT8T8urwMTU5tFEltf4EKstEVSGj15MA8eHOFjAqi FppxulzC74WVnD12LZpH4JCKImcb1w51yrPxM4R65VQPozsM4pHJocEJawP+8UUiw9+y o1zTbogKQLv4d5cAoFqskfszZc8eQ14EIb2b5C9ZdQxNE5Ii3eVqQCkhE+g9dvaAKX5I nhw+4/Ynnx4c81aDSe+XixL4N/WE8Ckvz/qBB7LN22nj71+4J6BvS4JR+sIfO9v9O+Yu 8+hQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo development announcement list X-BeenThere: gentoo-dev-announce@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.51.167 with SMTP id l7mr4263337igo.11.1361831348783; Mon, 25 Feb 2013 14:29:08 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.21.98 with HTTP; Mon, 25 Feb 2013 14:29:08 -0800 (PST) Date: Mon, 25 Feb 2013 17:29:08 -0500 X-Google-Sender-Auth: W2yseT-uXbsQW7bHNj0RZEUEmLI Message-ID: Subject: [gentoo-dev-announce] Forming Gentoo Policy - Copyright Assignment and Attribution From: Rich Freeman To: gentoo-nfp Cc: gentoo-dev-announce@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 47d4d57a-2f40-47b5-be41-b29fbe37c3d3 X-Archives-Hash: e305f5187c42db9ec813fc0a24dedc58 I'm CCing this to gentoo-dev-announce since this has been a something high-profile topic, but all replies should stay on gentoo-nfp. In a previous thread there was discussion around the pros/cons of requiring copyright assignment to the Foundation. In general this was not well-supported, and we're increasingly finding ourselves in a position where we want to accept contributions from those who are unable/unwilling to assign copyrights, or where a work started outside of Gentoo but we wish to incorporate it. At recent Trustee meetings the consensus has been that we will not move in this direction. In order to avoid completely undirected bikeshedding we're tossing out a strawman for how we might move forward. This isn't policy - just a proposal for policy, and decisiveness shouldn't be confused for any unwillingness to discuss alternatives. With Regard to Copyright Assignment We'd like to propose that we create an agreement similar to the FSFe FLA and what is used by KDE to allow for VOLUNTARY assignment of copyright to the Gentoo Foundation. The more we can do this the simpler everything else below gets, and the more power the Foundation has to go after offenders. However, it will not be required that this be signed off on in order for anything to make its way into a Gentoo project (the tree, docs, associated software, etc). We'd come up with some mechanism for doing this electronically (details TBD) - nobody would be mailing around paper. It could be done retroactively as well. A list of those who have signed would be published, which may be helpful with teams that need to work out who owns what when attributing copyright (see below). With Regard to Licensing Per our social contract: We will release our contributions to Gentoo as free software, metadata or documentation, under the GNU General Public License version 2 (or later, at our discretion) or the Creative Commons - Attribution / Share Alike version 2 (or later, at our discretion). If we're not going to own copyright then the whole "at our discretion" bit doesn't really apply cleanly. We'd like to have a table (likely in xml and published on the website like various other similar tables) that lists Gentoo projects and their licensing requirements. Our policy should be to require those to be either GPL v2+ or CC BY-SA v2+, except as approved by the Trustees (generally this would be used to make exceptions for v2-only, or if somebody wants to request that a project be BSD). The intent with the 2+ bit isn't to exclude contributions so much as to at least not make v2-only a default, as it would be best for us to retain some flexibility to upgrade. With a list of required licenses there will be a requirement that anybody committing to Gentoo acknowledge that the work they commit is certified by them to be usable under the documented license. This declaration would accompany each commit. This will NOT be an assignment - just a declaration that the committer has done their homework. Implementation details TBD. Linux does it with the signed-off-by commit comments (specifically Developer Certificate of Origin, DCO [1]), and this could be used regardless of VCS, it just gets much easier with Git. Again, details are TBD and likely need to go by counsel. Note that a DCO would likely require the use of a real name when signing. With Regard to Copyright Attribution This is where all of this can get really messy. The existing policies around ebuilds/etc all starting out with the copyright Gentoo Foundation would be replaced. We've yet to find much in the way of published policy for other FOSS projects around how much of a work needs to be covered by these attributions. We did find GNU mailing list traffic to suggest that they set the mark at 50%. It seems that our options are to either always list anybody who contributed so much as a character, or have some kind of threshold. Our initial suggestion is to start with the largest contributor and cover AT LEAST 60% of the lines inside a file. No policy will prevent anybody from listing as many significant contributors as can be found, but to be compliant we'd require attribution for 60% of the lines. We propose that the copyright notice at the top of the file read: "Copyright and others (see below)." Then somewhere within the file there would be a list, or a reference to a closely-associated file containing a list, of contributors for no less than 60% of the lines of code in the file (again, this is a minimum only to allow us some wiggle room - best practice will be to list as many as can be found). The one-line notice must appear near the top, and the rest can appear anywhere - if just a reference to an external file the recommendation would be to put that near the top as well. The Changelog could be used for this purpose as long as it acknowledges the actual copyright holder of the code (acknowledging contributions is recommended in any case). Our ability to police this is going to be near-zero - we'll really be depending on devs to get it right, and we would of course respond to complaints. Git will make this easier, but since committer != owner that isn't perfect either. Repoman at best could look for the notice, but not ensure that the name is correct. We propose for grandfathering purposes that modifications may be made to existing files without any need to retroactively bring them into full compliance. New copyright owners should be added to the list, but for the purpose of this policy existing code is considered to count towards the 60% rule. This also applies to bumps/etc. As code is updated/replaced the goal is to slowly phase in the new policy and improve our overall legal clarity without burdening maintainers with having to go through a large exercise just to do a bump or change a few lines of code. There are a bunch of details TBD of course. Definitions around what constitutes a line and such should favor simplicity. So, please comment away. This isn't a detailed policy, but rather another step towards forming such a policy. We expect based on comments that the next thread on this topic will actually contain a detailed policy with review by counsel. To cut down on churn here your comments on overall direction will be important. Rich (For the Trustees) 1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches#l298