From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: enable MELPA & Marmalade by defaul [was: mykie.el] Date: Mon, 6 Jan 2014 21:39:35 -0800 (PST) Message-ID: <93a2d060-c7f8-4ce3-9bff-f7397be690ff@default> References: <87bnzshlo5.fsf@flea.lifelogs.com> <87bnzshlo5.fsf@flea.lifelogs.com> <20140103.200846.1574807089640559527.cokesboy@gmail.com> <87a9f8g22x.fsf@flea.lifelogs.com> <76f5b9cd-3452-4189-b3a0-30dc55a3ee55@default> <87wqic65kj.fsf@wanadoo.es> <874n5gfvjv.fsf@mac.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389073197 2863 80.91.229.3 (7 Jan 2014 05:39:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 05:39:57 +0000 (UTC) Cc: =?iso-8859-1?B?03NjYXIgRnVlbnRlcw==?= , emacs-devel@gnu.org To: Eric Brown Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 06:40:02 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W0POT-0007pW-T4 for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 06:40:02 +0100 Original-Received: from localhost ([::1]:38923 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0POT-0002jR-0Z for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 00:40:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0POI-0002iR-9O for emacs-devel@gnu.org; Tue, 07 Jan 2014 00:39:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0PO8-0004Sv-Eu for emacs-devel@gnu.org; Tue, 07 Jan 2014 00:39:50 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:32479) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0PO8-0004Sn-5F for emacs-devel@gnu.org; Tue, 07 Jan 2014 00:39:40 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s075dcp3016474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jan 2014 05:39:39 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s075dbeh014404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 05:39:37 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s075dbTF011448; Tue, 7 Jan 2014 05:39:37 GMT In-Reply-To: <874n5gfvjv.fsf@mac.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167568 Archived-At: Hi Eric, > >> > Why shouldn't GNU Emacs enable all three by default? > >> > That would help GNU Emacs users more, I think. > >> > >> One easy answer is that MELPA and Marmalade are non under the > >> control of the Emacs prooject. > > > > So? GNU Emacs is not responsible for whatever it might be that > > those repos have or do. And I think we (should) know by now > > that most, if not all, of what they do can be helpful for Emacs > > users. >=20 > I think this falls into the category of "should a GNU project > recommend repositories that contain non-free software?" Putting them in the available-by-default list does *not* recommend them, IMO. And it is certainly possible for GNU Emacs to post a big banner saying that the ONLY repository it recommends is its own ELPA repository, genuine GNU ELPA. Nothing wrong with that. Would that satisfy your recommendation worry? And anyway, nothing says that those repositories involve much non-free software, or even any at all. Without looking, I'd bet that the *overwhelming mass* of packages in those two repositories are free software (GPL'd). Why make users jump through extra hoops to access all that free software, even if there might also be a non-free package there somewhere? Do you think that a downloading user cannot tell whether some software is free or not? If so, is this about trying to hide that non-free software from their unsuspecting hands, so they cannot make the awful mistake of not recognizing it? If so, that kind of protection-by-ignorance is doomed to be ineffective and even counterproductive in the long run, IMHO. > RMS and his defense of the FSF position (and composure in > the face of very shabby treatment) are remarkable. Agreed 100%. And so? Has RMS said that listing those two repositories would hurt free software? Maybe a lawyer from the FSF will chime in. (As if we didn't get enough software-development-by-legal-department these days..., but I digress.) > If Emacs (or any GNU/FSF program) actively prevented the > installation of software, or surfing to a site of the users' > choice, that would be censorship. I did not suggest that. I suggested listing those repos by default. That neither censors access to them nor particularly recommends them (IMO). How about my Samsung - Netflix analogy? Do you think you'd stand a chance if you sued Samsung because one of Netflix's films offended you? Is Samsung liable for bad Netflix films because it makes Netflix available by default on your new TV? Your public library (that nasty socialist institution!) no doubt has some books that some people might find objectionable. The library does make a selection - it decides what to make available. But that does not mean that the library censors those books that are not in its catalog. And it does not mean that the library necessarily recommends each of its books for each of its readers. Some users perhaps should not read some books or install some software packages, at least not until they feel they are ready and want to do so. That does not mean that books or software that might be helpful to other users (even perhaps most users) should not be made easily available to them. It is my guess that the vast majority of packages in those two repositories (a) are useful to at least _some_ Emacs users, (b) are probably not poisonous to _any_ Emacs users, and (c) are likely not at all problematic for _most_ Emacs users. Do you have a different guess in this regard? (Please note the qualifiers, in particular "vast majority".) If that is the case (folks here can make that judgment/guess), then is it more helpful to users to add those two repositories to the default list? I think so. You are welcome to disagree. > It is another matter entirely to _recommend_ the software > sites, because the FSF believes that this constitutes some > form of complicity in leading someone astray. (Whether the > end-user believes it is immaterial.) Sorry, I really do not see it that way. But then, I am not a lawyer. I'm thinking about what could be most helpful for most users (in my judgment). I do not see simply listing MELPA by default as constituting a blanket endorsement of everything on MELPA. I cannot imagine that any user would see it that way. (A lawyer who wants to make his job easier might see it that way, or at least say that he does.) > > Think users, not lawyers. This is not GNanny, or at > > least it did not used to be. >=20 > It is trivial for a user to enable these repositories. Maybe so, but I have seen questions here and there about doing so. List them and it becomes even more trivial. And no doubt it is just as trivial to remove one from the list, or to simply ignore it, no? And to enable them, they need to know they exist. Listing them by default obviates a separate discovery step: here they are. Just what are you trying to protect users or GNU Emacs from? It's a serious question. I'd like to get a specific answer. So far, we've heard about the bogeyman of "(all?)" MELPA packages destroying a user's environment or whatever (nothing about free software in that scarefest). That's one extremely vague anecdote from Oscar about one user having had one bad experience. Sheesh. And now we've gotten a vague catastrophe scenario from you about free software being somehow polluted and dragged down to depravity and degradation by inadvertent downloading of non-free software. But seriously, what is the *real track record* for the 1487 packages on MELPA and the *hundreds of thousands* of package downloads from MELPA so far? Any knowledge of mass suffering? Any statistics about non-free software corrupting free-software environments or users? The experiment has been running for a while now. Surely we should know by now if there is a big problem here that really needs preventing. No? What's the story - real danger or not? > What is not trivial is endeavoring to maintain a libre software > installation, but having non-free repositories enabled. It is truly > shocking that proprietary "feature-enhancing" extensions can get > installed onto a system by package managers, though the selected > software package (e.g. Chromium) was in fact libre. Any evidence that that has anything to do with the question at hand? =20 > From another perspective, it makes it difficult to develop software > systems for commercial purposes, because can't be sure that my > company can use for any purpose or redistribute the codes. I think you are really exaggerating there (but I am not a lawyer). That sounds very much like the kind of thing one sometimes hears in commercial companies about GNU (!) and why GNU software should be avoided like the plague by companies because it supposedly sucks all of the company's own software into a free-software tainted purgatory. Dueling bogeymen. > In principle, a repo author may rise like a submarine, when he > discovers that he could strike it rich because of (unintended) > license violations. IANAL, but I believe that unless otherwise > stated, all rights are reserved. Sounds like we need to hear from a law expert about this. All of that sounds wildly exaggerated to me. Just because a repository might have some packages (and is that even sure?) that are not free software, even if it also has hundreds of useful free-software packages (which I think is the case), is it the end of the world for GNU Emacs to list that repository? In that scenario, I would say that the benefit (to users, and to Emacs itself) would *FAR* outweigh whatever cost you imagine to free software. But perhaps (no doubt) I am not grasping the seriousness of the threat to free software posed by listing these two repositories. So far, I've seen nothing specific - only bogeymen and vague Chicken Little alarmism. Where's the beef? I do appreciate the concern. I suspect that it is misplaced. But I, like you, am not a lawyer. I realize that I am likely seeing a small part of a bigger picture. Lawyer input welcome.