From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: non-gnu elpa issue tracking Date: Thu, 10 Dec 2020 09:54:44 +0300 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27163"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Emacs-Devel List To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 10 09:38:23 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 1knHSw-0006xl-En for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 09:38:22 +0100 Original-Received: from localhost ([::1]:34684 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knHSv-0005d7-GX for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 03:38:21 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knHNP-00083a-4n for emacs-devel@gnu.org; Thu, 10 Dec 2020 03:32:39 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:34095) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knHNN-0007Rh-9F for emacs-devel@gnu.org; Thu, 10 Dec 2020 03:32:38 -0500 Original-Received: from localhost ([::ffff:41.202.241.31]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E525.000000005FD1DD23.000012F7; Thu, 10 Dec 2020 01:32:35 -0700 Content-Disposition: inline In-Reply-To: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-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:260639 Archived-At: * Boruch Baum [2020-12-09 15:57]: > 1) License disclosure: The summaries indicate that RMS is open to having > the repository host packages bearing *any* free license, but there > may be users who are pickier, so a package's license should be > disclosed prominently on the listing page and the package detail > page; For me it was natural that free software license should be GPL compatible license, so I was consulting this page when reviewing a pattern of licenses: https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses Example is public domain but not CC0 where such package is not compatible with the GPL as it is not compatible with world jurisdictions. Many would not recognize "public domain" and that renders software proprietary. I think that new column or license in the description of the package would be beneficial. The stance alone that licensing is important and that GPL compatible licenses are acceptable is also good for people to get awareness. > 2) The acceptance or candidacy process for each package should be > documented in some discrete method. Melpa does this using github's > pull request feature, which documents the entire conversation related > to the process of accepting a package. It should be clear now that some packages do not even bear any license inside. kiwix-20200714.1357.tar - has no license inside. Maybe it has in the original repository, but the license must be given explicitly. If not given explicitly with software it is proprietary. If it was a mistake by Melpa's workflow then Emacs developers could try to look into the original repository and fetch software from there. This would be anyway better. Those are 2 examples showing that Melpa does not do the job well and there are hundreds of other examples. That shows that their process of documenting acceptance of the packages is flowed, and process of distributing packages is flowed. Melpa distributes proprietary packages. There is no need to compare to it. As the major difference between GNU ELPA and Melpa is ethics, one need not compare ethical repository to the one lacking ethical principles. Let us say if I wish to make private repository of Emacs packages I would not be discussing with anybody, I would just make it. > 3) After a package is initially accepted to the repository, the > summaries of Richard Stallman's presentation indicate that subsequent > commits or releases may be rejected or modified. That record should > also be documented. Debian does this using its own package tracking > software. If there is a mailing list where people apply with patches it would get automatically recorded. Just as now for Emacs and GNU ELPA packages.