From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pine.sfconservancy.org (pine.sfconservancy.org [IPv6:2001:4801:7822:103:be76:4eff:fe10:7c55]) by sourceware.org (Postfix) with ESMTPS id 175C83858013 for ; Sun, 4 Jul 2021 23:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 175C83858013 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sfconservancy.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sfconservancy.org Received: from localhost (unknown [216.161.86.18]) (Authenticated sender: bkuhn) by pine.sfconservancy.org (Postfix) with ESMTPSA id D07B3E472; Sun, 4 Jul 2021 23:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sfconservancy.org; s=pine; t=1625441161; bh=ZdjzWSFMC8XOYmTDQ0BdWg/V3hByMKuW3bw8o5JooQ0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RYjxWFTyxIhA/cOJLuPheBDpeUtU06B2wykpUlO0rRSgpzqQAmxwPA+YHCj0/IG19 haZzo56Sd1fz5X0EUIvJp0Gb/P+TTEI5/vnU4l4Ib/aF6Bd+LuWQCbCZmLnJ45Bc+0 LGQw9ZAalvolF37gmiupqMaFL1Yj5DZJdPk7X82UDNU6XRnGqmhdeVWqIrsPFe5WYf z1mlXz79+wX4XasDIjdSEonZTDurAoR1cU2GW8vrmHPN1Lm1tw6lw8rLZ29lA3cU+l iF7Qs6u3s8Lk2SaBb/nwNDdF3mzuEZu4WttPV51mS6XZAJ7aJ6SSmQi7mLNruu9ffT 8UXOoxsMzH9mg== Date: Sun, 4 Jul 2021 16:25:16 -0700 From: "Bradley M. Kuhn" To: libc-alpha@sourceware.org Subject: Re: Seeking input from developers: glibc copyright assignment policy. Message-ID: References: <1b2ac4c8-0bbf-b7a7-8b05-03d5a71d46f4@cs.ucla.edu> <87eeceqomw.fsf@oldenburg.str.redhat.com> <7ce2b2b9-eb78-399d-abb2-de7690b3da5b@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7ce2b2b9-eb78-399d-abb2-de7690b3da5b@cs.ucla.edu> X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 23:26:06 -0000 > On 7/4/21 4:55 AM, Florian Weimer wrote: > > I would prefer something along the lines “Copyright The glibc > > Contributors”. IANAL, but my own experience and work with GPL enforcement and lots of copyright issues, and information I've received from copyright attorneys over the years have convinced me it's a big mistake to create a copyright notice that lists as the legal entity as something that has no legal standing. So, unless you plan to form an organization called “the glibc Contributors”, I advise against that notice. What I recommend, though, if glibc is definitely going to a multi-copyright held work, that you move copyright inventory to a single top-level file instead of keeping it file-by-file. In my years of examining FOSS code, I regularly find that developers, particularly when working under the DCO, do a terrible job at keeping file-by-file copyright inventory up-to-date. The Linux project has disturbingly taken to *removing* all such file-by-file copyright notices from the source tree entirely, which is an over-correction and just as bad a mistake in the other direction. I just think file-by-file copyright notice inventory has become so inaccurate in multi-copyright-held works that it essential becomes a fiction: the copyright notice ends up being just the first few people who worked on the file in question, and later contributors simply forget to include an update of the copyright notices in the files. As others have pointed out, copyright notices aren't mandatory under copyright law to get move of the benefits. Paul Eggert is quite correct that there are some *minor* legal benefits in some countries to keep copyright notices in place. (Some folks do argue that those benefits are so strong that it's imperative to keep copyright notices accurate on a file-by-file basis; but I disagree with that position). The fact is, storing copyrighted materials in separate files on a computer is purely a technical convenience, as copyright law doesn't generally think in terms of “what file it was in” but rather “what is the work in question”. (Licenses like the MPL do have certain requirements that are file-based, but the LGPL and GPL doesn't have these kinds of requirements.) Thus, my usual recommendations to projects is to change the file-level notices to something like: /* License: LGPLv2-or-later ; copyright and license notices kept in file ** COPYRIGHT at the top level of this source tree, and available at ** if you receive this file separated from the entire source tree */ and then move all the file-by-file notices, with the long text from the LGPL about the license details, plus the copyright notices, together into that *one* file called COPYRIGHT at the top-level, and encourage contributors to update that file if they want a copyright notice added. Again, IANAL and TINLA. I recommend that the Glibc developers talk to multiple copyright attorneys about these issues before making a change, and copyright attorneys do disagree about some of these things in my experience. The issues you're going to face moving to a fully multi-copyright-held work are going to be many; I urge you to sort all this out before dropping copyright assignment. * * * Finally, since I'm posting my first email here after the feedback deadline, I'd like to inquire about what the leaders of the glibc project thought about all the feedback received and if the plans have been made any more detailed based on the feedback received — particularly with regard to what, if anything, the project is going to do to figure out who the real copyright holders are of various contributors once opt-outs of assignment begin. -- Bradley M. Kuhn - he/him Policy Fellow & Hacker-in-Residence at Software Freedom Conservancy ======================================================================== Become a Conservancy Supporter today: https://sfconservancy.org/supporter