From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Sat, 16 Aug 2008 14:04:11 -0700 Message-ID: <48A740CB.4050404@emf.net> References: <10697146.3630221218551689983.JavaMail.www@wwinf4615> <20080812171404.GB7999@muc.de> <20080813092057.GA3010@muc.de> <20080814083817.GA2593@muc.de> <877iak7xfp.fsf@skyscraper.fehenstaub.lan> <873al79akr.fsf@skyscraper.fehenstaub.lan> <48A5BAD7.8030302@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218917702 11071 80.91.229.12 (16 Aug 2008 20:15:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Aug 2008 20:15:02 +0000 (UTC) Cc: acm@muc.de, ams@gnu.org, hannes@saeurebad.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 16 22:15:54 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KUSBj-0004Mf-KU for ged-emacs-devel@m.gmane.org; Sat, 16 Aug 2008 22:15:52 +0200 Original-Received: from localhost ([127.0.0.1]:49885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KUSAl-00011j-Np for ged-emacs-devel@m.gmane.org; Sat, 16 Aug 2008 16:14:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KUSAg-0000zg-A1 for emacs-devel@gnu.org; Sat, 16 Aug 2008 16:14:46 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KUSAd-0000w8-QI for emacs-devel@gnu.org; Sat, 16 Aug 2008 16:14:45 -0400 Original-Received: from [199.232.76.173] (port=38933 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KUSAd-0000w3-Gq for emacs-devel@gnu.org; Sat, 16 Aug 2008 16:14:43 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:44422) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KUSAQ-0000vl-Eh; Sat, 16 Aug 2008 16:14:31 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.75.128] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 37026385; Sat, 16 Aug 2008 13:14:08 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102538 Archived-At: Richard M. Stallman wrote: > How does not providing dynamic loading maximize what users can > do while remaining free? > > It protects against the danger of non-free C-level add-ons to Emacs. > It's the same principle as the GPL itself. > That doesn't answer the question. You said something odd: that not having a dynamic loading feature helps to maximize what users can do in freedom. That's false, though. Having a dynamic loading feature would let users do more, in freedom. Suppose it were *certain* that non-free (but perfectly legal) C-level add-ons to GNU Emacs would result from adding a dynamic loading feature. That isn't a good argument to not add the feature and here is why: It is equally certain that GNU Make is used to build non-free programs. It is equally certain that GCC is used to compile non-free programs. It is equally certain that GNU Emacs is used to edit non-free programs. It is historic fact that one of the biggest areas in which free software projects have succeeded in creating free software jobs is in maintaining and extending a GNU/Linux platform for running non-free programs. It is a historic fact that those free (both senses) tools have led to the creation of non-free programs that were otherwise unlikely to be written. The GNU project can not help but abet the creation of non-free programs, as long as their are people who want to create non-free programs. If we accept that the consequence of non-free programs is reason enough to reject a feature, we ought not write any software at all! On the other hand, it is *plausible* that a well designed dynamic loading feature would lead to tiny "boom" in new free software programs. Third parties could release C-level, free software extensions to GNU Emacs without any need for additional coordination with the GNU Emacs maintainers. There would be opportunity for people to experiment more freely with C-level extensions -- more chances to find new uses. There would be a new marketplace of technical ideas in which people are enriched by exercising their software freedoms. When people have cause to *exercise* their software freedoms they come to understand those freedoms better. They are more likely to come to regard those freedoms as simply "natural" -- as a basic right. If more people are busy exercising their software freedoms, more people will be prepared to defend those freedoms. Since it is plausible that a dynamic loading feature can lead to more people exercising their software freedoms, and since a dynamic loader makes decent sense technically and at an architectural level, there are strong arguments *for* adding a dynamic loader. An analogous analysis applies to tree print and read in GCC. Certainty that non-free uses will result hardly changes much of anything and is not a strong argument against the feature. Plausibility that the feature will lead to more free software uses of GCC is a strong argument for the feature. If you want to think about what software to NOT write in order to save work, think about software architecture and maintainability and stuff like that. Maybe it is wise to NOT write program X because writing Y instead is simpler. But thinking about what NOT to write as some kind of tactic for discouraging new non-free programs is ineffective unless we write no programs at all! It is better to think about what programs TO WRITE and to think in terms of "combinatorics". A good GNU system will contain a maximal number of opportunities to write new programs, new modules, new add-ons, etc. The more that people *actually do* with their software freedom, the more they will come to understand and value their software freedom. -t