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: Wed, 27 Aug 2008 15:32:15 -0700 Message-ID: <48B5D5EF.2030501@emf.net> References: <48A5BAD7.8030302@emf.net> <48A740CB.4050404@emf.net> <20080816213508.GA8530@muc.de> <87hc9ka8eg.fsf@uwakimon.sk.tsukuba.ac.jp> <20080817073124.GA1294@muc.de> <87ljyv5gy5.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818101802.GA2615@muc.de> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> <87ljytkwpk.fsf@rattlesnake.com> <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@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 1219873317 2417 80.91.229.12 (27 Aug 2008 21:41:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Aug 2008 21:41:57 +0000 (UTC) Cc: bob@rattlesnake.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 27 23:42:50 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 1KYSmv-0007UQ-TE for ged-emacs-devel@m.gmane.org; Wed, 27 Aug 2008 23:42:50 +0200 Original-Received: from localhost ([127.0.0.1]:59023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYSlx-0006Au-MH for ged-emacs-devel@m.gmane.org; Wed, 27 Aug 2008 17:41:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KYSlt-0006AR-05 for emacs-devel@gnu.org; Wed, 27 Aug 2008 17:41:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KYSls-0006A7-BH for emacs-devel@gnu.org; Wed, 27 Aug 2008 17:41:44 -0400 Original-Received: from [199.232.76.173] (port=42309 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KYSls-0006A4-56 for emacs-devel@gnu.org; Wed, 27 Aug 2008 17:41:44 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:43963) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KYSlm-0005R1-Ki; Wed, 27 Aug 2008 17:41:38 -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 37792258; Wed, 27 Aug 2008 14:41:22 -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:103053 Archived-At: Richard M. Stallman wrote: > In other words: the incentive to create the non-free > XRefractory comes, in part, from the ban on a dynamic > loader. > > Your reasoning is confused, and the conclusion makes no sense. > My decision remains unchanged. > My reasoning is not confused. I'll restate it more plainly: Consider a feature, X, which is desirable for practical purposes. Consider a feature, Y, which is banned. If the ban on Y makes X harder to implement, in the sense of costing more in labor or money, then the economic incentive to go into business selling a non-free implementation of X goes up. The reason that incentive goes up is because the cost of going into business selling a non-free X goes up while the demand for the practically useful X remains steady. Now, someone with some money that they want to spend writing new, non-free software looks at that and says "I think I can do X, in spite of the ban on Y. In fact, given the work I did on my masters thesis, I think I can do X cheaper than most people. If I start selling a non-free X, it will be a long time before some competitor comes along either selling a non-free competitor to X or sharing a free version of X. It will be a long time because I'm almost the only one with an effective idea of how to get around the ban on Y. Therefore, I'll go into business selling proprietary X and count my blessings for the banning of Y." There are (and have long been) available to the GNU project a kind of dichotomy of positive and negative strategies for designing and implementing software. On the positive side: writing code that directly helps users' and developers' of free software. On the negative side, writing code or refusing to write code -- either way -- so as to push back the goals of non-free software developers. Obviously the happiest cases are when the strategy can use both simultaneously: with one line of code written or not written both help users and developers on the free side and directly impede developers on the non-free side. The hard cases (apparently) are when the only choices apparent are either only positive or only negative: only help free software users and developers directly, or only directly interfere with non-free developer ambitions -- but not both. The dynamic loader and GCC tree print/read problems are in this category of "either but not both". What I am pointing out to you is that those "either but not both" cases are not very clear cut -- you don't actually have the choice you think you have. You *think* that the dynamic loader ban impedes non-free Emacs add-ons but the abstract argument above about X and Y and the specific real-world example of XRefractory illustrate that, well, the dynamic loader ban may actually make especially problematic non-free add-ons *more* likely. So, what "strategy do you use for picking a strategy" when cases like that arise -- cases of partial knowledge and easy mistakes like that? I say: stay positive and stick to what you know about making life easier for free software users and developers and ignore any (probably mistaken) hypotheticals about what non-free developers might do. The more capable free software users and developers become, the faster the free software movement will snowball and win -- at least that is the view that comes from confidence. Remember that 30 years ago you were a hacker just out to "improve the system" and any artificial legal hoo-haw that got in the way just seemed stupid (at first) and then sinister (leading to the movement). Ok, so... don't go from that good position, way back then, to a modern one where for some twisted reason you conclude that you should decline to "improve the system" when you have every right to. Feature bans are antithetical to the hacker spirit that gave rise to the free software movement. -t > > >