From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Sat, 12 Dec 2020 18:07:28 +0100 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Reply-To: thibaut.verron@gmail.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39479"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Boruch Baum , Stefan Kangas , Richard Stallman , Jean Louis , Emacs developers To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 12 20:30:02 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1koAag-000AAt-Mg for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 20:30:02 +0100 Original-Received: from localhost ([::1]:36686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koAaf-0004wB-Cr for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 14:30:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ko9jd-0004vA-HP for emacs-devel@gnu.org; Sat, 12 Dec 2020 13:35:13 -0500 Original-Received: from mail-ot1-x335.google.com ([2607:f8b0:4864:20::335]:40881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ko9jX-0007pL-4F; Sat, 12 Dec 2020 13:35:13 -0500 Original-Received: by mail-ot1-x335.google.com with SMTP id j12so11542270ota.7; Sat, 12 Dec 2020 10:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=V62BCthq/xSYaPxSP7aYmsrK2BPw+fUruGY+zXiH6R8=; b=TO6HuHV4HswnARoLjs0W7yugstXp8v5Y0zRv35lyjftJ3q8r/FMcwgZvqCgoqVJZOd LKalThcmePwcSrd9vvK7/dS/E67rYfdpSVCkxjGmnSGc+85X1Jv8/E8cutxdpnJusQXX 6wjllqsVZeAXbkOhgL7/dppogRn13qcelHhaEAYQKYvndUFzFB4ijy6hn7gnzzlWK+aa a+V6n6QhLQkG0eL7c+M9ouhLJuc1e4KRj7bXKPJWpvefF1UvctRgAxUVrUlmpp1sMNfJ Cys7MQEiIA6k+/jN/UGDlpmjKCD+u6qLVuSabMVciZXvdBsrqerjIHdUG+9gw3mRAs5C vtVQ== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=V62BCthq/xSYaPxSP7aYmsrK2BPw+fUruGY+zXiH6R8=; b=VamYV1jnFWUHwHBVRQgdI4T5Wt1JPCYYawIS7J2VPPhixvyDWAdEtx7mipRqN2STiv zXkflC+7SGnj6yrvPnNsQz7k8dqD/7x0qCKCUtreczm80fIrSXawFAWoyRTmYleoQqYK /SfX76r3/T/BEMyd0cb5SpCOx0YY1802j/djqrGgJlmt/AjOWLrCYW/f3xENukpTuydQ RwhiVTi/fvdZjwPViJMkwpOCT9W8X8X5uSfwbpABF8/IVRsFVSz4eLQyFQ/shMS8y1fq RjNjT5z+Gex7HGzZsGSohclRaUFCPaAIvUFX2pmUfWS1c5SHB8Cu7hophf638rN+OH4l AZ1w== X-Gm-Message-State: AOAM533dp6VbfODuEJzku8Bovr3jK+Jh6opgVk9e5yAAxf+euZLzMcOr Uj80W0ABf8WGw2vO559DaysIs9USBBfFNDHiUjuBKnnS/SpJDfn2 X-Google-Smtp-Source: ABdhPJx8mqS+E3LIuDG/g7dKsMu4N/A20+CBjSM4FPRMQPyrxAIniXi6+aVzA/rqUJJ78lUqsWc2zLY0oMTvoKHMsNI= X-Received: by 2002:a25:31c5:: with SMTP id x188mr25242526ybx.450.1607792859446; Sat, 12 Dec 2020 09:07:39 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::335; envelope-from=thibaut.verron@gmail.com; helo=mail-ot1-x335.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260720 Archived-At: Le sam. 12 d=C3=A9c. 2020 =C3=A0 16:23, Tim Cross a= =C3=A9crit : > > > > On Sat, 12 Dec 2020 at 21:08, Thibaut Verron w= rote: >> >> Le sam. 12 d=C3=A9c. 2020 =C3=A0 07:37, Tim Cross a =C3=A9crit : >> > >> >> >> I also recall a discussion where some developers were worried that >> assigning a copyright to the FSF was an official statement of >> philosophical support, and that it was a statement they were not >> willing to make. The official answer was that there is no such >> statement in the copyright. > > > As non-GNU ELPA is primarily about having a repository of packages which = fit with the FSF philosophy and which do not require copyright assignment, = concerns relating to copyright assignment are not relevant. My point was that if assigning the copyright is not a statement of philosophical support for the FSF, clearly, choosing the default license (and possibly the only legal one) for an elisp file is also not. >> >> > I think a mandatory requirement should simply be that any packages whi= ch go into non-GNU ELPA are hosted on an approved platform. We could point = to a list of such hosting providers e.g. https://www.gnu.org/software/repo-= criteria-evaluation.html and say Grade C or better only. . >> >> There is no such requirement for GNU ELPA at the moment. > > Perhaps there should be. However, GNU ELPA consists of code which has had= copyright assigned to the FSF, so I guess that is their call. I might be mistaken, but as I understand it, the copyright assignment does not give the FSF authority to move the repositories (including issues, pull requests, etc), only to create a new one mirroring the code. It is always possible to remove those packages which are hosted on Github, of course, but I don't know how many maintainers would be willing to jump through hoops *again* to get their package readmitted. >> > This will also have the added incentive of encouraging better hosting = options. It might even encourage GitLab for example, to enhance their envir= onment to meet Class B. >> >> Couldn't it just as well be an occasion to encourage Github to improve? >> > I strongly doubt it. Github has become a significant platform for Microso= ft and I see little interest from them in supporting the philosophy and goa= ls of the FSF. Right, because they are evil and it's in their nature. But seriously, I see interest in retaining their audience. Gitlab is already gaining traction in several communities (e.g., from first-hand experience, public research), and Microsoft knows that Github is only popular for companies for as long as it is popular for developers. Asking Microsoft to completely give up control on Github is not realistic of course. But small changes such as moving to a free Captcha system, or giving repositories the option to allow anonymous comments, why not? >> > Many people have selected Github for hosting simply because it was the= best known solution. With a little encouragement, they would probably be w= illing to move to at least GitLab, which offers many of the similar conveni= ence features of Github. Being able to host your package in non-GNU ELPA m= ight be that encouragement. >> >> There is a lot of inertia involved in relocating a package with >> hundreds of contributors. > > > Hence adding a requirement to be hosted on a platform which furthers FSF = goals to help combat that inertia. People will have the choice - if they wa= nt their package to go into non-GNU ELPA, move it to a more compliant hosti= ng environment or leave it where it is and don't worry about getting your p= ackage into non-GNU ELPA. In my opinion, they won't worry, just like they didn't worry about getting their package into GNU ELPA before. Melpa works fine. As I remember it, the discussion started with "why do people use Melpa when there is GNU ELPA", and the more or less accepted answer was that there is too much red tape for packages to be included in GNU ELPA. Hence the NonGNU ELPA project, cutting down the requirements and not even requiring initiative from the package maintainers. The only requirement was that the package be free and not promote non-free software. It's okay to set stricter requirements and to ask maintainers to comply if they want the privilege of having their package listed in NonGNU ELPA. But then I won't be surprised if in 1 year the question of "why do people use Melpa when there is GNU ELPA and NonGNU ELPA" comes up. > It also seems inconsistent to have so many packages, both GNU ELPA and no= n-GNU ELPA packages hosted on a platform which is so far from being accepta= ble from a FSF philosophical perspective. Makes it feel like the FSF fails = to eat their own dog food. I agree. But I don't think that adding requirements is the answer. >> >> >> I agree that some of the difficulties posed by copyright assignment do >> not apply for relocation (e.g. that one contributor 7 years ago whom >> nobody can contact), but there is an effort involved in both. > > > Copyright issues are not relevant for non-GNU ELPA. > -- > regards, > > Tim > > -- > Tim Cross >