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 14:49:45 +0300 Message-ID: References: <20201209125516.lenqswi7fhiscbr2@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2668"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Emacs-Devel List , Stefan Kangas , Boruch Baum To: Thibaut Verron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 10 13:16:32 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 1knKs4-0000Z8-DZ for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 13:16:32 +0100 Original-Received: from localhost ([::1]:48332 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1knKs3-0006Q9-Bm for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Dec 2020 07:16:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knKa2-0002qK-35 for emacs-devel@gnu.org; Thu, 10 Dec 2020 06:57:54 -0500 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:54979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1knKZv-0001hH-En for emacs-devel@gnu.org; Thu, 10 Dec 2020 06:57:52 -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 000000000001E529.000000005FD20D37.00002597; Thu, 10 Dec 2020 04:57:43 -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:260647 Archived-At: * Thibaut Verron [2020-12-10 12:15]: > Le jeu. 10 déc. 2020 à 09:32, Jean Louis a écrit : > > > > * Thibaut Verron [2020-12-10 02:23]: > > > > > > > > My opinion is that non-GNU ELPA and GNU ELPA both should never point > > > > to any website that has any proprietary Javascript or promotes > > > > proprietary software, specifically hyperlinks to Github better be > > > > removed completely. > > > > > > > > > > Without backlinks to the original repositories, how will people know where > > > to report bugs with packages installed from non-GNU ELPA? > > > > My opinion is that nothing offered within Emacs, be it ELPA packages > > or now non-GNU ELPA packages should guide users to any non-free > > software, especially not websites with non-free Javascript like > > Github. > > Would gitlab be acceptable, at the very least? Not my decision. Developers decide on that. Maybe people wish to see this reference: https://www.gnu.org/software/repo-criteria-evaluation.html There are many similar. Codeberg.org (Germany) https://codeberg.org Sourcehut.org https://sourcehut.org Trisquel GNU/Linux-libre Git Repositories https://devel.trisquel.info/groups/trisquel Pagure https://pagure.io/pagure Fosshost https://fosshost.org/ GitGud - Fast and Free Git Hosting https://gitgud.io/users/sign_in > > Author name should be there, email address and there can be URL as > > per: (info "(elisp) Simple Packages") > > > > I would change that URL to point to non-GNU ELPA repository as it > > becomes not only plain distributor but slight fork of the > > package. There is nothing wrong with it. People can still use author's > > name and email to report directly. > > I personally would be annoyed if users started reporting bugs directly > to my e-mail. I cannot imagine how it would be for high-traffic > packages. Packages live their URL and author's name. I do not think that licenses forbid changing the URL. Normally one has to tell who are authors and provide license. From that viewpoint whatever authors write in the package commentary or README file will be used by users. non-GNU ELPA is more similar to a fork. As the control will be maintained which packages are distributed to users and what is changed there or modified. In that sense it can be that for some features we start reporting to non-GNU ELPA, and not to upstream. We discussed here that it is desirable to make relations with upstream authors. But what if they do not wish? Then packages, as they are free software, may be distributed and modified in non-GNU ELPA without notification to author. > And what about packages with extensive guidelines for reporting bugs? > Should they now include those guidelines in the package description? > And would you amend those guidelines to remove references to github, > too? I don't think so and I am not authorized to make statements on that. I think that general questions do not lead to useful solution. There is no need to make hypothetical conclusions as there is no specific package to talk about. > I thought that the point of non-GNU ELPA was to bridge the gap between > the emacs developers and the "community developers". But this kind of > minor ideological changes, in my opinion, is more likely to antagonize > developers. I see it quite contrary. People will get interested and will apply to non-GNU ELPA with their proposals. There are limits mostly related to free software principles, there are packaging guidelines, there is certai limit how many packages can be handled by developers in what period of times. By opening non-GNU ELPA GNU project is doing exactly what you said, providing a bridge that any Emacs Lisp developers, may get their packages easier discovered by default. We shall not forget that option to include the package to GNU ELPA always existed and exists today. Everybody is welcome. Naturally those who have proprietary packages would need to adopt their license for that to take place. Sorry, I cannot see minor ideological changes, in fact I see no ideological change at all since decades. If we wish to compare it to MELPA, we today discovered that MELPA practically distributes proprietary software. Then a person discovered that the license does exist somewhere else on Github. If I would have package there and license in the same repository that would make me feel unjust that somebody like MELPA is fetching my package and not distributing license with it. In that sense MELPA is changin the author's package without author's knowledge. That is all by mistake and some neglect, not by bad intention. While changing author's package MELPA is not antagonizing anybody, so will non-GNU ELPA not antagonize anybody. Quite contrary, people wish to integrate with each other and help each other. As I said, hypothethical talk is not useful. Bring a package and ask if such can be included. Let us see, that we do not create problems out of nothing. I am sure that Emacs developers already have lists of packages in their mind and will come to it soon. > Am I correct to understand that if some developers decide that they do > not want their package included in non-GNU ELPA, the only way that > they can enforce this decision is to use a less permissive license for > future releases? > > I don't think that we want to encourage such a choice. Maybe you review again what is free software. As I already pointed, if you have account on Github, within seconds you can already fork other people's software, and you do not need to ask people about that. They have already given explicit permission that you may copy software, modify it, distribute it. I do not see practical reason why would a developer object that free softwar package is distributed, copied, modified from some other place than original repository? If they do object, they can tell their opinion, but nevertheless the rights obtained by free software license cannot be just taken back as author wish and want. Thus the hypothetical case you explained above I cannot see happening. Quite contrary I feel that when Emacs packages are distributed that authors have certain pleasure when other people use the package how they wish and want. > > Remember that this does not prevent other users of any other website > > such as MELPA to use their hyperlinks how they like. T > > > > This opinion is for specifically for Emacs that should never point to > > non-free websites and relates to ELPA as well. > > > > So I do not see any real problem there. Those using MELPA will do what > > they wish. > > I thought the goal of non-GNU ELPA was to make MELPA necessary only > for non-free packages, and thus useless of the vast majority of > users. That would be negative goal that goes into wrong direction. If MELPA is useful or not useful it does not matter. It is different project with a different set of ethical principles. GNU is different project with different sent of ethical principles. Goal for GNU is to provide free operating system and for Emacs packages to be useful free software accessible by default without user having to stumble upon or being guided into non-free or proprietary software. Goal is not to make other repository useless. Various groups and communities do what they want. GNU project is always proposing to use free software, to distribute licenses correctly, it teaches users about free software. If some separate project like MELPA provided non-free software then such will get less and less recommended by GNU project or never at all. As simple as that. It is analogous to Archlinux that has open policy to accept any software including proprietary as long as authors agree that it can be distributed from Archlinux. GNU project cannot possibly recommend Archlinux to users. That does not mean that GNU project is working against Archlinux to make it useless. Nothing changed fundamentally in GNU project, what changed is in those other communities. > If "non-free" now includes all those packages whose developers don't > want to deal with issues outside of github, it can become a lot more > extensive. That is not definition of non-free. Remember that my opinion is personal, not authorized for GNU project to speak of final decisions. If I understand it well you mean that some issues to maintain packages will be sent by Emacs users and such issues may not arrive to developers of upstream package? People discussed it already here that non-GNU ELPA should establish relations with authors so that authores can contribute directly to non-GNU ELPA. Compare that to Github fork: 1. User clicks to fork the package. Author is not asked anything. Package is just forked. They may not even speak to author ever. 2. Or telling author kindly that non-GNU ELPA is now interested to distribute the package and if author wish to maintain it directly. Those questions rather apply to Github, not to GNU. Please remember that license gives rights to copy, modify, distribute packages as users wish and want. When doing so, I could change all original URLs and point back to my URL as long as license is respected. I could now say: I do not wish to take any reports or bugs, issues, as they are not welcome. That is what many people do when they finish with the package. They will say take it and do what you wish with it, it is free software, but I have not time for it. > > And those using non-GNU ELPA would report there where > > developers decide, but not on Github, provided this type of proposal > > is accepted. > > What is "there" in this context? And who are "developers"? Remember, me not authorized for Emacs developers. I am expressing personal opinion. Emacs developers will decide how they will publish software they package in non-GNU ELPA. They have yet to say how to report bugs on such packages. I would not like if GNU project would start pointing to people: go back to Github and report bugs there for reason that users are driven or guided to non-free software and unethical software repositories. When making those comparisons and analyzes I suggest that you first compare it to what is already at hand and present in the world. Example is Melpa, you are free to pull sources for Melpa and open up your own server providing your own ELPA. It is trivial to do so as they have given website, and scripts available for everybody. Maybe main problem is that people do not know how to setup their own servers. When doing so, pulling software, everybody is free to modify what is free software and offer to others. Melpa is doing that on each software package by modifying their version numbers and other meta data. Isn't modification of a version number against author's decision? I think it is. But it is free software and Melpa is free to do what they wish. They can say that version number is 2 when it is 1. Free software. GNU/Linux distributions such as Debian modify the software with patches. They desire but do not need to ask original authors. What is more important is maintainer of a package who does the job and prepares package to be compatible with other packages. Imagine if Debian would be waiting for authors to start acting upon something they maybe long forgotten or do not maintain. Companies like Redhat have been modifying Linux kernel. Many companies modified Linux kernel without necessarily informing developers. Free software. But as long as kernel is distributed developers could get those modifications back. Compare those thoughts of today to that what is already present in the world to see that there is nothing different in non-GNU ELPA in the context of software modification and distribution. Jean