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: Sat, 12 Dec 2020 22:54:56 +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="10104"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Richard Stallman , thibaut.verron@gmail.com, Boruch Baum , Emacs developers , Stefan Kangas , Stefan Monnier To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 12 21:01:08 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 1koB4l-0002Y3-26 for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 21:01:07 +0100 Original-Received: from localhost ([::1]:50404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koB4j-00078Z-TJ for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Dec 2020 15:01:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42780) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koB1r-0005Jv-Hs for emacs-devel@gnu.org; Sat, 12 Dec 2020 14:58:07 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:32913) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koB1o-0004i7-Vk; Sat, 12 Dec 2020 14:58:06 -0500 Original-Received: from localhost ([::ffff:41.202.241.30]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000308F6.000000005FD520C9.00005F44; Sat, 12 Dec 2020 12:58:00 -0700 Content-Disposition: inline In-Reply-To: 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:260723 Archived-At: * Tim Cross [2020-12-12 18:37]: > On Sun, 13 Dec 2020 at 00:50, Stefan Monnier > wrote: > > > > The non-GNU ELPA is supposed to be a repository for packages which are > > GPL > > > compliant and it is a reasonable expectation that those who make their > > > packages GPL compliant do so because they support the philosophical goals > > > of the FSF. > > > > The overwhelming majority of ELisp packages out there are hosted on > > Github (that also applies to many GNU ELPA packages, many of them are > > developed by long time contributors to Emacs), so I think the evidence > > shows the above expectation doesn't hold at all. > > > > Maybe. However, it could also be a combination of the fact github was the > first free git hosting environment and is the better known one. Just > because it is this way now doesn't mean it has to be. If the GNU/FSF > doesn't take a clear position on this and do something to discourage the > use of hosting environments that force the use of proprietary software, > this will not change and eventually all we will have are the proprietary > solutions. It may not have been the right decision to allow code which has > assigned copyright to the FSF to remain on Github. However, as non-GNU ELPA > is just getting started, now would be a good time to try and change > things. Exactly. > I'm also not convinced about arguments suggesting too much inertia or too > much hassle in moving to a new hosting platform. That IS the goal of Github to make people become very dependent that they cannot switch. Using that argument is advertising the Github indirectly. Every code hosting platform shall not make developers and software development dependent on it. Github does exactly that with its proprietary applications served for developers. > There are few technical barriers to moving git repositories to a new > hosting platform. However, there has to be some incentive to do so. > It also seems inconsistent to have so many packages, both GNU ELPA > and non-GNU ELPA packages hosted on a platform which is so far from > being acceptable from a FSF philosophical perspective. Makes it feel > like the FSF fails to eat their own dog food. Exactly.