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 71F8A138334 for ; Sat, 24 Nov 2018 21:22:03 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 440D2E0AAF; Sat, 24 Nov 2018 21:22:02 +0000 (UTC) Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) (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 E3869E0AAB for ; Sat, 24 Nov 2018 21:22:01 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id 101so5766616pld.6 for ; Sat, 24 Nov 2018 13:22:01 -0800 (PST) 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:content-transfer-encoding; bh=biQzl6fQ1MZ4vSkvNa/4dn+v4KTfVGqMGyhRniK9F5g=; b=JIFP22CyGnhvsvmZeA4nCLCcFhgG2yCUXdIZB1h9etCMFhRDkLQPVgaTrotb1VrwCM rtlARkJW7sbu+YXy/0/cBe2ExgNfdK6C9SqQWaYsUYCGZzc/nzJg2wy5XC8drhhX2few nHbvkK7JuQL6z2mHx6UezLUkiCGqwYCGzKexKr+XcCtTT7/nQkAFZrvSwgh3Kn4PRnB+ /M0tmFje/2r9VikktUHmD7Ghy5aEy/YEFm6ZCpYC/aiWMfzzexq0umKXq85pBHVCZLBM gsU2qs4jyyuaOWJ/StiNYQ2oxGx30ICnElWePhmoNzRw5MY6KfcEBacaI1/uuFXkeLJR vB/w== X-Gm-Message-State: AA+aEWZcyFbfzU/66/EtxOuvWpm1kqE+DW2WcMAyrL43kr0S1WEw2mmk q8GGM0mw19ZGoQvIZP7fRZGYyNZbZz69xtOR+aUOdtEC X-Google-Smtp-Source: AFSGD/UvHt5nDjieUYFMab09qCpvS5eg9fheTjDg2xgcX1cWCax7YeZUOEGb5wyblszXMsFq7WLBl3kb7YdAN99W2lQ= X-Received: by 2002:a17:902:ab84:: with SMTP id f4mr20805509plr.207.1543094520404; Sat, 24 Nov 2018 13:22:00 -0800 (PST) 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: <20181114024643.GA15537@linux1.home> <20181114174522.cab71989801dc2c155735326@gentoo.org> <20181114185302.875806d543d7da9d9162fc42@gentoo.org> <0ab206f1-4416-b35c-0f1b-85d5dd24c7c0@poindexter.ovh> <0082a107-c458-d9bd-0f38-9b3085f0a9d3@poindexter.ovh> <79c57d08-8b0b-ed86-33dd-30462ca1d72d@poindexter.ovh> <20181124174747.GA19308@linux1.home> In-Reply-To: From: Rich Freeman Date: Sat, 24 Nov 2018 16:21:48 -0500 Message-ID: Subject: Re: [gentoo-project] rfc: copyright attribution clarifications To: gentoo-project Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: a44ee8b8-327e-4e0a-b6a2-33b9361f3c4a X-Archives-Hash: baf19fcf8f1f63883748fecce0872fa6 On Sat, Nov 24, 2018 at 3:32 PM Alec Warner wrote: > > On Sat, Nov 24, 2018 at 3:12 PM Rich Freeman wrote: >> >> 1. They add clutter to ebuilds. At the very least they should be put >> at the bottom of ebuilds and not at the top, and anybody editing an >> ebuild should be free to move a multiline notice to the bottom if they >> see it at the top. > > So now you don't if the notices exist, as long as they are at the bottom = of the file? It seems inconsistent with the rest of your position ;) "At the very least" doesn't mean that I don't care. It means that if we can't live without this at least get them out of the way. All-or-nothing is not the only way to have a reasonable discussion. And as I go on, there are other reasons that have nothing to do with clutte= r. >> >> 2. It strikes me as being fairly anti-community. Basically the >> companies that give us the most trouble get to stick their names all >> over ebuilds, while freely benefitting from hundreds of other ebuilds >> that others have contributed without any care for sticking their names >> on stuff. Sony should be contributing because they want to >> contribute, not to stick their names on things. Or if they want to >> sponsor us they should do so under the normal terms for doing so, >> which generally involve more than contributing a couple of lines of >> ebuild boilerplate. > > > So this argument is basically; we don't understand why Sony wants to put = their name on the notice. In lieu of any facts, we will tell our own narrat= ive; anyone that causes trouble is a baddie; Sony is causing trouble, there= fore, Sony is 'anti-community', or 'name-grabbing' or whatever. I didn't say that "Sony is anti-community" here (I do imply it more later on). I said that this policy is. An organization can have a policy that says that donations conditional on public acknowledgement are not accepted, and that is not making a statement about the donors themselves. It is just a policy. >> >> 3. It opens up a slippery slope. Once you say one person can stick >> their names on something, how long until everybody and their uncle >> starts doing it and an ebuild with a long history like glibc has three >> pages of contributor names at the top (and IMO glibc is one of those >> few ebuilds that actually seems non-trival)? > > I think you can easily look at other projects that let anyone stick their= name on anything to see what happens...I'm not sure this is a strong argum= ent against. These other projects seem fine and are not overflowing with co= pyright notices. Sure, but most projects have files containing thousands of lines of code. Sticking a few more lines in a header isn't as impactful there, as I elaborated on in an earlier email. A typical C file opens up with a stack of #include and #ifdef statements, which isn't terribly important. They're just more verbose by their nature, and if you're looking at a C source file you're probably looking in the middle of it. A typical ebuild opens up with stuff like EAPI, KEYWORDS, IUSE, SRC_URI, HOMEPAGE, which are some of the most important metadata in the file. Having this be easily readable is far more useful than a page of preprocessor directives, IMO. Most people looking at ebuilds are pretty likely to be interested in the stuff at the very top more than just about anything else. >> >> 4. The people digging in to try to force this policy have no interest >> in participating in the Gentoo community, or actually advocating for >> their position. It seems that they simply consider their position >> undebatable and expect us to just accept it because heaven forbid one >> developer not be allowed to contribute during business hours, despite >> many others having no issues with this at all since their employers >> are more reasonable. > > I assert that you don't know anything about their reasons, their rational= e, their reasonableness or anything really. "People who have conflicts are = unreasonable" is really what I hear from this kind of speech and its not re= ally a great message to send. I said they aren't interested in participating in the Gentoo community. The fact that the lawyer who came up with this policy in the first place isn't on the list tends to speak to that. Granted, they could be merely unaware that their request has made a stir. I don't really have a problem with sending messages that companies that want to set blanket policies without dialogue aren't very welcome around here. Having them refuse to participate would create less churn. >> IMO Gentoo (and the members of its community) should be using this as >> an opportunity to tarnish Sony's reputation, not bend over backwards >> to cater to a random request of a company lawyer who seemingly isn't >> interested in actually discussing their policy. This isn't Sony >> contributing to open source, this is Sony interfering with what has >> basically been routine practice in the community for 15-20 years. > > I think it is an entirely reasonable position to do the following: > - Not accept the SEI notices because we do not understand the grounds on= which they are added. > - Ask SEI for a rationale for what the notices are meant to convey, so w= e can decide if we can support whatever that use case is; maybe its somethi= ng we didn't consider in the GLEP. That is reasonable. Certainly it makes sense to consider rationales if they're willing to supply them, though they should also be willing to engage in dialogue with those who disagree in the hope of reaching a compromise if necessary. > I don't think its reasonable to say they are mean shitheads; Then don't. That doesn't prevent others from doing so. If their goal is to get positive PR by having their name in their contributions then they should consider how they go about it, and so should their representatives. --=20 Rich