Have you ever wanted to use Lintian's spell-checker against arbitrary files? Now you can do it with spellintian:

$ zrun spellintian --picky /usr/share/doc/RFC/best-current-practice/rfc*
/tmp/0qgJD1Xa1Y-rfc1917.txt: amoung -> among
/tmp/kvZtN435CE-rfc3155.txt: transfered -> transferred
/tmp/o093khYE09-rfc3481.txt: unecessary -> unnecessary
/tmp/4P0ux2cZWK-rfc6365.txt: charater -> character

mwic (Misspelled Words In Context) takes a different approach. It uses classic spell-checking libraries (via Enchant), but it groups misspellings and shows them in their contexts. That way you can quickly filter out false-positives, which are very common in technical texts, using visual grep:

$ zrun mwic /usr/share/doc/debian/social-contract.txt.gz
DFSG:
   an Free Software Guidelines (DFSG)
   an Free Software Guidelines (DFSG) part of the
                                ^^^^
Perens:
     Bruce Perens later removed the Debian-spe 
  by Bruce Perens, refined by the other Debian 
           ^^^^^^
Ean, Schuessler:
  community" was suggested by Ean Schuessler. This document was drafted
                              ^^^ ^^^^^^^^^^
GPL:
  The "GPL", "BSD", and "Artistic" lice 
       ^^^
contrib:
  created "contrib" and "non-free" areas in our 
           ^^^^^^^
CDs:
  their CDs. Thus, although non-free wor 
        ^^^

It doesn t look so old in hex; Zero, x, Two, Eight but I finally got there. So on this day, what other landmarks am I up to?

• I ve been programming, on and off, for 28 years (thanks for teaching me Chris anyone still use LOGO?)
• Writing Free Software for 17 years (thanks Terry for explaining the concepts and giving me my first Linux)
• A debian developer for 14 years (thanks for telling me and eventually adding me Bruce)

Some people get a little sad hitting this age, but it really is only a number, wether it is 0 28, \050 or even 40. As the saying goes: only the dead don t age.

A few days ago an article in the Norwegian Computerworld magazine about how version 2.0 of European Interoperability Framework has been successfully lobbied by the proprietary software industry to remove the focus on free software. Nothing very surprising there, given earlier reports on how Microsoft and others have stacked the committees in this work. But I find this very sad. The definition of an open standard from version 1 was very good, and something I believe should be used also in the future, alongside the definition from Digistan. Version 2 have removed the open standard definition from its content. Anyway, the news reminded me of the great reply sent by Dr. Edgar Villanueva, congressman in Peru at the time, to Microsoft as a reply to Microsofts attack on his proposal regarding the use of free software in the public sector in Peru. As the text was not available from a few of the URLs where it used to be available, I copy it here from my source to ensure it is available also in the future. Some background information about that story is available in an article from Linux Journal in 2002.

Lima, 8th of April, 2002
To: Se or JUAN ALBERTO GONZ LEZ
General Manager of Microsoft Per Dear Sir: First of all, I thank you for your letter of March 25, 2002 in which you state the official position of Microsoft relative to Bill Number 1609, Free Software in Public Administration, which is indubitably inspired by the desire for Peru to find a suitable place in the global technological context. In the same spirit, and convinced that we will find the best solutions through an exchange of clear and open ideas, I will take this opportunity to reply to the commentaries included in your letter. While acknowledging that opinions such as yours constitute a significant contribution, it would have been even more worthwhile for me if, rather than formulating objections of a general nature (which we will analyze in detail later) you had gathered solid arguments for the advantages that proprietary software could bring to the Peruvian State, and to its citizens in general, since this would have allowed a more enlightening exchange in respect of each of our positions. With the aim of creating an orderly debate, we will assume that what you call "open source software" is what the Bill defines as "free software", since there exists software for which the source code is distributed together with the program, but which does not fall within the definition established by the Bill; and that what you call "commercial software" is what the Bill defines as "proprietary" or "unfree", given that there exists free software which is sold in the market for a price like any other good or service. It is also necessary to make it clear that the aim of the Bill we are discussing is not directly related to the amount of direct savings that can by made by using free software in state institutions. That is in any case a marginal aggregate value, but in no way is it the chief focus of the Bill. The basic principles which inspire the Bill are linked to the basic guarantees of a state of law, such as:

• Free access to public information by the citizen.
• Permanence of public data.
• Security of the State and citizens.

To guarantee the free access of citizens to public information, it is indispensable that the encoding of data is not tied to a single provider. The use of standard and open formats gives a guarantee of this free access, if necessary through the creation of compatible free software. To guarantee the permanence of public data, it is necessary that the usability and maintenance of the software does not depend on the goodwill of the suppliers, or on the monopoly conditions imposed by them. For this reason the State needs systems the development of which can be guaranteed due to the availability of the source code. To guarantee national security or the security of the State, it is indispensable to be able to rely on systems without elements which allow control from a distance or the undesired transmission of information to third parties. Systems with source code freely accessible to the public are required to allow their inspection by the State itself, by the citizens, and by a large number of independent experts throughout the world. Our proposal brings further security, since the knowledge of the source code will eliminate the growing number of programs with *spy code*. In the same way, our proposal strengthens the security of the citizens, both in their role as legitimate owners of information managed by the state, and in their role as consumers. In this second case, by allowing the growth of a widespread availability of free software not containing *spy code* able to put at risk privacy and individual freedoms. In this sense, the Bill is limited to establishing the conditions under which the state bodies will obtain software in the future, that is, in a way compatible with these basic principles. From reading the Bill it will be clear that once passed:

the law does not forbid the production of proprietary software

the law does not forbid the sale of proprietary software

the law does not specify which concrete software to use

the law does not dictate the supplier from whom software will be bought

the law does not limit the terms under which a software product can be licensed.

What the Bill does express clearly, is that, for software to be acceptable for the state it is not enough that it is technically capable of fulfilling a task, but that further the contractual conditions must satisfy a series of requirements regarding the license, without which the State cannot guarantee the citizen adequate processing of his data, watching over its integrity, confidentiality, and accessibility throughout time, as these are very critical aspects for its normal functioning. We agree, Mr. Gonzalez, that information and communication technology have a significant impact on the quality of life of the citizens (whether it be positive or negative). We surely also agree that the basic values I have pointed out above are fundamental in a democratic state like Peru. So we are very interested to know of any other way of guaranteeing these principles, other than through the use of free software in the terms defined by the Bill. As for the observations you have made, we will now go on to analyze them in detail: Firstly, you point out that: "1. The bill makes it compulsory for all public bodies to use only free software, that is to say open source software, which breaches the principles of equality before the law, that of non-discrimination and the right of free private enterprise, freedom of industry and of contract, protected by the constitution." This understanding is in error. The Bill in no way affects the rights you list; it limits itself entirely to establishing conditions for the use of software on the part of state institutions, without in any way meddling in private sector transactions. It is a well established principle that the State does not enjoy the wide spectrum of contractual freedom of the private sector, as it is limited in its actions precisely by the requirement for transparency of public acts; and in this sense, the preservation of the greater common interest must prevail when legislating on the matter. The Bill protects equality under the law, since no natural or legal person is excluded from the right of offering these goods to the State under the conditions defined in the Bill and without more limitations than those established by the Law of State Contracts and Purchasing (T.U.O. by Supreme Decree No. 012-2001-PCM). The Bill does not introduce any discrimination whatever, since it only establishes *how* the goods have to be provided (which is a state power) and not *who* has to provide them (which would effectively be discriminatory, if restrictions based on national origin, race religion, ideology, sexual preference etc. were imposed). On the contrary, the Bill is decidedly antidiscriminatory. This is so because by defining with no room for doubt the conditions for the provision of software, it prevents state bodies from using software which has a license including discriminatory conditions. It should be obvious from the preceding two paragraphs that the Bill does not harm free private enterprise, since the latter can always choose under what conditions it will produce software; some of these will be acceptable to the State, and others will not be since they contradict the guarantee of the basic principles listed above. This free initiative is of course compatible with the freedom of industry and freedom of contract (in the limited form in which the State can exercise the latter). Any private subject can produce software under the conditions which the State requires, or can refrain from doing so. Nobody is forced to adopt a model of production, but if they wish to provide software to the State, they must provide the mechanisms which guarantee the basic principles, and which are those described in the Bill. By way of an example: nothing in the text of the Bill would prevent your company offering the State bodies an office "suite", under the conditions defined in the Bill and setting the price that you consider satisfactory. If you did not, it would not be due to restrictions imposed by the law, but to business decisions relative to the method of commercializing your products, decisions with which the State is not involved. To continue; you note that:" 2. The bill, by making the use of open source software compulsory, would establish discriminatory and non competitive practices in the contracting and purchasing by public bodies..." This statement is just a reiteration of the previous one, and so the response can be found above. However, let us concern ourselves for a moment with your comment regarding "non-competitive ... practices." Of course, in defining any kind of purchase, the buyer sets conditions which relate to the proposed use of the good or service. From the start, this excludes certain manufacturers from the possibility of competing, but does not exclude them "a priori", but rather based on a series of principles determined by the autonomous will of the purchaser, and so the process takes place in conformance with the law. And in the Bill it is established that *no one* is excluded from competing as far as he guarantees the fulfillment of the basic principles. Furthermore, the Bill *stimulates* competition, since it tends to generate a supply of software with better conditions of usability, and to better existing work, in a model of continuous improvement. On the other hand, the central aspect of competivity is the chance to provide better choices to the consumer. Now, it is impossible to ignore the fact that marketing does not play a neutral role when the product is offered on the market (since accepting the opposite would lead one to suppose that firms' expenses in marketing lack any sense), and that therefore a significant expense under this heading can influence the decisions of the purchaser. This influence of marketing is in large measure reduced by the bill that we are backing, since the choice within the framework proposed is based on the *technical merits* of the product and not on the effort put into commercialization by the producer; in this sense, competitiveness is increased, since the smallest software producer can compete on equal terms with the most powerful corporations. It is necessary to stress that there is no position more anti-competitive than that of the big software producers, which frequently abuse their dominant position, since in innumerable cases they propose as a solution to problems raised by users: "update your software to the new version" (at the user's expense, naturally); furthermore, it is common to find arbitrary cessation of technical help for products, which, in the provider's judgment alone, are "old"; and so, to receive any kind of technical assistance, the user finds himself forced to migrate to new versions (with non-trivial costs, especially as changes in hardware platform are often involved). And as the whole infrastructure is based on proprietary data formats, the user stays "trapped" in the need to continue using products from the same supplier, or to make the huge effort to change to another environment (probably also proprietary). You add: "3. So, by compelling the State to favor a business model based entirely on open source, the bill would only discourage the local and international manufacturing companies, which are the ones which really undertake important expenditures, create a significant number of direct and indirect jobs, as well as contributing to the GNP, as opposed to a model of open source software which tends to have an ever weaker economic impact, since it mainly creates jobs in the service sector." I do not agree with your statement. Partly because of what you yourself point out in paragraph 6 of your letter, regarding the relative weight of services in the context of software use. This contradiction alone would invalidate your position. The service model, adopted by a large number of companies in the software industry, is much larger in economic terms, and with a tendency to increase, than the licensing of programs. On the other hand, the private sector of the economy has the widest possible freedom to choose the economic model which best suits its interests, even if this freedom of choice is often obscured subliminally by the disproportionate expenditure on marketing by the producers of proprietary software. In addition, a reading of your opinion would lead to the conclusion that the State market is crucial and essential for the proprietary software industry, to such a point that the choice made by the State in this bill would completely eliminate the market for these firms. If that is true, we can deduce that the State must be subsidizing the proprietary software industry. In the unlikely event that this were true, the State would have the right to apply the subsidies in the area it considered of greatest social value; it is undeniable, in this improbable hypothesis, that if the State decided to subsidize software, it would have to do so choosing the free over the proprietary, considering its social effect and the rational use of taxpayers money. In respect of the jobs generated by proprietary software in countries like ours, these mainly concern technical tasks of little aggregate value; at the local level, the technicians who provide support for proprietary software produced by transnational companies do not have the possibility of fixing bugs, not necessarily for lack of technical capability or of talent, but because they do not have access to the source code to fix it. With free software one creates more technically qualified employment and a framework of free competence where success is only tied to the ability to offer good technical support and quality of service, one stimulates the market, and one increases the shared fund of knowledge, opening up alternatives to generate services of greater total value and a higher quality level, to the benefit of all involved: producers, service organizations, and consumers. It is a common phenomenon in developing countries that local software industries obtain the majority of their takings in the service sector, or in the creation of "ad hoc" software. Therefore, any negative impact that the application of the Bill might have in this sector will be more than compensated by a growth in demand for services (as long as these are carried out to high quality standards). If the transnational software companies decide not to compete under these new rules of the game, it is likely that they will undergo some decrease in takings in terms of payment for licenses; however, considering that these firms continue to allege that much of the software used by the State has been illegally copied, one can see that the impact will not be very serious. Certainly, in any case their fortune will be determined by market laws, changes in which cannot be avoided; many firms traditionally associated with proprietary software have already set out on the road (supported by copious expense) of providing services associated with free software, which shows that the models are not mutually exclusive. With this bill the State is deciding that it needs to preserve certain fundamental values. And it is deciding this based on its sovereign power, without affecting any of the constitutional guarantees. If these values could be guaranteed without having to choose a particular economic model, the effects of the law would be even more beneficial. In any case, it should be clear that the State does not choose an economic model; if it happens that there only exists one economic model capable of providing software which provides the basic guarantee of these principles, this is because of historical circumstances, not because of an arbitrary choice of a given model. Your letter continues: "4. The bill imposes the use of open source software without considering the dangers that this can bring from the point of view of security, guarantee, and possible violation of the intellectual property rights of third parties." Alluding in an abstract way to "the dangers this can bring", without specifically mentioning a single one of these supposed dangers, shows at the least some lack of knowledge of the topic. So, allow me to enlighten you on these points. On security: National security has already been mentioned in general terms in the initial discussion of the basic principles of the bill. In more specific terms, relative to the security of the software itself, it is well known that all software (whether proprietary or free) contains errors or "bugs" (in programmers' slang). But it is also well known that the bugs in free software are fewer, and are fixed much more quickly, than in proprietary software. It is not in vain that numerous public bodies responsible for the IT security of state systems in developed countries require the use of free software for the same conditions of security and efficiency. What is impossible to prove is that proprietary software is more secure than free, without the public and open inspection of the scientific community and users in general. This demonstration is impossible because the model of proprietary software itself prevents this analysis, so that any guarantee of security is based only on promises of good intentions (biased, by any reckoning) made by the producer itself, or its contractors. It should be remembered that in many cases, the licensing conditions include Non-Disclosure clauses which prevent the user from publicly revealing security flaws found in the licensed proprietary product. In respect of the guarantee: As you know perfectly well, or could find out by reading the "End User License Agreement" of the products you license, in the great majority of cases the guarantees are limited to replacement of the storage medium in case of defects, but in no case is compensation given for direct or indirect damages, loss of profits, etc... If as a result of a security bug in one of your products, not fixed in time by yourselves, an attacker managed to compromise crucial State systems, what guarantees, reparations and compensation would your company make in accordance with your licensing conditions? The guarantees of proprietary software, inasmuch as programs are delivered AS IS'', that is, in the state in which they are, with no additional responsibility of the provider in respect of function, in no way differ from those normal with free software. On Intellectual Property: Questions of intellectual property fall outside the scope of this bill, since they are covered by specific other laws. The model of free software in no way implies ignorance of these laws, and in fact the great majority of free software is covered by copyright. In reality, the inclusion of this question in your observations shows your confusion in respect of the legal framework in which free software is developed. The inclusion of the intellectual property of others in works claimed as one's own is not a practice that has been noted in the free software community; whereas, unfortunately, it has been in the area of proprietary software. As an example, the condemnation by the Commercial Court of Nanterre, France, on 27th September 2001 of Microsoft Corp. to a penalty of 3 million francs in damages and interest, for violation of intellectual property (piracy, to use the unfortunate term that your firm commonly uses in its publicity). You go on to say that: "The bill uses the concept of open source software incorrectly, since it does not necessarily imply that the software is free or of zero cost, and so arrives at mistaken conclusions regarding State savings, with no cost-benefit analysis to validate its position." This observation is wrong; in principle, freedom and lack of cost are orthogonal concepts: there is software which is proprietary and charged for (for example, MS Office), software which is proprietary and free of charge (MS Internet Explorer), software which is free and charged for (Red Hat, SuSE etc GNU/Linux distributions), software which is free and not charged for (Apache, Open Office, Mozilla), and even software which can be licensed in a range of combinations (MySQL). Certainly free software is not necessarily free of charge. And the text of the bill does not state that it has to be so, as you will have noted after reading it. The definitions included in the Bill state clearly *what* should be considered free software, at no point referring to freedom from charges. Although the possibility of savings in payments for proprietary software licenses are mentioned, the foundations of the bill clearly refer to the fundamental guarantees to be preserved and to the stimulus to local technological development. Given that a democratic State must support these principles, it has no other choice than to use software with publicly available source code, and to exchange information only in standard formats. If the State does not use software with these characteristics, it will be weakening basic republican principles. Luckily, free software also implies lower total costs; however, even given the hypothesis (easily disproved) that it was more expensive than proprietary software, the simple existence of an effective free software tool for a particular IT function would oblige the State to use it; not by command of this Bill, but because of the basic principles we enumerated at the start, and which arise from the very essence of the lawful democratic State. You continue: "6. It is wrong to think that Open Source Software is free of charge. Research by the Gartner Group (an important investigator of the technological market recognized at world level) has shown that the cost of purchase of software (operating system and applications) is only 8% of the total cost which firms and institutions take on for a rational and truly beneficial use of the technology. The other 92% consists of: installation costs, enabling, support, maintenance, administration, and down-time." This argument repeats that already given in paragraph 5 and partly contradicts paragraph 3. For the sake of brevity we refer to the comments on those paragraphs. However, allow me to point out that your conclusion is logically false: even if according to Gartner Group the cost of software is on average only 8% of the total cost of use, this does not in any way deny the existence of software which is free of charge, that is, with a licensing cost of zero. In addition, in this paragraph you correctly point out that the service components and losses due to down-time make up the largest part of the total cost of software use, which, as you will note, contradicts your statement regarding the small value of services suggested in paragraph 3. Now the use of free software contributes significantly to reduce the remaining life-cycle costs. This reduction in the costs of installation, support etc. can be noted in several areas: in the first place, the competitive service model of free software, support and maintenance for which can be freely contracted out to a range of suppliers competing on the grounds of quality and low cost. This is true for installation, enabling, and support, and in large part for maintenance. In the second place, due to the reproductive characteristics of the model, maintenance carried out for an application is easily replicable, without incurring large costs (that is, without paying more than once for the same thing) since modifications, if one wishes, can be incorporated in the common fund of knowledge. Thirdly, the huge costs caused by non-functioning software ("blue screens of death", malicious code such as virus, worms, and trojans, exceptions, general protection faults and other well-known problems) are reduced considerably by using more stable software; and it is well known that one of the most notable virtues of free software is its stability. You further state that: "7. One of the arguments behind the bill is the supposed freedom from costs of open-source software, compared with the costs of commercial software, without taking into account the fact that there exist types of volume licensing which can be highly advantageous for the State, as has happened in other countries." I have already pointed out that what is in question is not the cost of the software but the principles of freedom of information, accessibility, and security. These arguments have been covered extensively in the preceding paragraphs to which I would refer you. On the other hand, there certainly exist types of volume licensing (although unfortunately proprietary software does not satisfy the basic principles). But as you correctly pointed out in the immediately preceding paragraph of your letter, they only manage to reduce the impact of a component which makes up no more than 8% of the total. You continue: "8. In addition, the alternative adopted by the bill (I) is clearly more expensive, due to the high costs of software migration, and (II) puts at risk compatibility and interoperability of the IT platforms within the State, and between the State and the private sector, given the hundreds of versions of open source software on the market." Let us analyze your statement in two parts. Your first argument, that migration implies high costs, is in reality an argument in favor of the Bill. Because the more time goes by, the more difficult migration to another technology will become; and at the same time, the security risks associated with proprietary software will continue to increase. In this way, the use of proprietary systems and formats will make the State ever more dependent on specific suppliers. Once a policy of using free software has been established (which certainly, does imply some cost) then on the contrary migration from one system to another becomes very simple, since all data is stored in open formats. On the other hand, migration to an open software context implies no more costs than migration between two different proprietary software contexts, which invalidates your argument completely. The second argument refers to "problems in interoperability of the IT platforms within the State, and between the State and the private sector" This statement implies a certain lack of knowledge of the way in which free software is built, which does not maximize the dependence of the user on a particular platform, as normally happens in the realm of proprietary software. Even when there are multiple free software distributions, and numerous programs which can be used for the same function, interoperability is guaranteed as much by the use of standard formats, as required by the bill, as by the possibility of creating interoperable software given the availability of the source code. You then say that: "9. The majority of open source code does not offer adequate levels of service nor the guarantee from recognized manufacturers of high productivity on the part of the users, which has led various public organizations to retract their decision to go with an open source software solution and to use commercial software in its place." This observation is without foundation. In respect of the guarantee, your argument was rebutted in the response to paragraph 4. In respect of support services, it is possible to use free software without them (just as also happens with proprietary software), but anyone who does need them can obtain support separately, whether from local firms or from international corporations, again just as in the case of proprietary software. On the other hand, it would contribute greatly to our analysis if you could inform us about free software projects *established* in public bodies which have already been abandoned in favor of proprietary software. We know of a good number of cases where the opposite has taken place, but not know of any where what you describe has taken place. You continue by observing that: "10. The bill discourages the creativity of the Peruvian software industry, which invoices 40 million US$/year, exports 4 million US$ (10th in ranking among non-traditional exports, more than handicrafts) and is a source of highly qualified employment. With a law that encourages the use of open source, software programmers lose their intellectual property rights and their main source of payment." It is clear enough that nobody is forced to commercialize their code as free software. The only thing to take into account is that if it is not free software, it cannot be sold to the public sector. This is not in any case the main market for the national software industry. We covered some questions referring to the influence of the Bill on the generation of employment which would be both highly technically qualified and in better conditions for competition above, so it seems unnecessary to insist on this point. What follows in your statement is incorrect. On the one hand, no author of free software loses his intellectual property rights, unless he expressly wishes to place his work in the public domain. The free software movement has always been very respectful of intellectual property, and has generated widespread public recognition of its authors. Names like those of Richard Stallman, Linus Torvalds, Guido van Rossum, Larry Wall, Miguel de Icaza, Andrew Tridgell, Theo de Raadt, Andrea Arcangeli, Bruce Perens, Darren Reed, Alan Cox, Eric Raymond, and many others, are recognized world-wide for their contributions to the development of software that is used today by millions of people throughout the world. On the other hand, to say that the rewards for authors rights make up the main source of payment of Peruvian programmers is in any case a guess, in particular since there is no proof to this effect, nor a demonstration of how the use of free software by the State would influence these payments. You go on to say that: "11. Open source software, since it can be distributed without charge, does not allow the generation of income for its developers through exports. In this way, the multiplier effect of the sale of software to other countries is weakened, and so in turn is the growth of the industry, while Government rules ought on the contrary to stimulate local industry." This statement shows once again complete ignorance of the mechanisms of and market for free software. It tries to claim that the market of sale of non- exclusive rights for use (sale of licenses) is the only possible one for the software industry, when you yourself pointed out several paragraphs above that it is not even the most important one. The incentives that the bill offers for the growth of a supply of better qualified professionals, together with the increase in experience that working on a large scale with free software within the State will bring for Peruvian technicians, will place them in a highly competitive position to offer their services abroad. You then state that: "12. In the Forum, the use of open source software in education was discussed, without mentioning the complete collapse of this initiative in a country like Mexico, where precisely the State employees who founded the project now state that open source software did not make it possible to offer a learning experience to pupils in the schools, did not take into account the capability at a national level to give adequate support to the platform, and that the software did not and does not allow for the levels of platform integration that now exist in schools." In fact Mexico has gone into reverse with the Red Escolar (Schools Network) project. This is due precisely to the fact that the driving forces behind the Mexican project used license costs as their main argument, instead of the other reasons specified in our project, which are far more essential. Because of this conceptual mistake, and as a result of the lack of effective support from the SEP (Secretary of State for Public Education), the assumption was made that to implant free software in schools it would be enough to drop their software budget and send them a CD ROM with Gnu/Linux instead. Of course this failed, and it couldn't have been otherwise, just as school laboratories fail when they use proprietary software and have no budget for implementation and maintenance. That's exactly why our bill is not limited to making the use of free software mandatory, but recognizes the need to create a viable migration plan, in which the State undertakes the technical transition in an orderly way in order to then enjoy the advantages of free software. You end with a rhetorical question: "13. If open source software satisfies all the requirements of State bodies, why do you need a law to adopt it? Shouldn't it be the market which decides freely which products give most benefits or value?" We agree that in the private sector of the economy, it must be the market that decides which products to use, and no state interference is permissible there. However, in the case of the public sector, the reasoning is not the same: as we have already established, the state archives, handles, and transmits information which does not belong to it, but which is entrusted to it by citizens, who have no alternative under the rule of law. As a counterpart to this legal requirement, the State must take extreme measures to safeguard the integrity, confidentiality, and accessibility of this information. The use of proprietary software raises serious doubts as to whether these requirements can be fulfilled, lacks conclusive evidence in this respect, and so is not suitable for use in the public sector. The need for a law is based, firstly, on the realization of the fundamental principles listed above in the specific area of software; secondly, on the fact that the State is not an ideal homogeneous entity, but made up of multiple bodies with varying degrees of autonomy in decision making. Given that it is inappropriate to use proprietary software, the fact of establishing these rules in law will prevent the personal discretion of any state employee from putting at risk the information which belongs to citizens. And above all, because it constitutes an up-to-date reaffirmation in relation to the means of management and communication of information used today, it is based on the republican principle of openness to the public. In conformance with this universally accepted principle, the citizen has the right to know all information held by the State and not covered by well- founded declarations of secrecy based on law. Now, software deals with information and is itself information. Information in a special form, capable of being interpreted by a machine in order to execute actions, but crucial information all the same because the citizen has a legitimate right to know, for example, how his vote is computed or his taxes calculated. And for that he must have free access to the source code and be able to prove to his satisfaction the programs used for electoral computations or calculation of his taxes. I wish you the greatest respect, and would like to repeat that my office will always be open for you to expound your point of view to whatever level of detail you consider suitable. Cordially,
DR. EDGAR DAVID VILLANUEVA NU EZ
Congressman of the Republic of Per .

LWN has an article by Valerie Aurora titled The dark side of open source conferences [1] which is about sexual harassment and sexual assault at Free Software conferences. Apparently some conferences create such a bad environment that some people won t attend, it s a well researched article that everyone in the community should read.The Autism DerailmentThe comments have the usual mix of insight, foolishness, and derailment that you expect from such discussions. One derailment thread that annoyed me is the discussion about men on the Autism Spectrum started by Joe Buck [2]. Joe seems to believe that the 1% of males on the Autism Spectrum (and something greater than 1% but a lot less than 50% in the Free Software community) are a serious part of the problem because they supposedly hit on women who aren t interested in them in spite of the fact that the article in question is about women who are being insulted, harassed, and groped at at open source conferences . The article had no mention of men who try to chat up women presumably this was a deliberate decision to focus on sexual assault and harassment rather than what Joe wanted to talk about.In response Mackenzie made the following insightful point:I don t think any autistic person who is high-functioning enough to A) contribute to open source B) want to be at an event with so many people and C) carry on any sort of conversation is low-functioning enough not to understand stop or no. If you can understand your patch has been rejected, you can likely understand don t do that again. Understanding how Other People FeelBruce Perens claimed What they [Aspies] don t understand is how the other person in the situation feels . Like many (possibly most) people Bruce doesn t seem to get the fact that no-one can really understand how other people feel. The best logical analysis of this seems to be the Changing Emotions article on Less Wrong [3]. While Less Wrong deals with Male to Female conversion as the example (which may be relevant to the discussion about the treatment of women) the same logic also applies to smaller changes. Anyone who even thinks that if they would always be able understand how their identical twin felt (if they had one) probably hasn t considered these issues much. As an aside, having a psychologist diagnose you as being on the Autism Spectrum and therefore by implication thinking differently to 99% of the population really makes you consider the ways in which other people might have different thought processes and experiences.Every time we have a discussion about issues related to sexism in the Free Software community we get a lot of documented evidence that there are many people who are apparently neuro-typical (IE not Autistic) who don t understand how other people think in many cases they go so far as to tell other people what their emotional state should be.What Really HappensNix said However, in that situation our natural reflex is to *get out of there*, not to jump on women like some sort of slobbering caveman which is a really good summary.In more detail, I think that the vast majority of guys who are on the Autism Spectrum and who are able to do things like attend computer conferences (*) realise that chatting up a random girl that they meet is something that just isn t going to work out. Generally people don t attempt things that they expect to fail so I don t think that Autistic guys are going to be hitting on girls at conferences.(*) Having never met any Autistic people who aren t capable of attending such conferences I can t speak for them. I really doubt that the Low Functioning Autistic guys are as much of a problem as some people claim, but lack evidence. In any case the actions of people who don t attend conferences aren t relevant to a discussion about things that happen at conferences.Update: It Keeps GoingDion claims that the misogyny at conferences is due to socially inept people, he also casually switches between discussing people who misunderstand when someone is flirting and people who hire almost-naked booth-babes (two very different classes of action) [4]. Several people asked for supporting evidence, naturally none was provided.In response njs posted a link to Marissa Lingen s blog post Don t blame autism, dammit [5]. Marissa points out that people who offend other people due to lacking social skills will tend to do so in times and places that are likely to get a bad reaction if you don t know that you are doing something wrong then there s no reason to hide it. If someone offends a senior manager at a corporate event then it could be because they are on the Autism Spectrum (I ve apparently done that). If someone offends junior people at a times and places where there are no witnesses but is always nice to managers and other powerful people then it s not related to Autism.One final note, I have little tolerance for anyone who claims to be an Aspie when they do something wrong. You are either on the Autism Spectrum all the time or none of it. Anyone who wants any sympathy for me for an occasion where they stuffed up due to being an Aspie can start by making a clear statement about where they are on the Autism Spectrum.Update2: Yet More from Bruce PerensBruce wrote IMO, the kind of men who go in to software engineering suffer a lack of healthy interaction with women who are their peers, and it may be that the high incidence of empathy disorders in our field is involved (which seems to be part of the inspiration for Joe Buck later in that thread) and now claims Nobody here was trying to connect Asperger s or autism with the touching incidents or violent crime .Matthew Garrett responded to that with If you weren t trying to say that the high incidence of empathy disorders in our field was related to a lack of healthy interaction with women who are their peers, and that that has something to do with incidents of sexual harassment or assault at conferences, what were you trying to say? Because that sounds awfully like We wouldn t have so many problems if it weren t for all the autists .Bruce s latest comment is If you choose to read something that nasty into my writing, that s your problem. Get therapy .Through this discussion I ve been unsure of whether to interpret the statements by Bruce et al the way Matthew does or whether I should consider them as merely a desperate attempt to derail the discussion. I can t imagine any possible way of interpreting such comments in connection with the discussion of sexual assault as anything other than either trivialising violent crimes against women (suggesting that they are no worse than asking out someone who s not interested) or claiming that anyone who lacks social skills should be treated as a violent sexual predator. It s just not reasonable to believe that every single person who wrote such comments referring to Autism was misunderstood and really meant something nice.As a general rule I don t think that it s the responsibility of other people to try and find a non-offensive interpretation of something that one might say. I don t think that all the people who strongly disagree with the most obvious and reasonable interpretations of Bruce s comments should get therapy. I think that Bruce should explain what he means clearly.

• [1] http://lwn.net/Articles/417952/
• [2] http://lwn.net/Articles/418209/
• [3] http://lesswrong.com/lw/xe/changing_emotions/
• [4] http://lwn.net/Articles/418281/
• [5] http://mrissa.livejournal.com/746160.html

The monthly IRC board meeting of Software in the Public Interest will take place later today, as announced by SPI’s secretary last week. While the announcement is back on time (yay!), the agenda isn’t (aww!). I’d be quite interested to learn how SPI is going to try to reduce the risk to its reserves, given the current slow decline of its primary bank which is not one of the first US banks getting bailed out. I think the best way for not-for-profits to avoid risking donations at the moment is to avoid having them in their bank accounts, in line with the Better Business Bureau standard that

“the charity’s unrestricted net assets available for use should not be more than three times the size of the past year’s expenses or three times the size of the current year’s budget, whichever is higher.”

Back in June 2005, SPI’s board of the time (Ian Jackson, John Goerzen, Jimmy Kaplowitz, David Graham, Bruce Perens, Benj. Mako Hill, Branden Robinson) decided to “remain noncompliant” with that standard and I fear that chicken could be coming home to roost now. I hope we don’t lose anything, but AIUI we’ve got nearly $150,000 in play. Update: Unlike its UK analogue, the Federal Deposit Insurance Corporation covers corporation accounts up to $250,000, so SPI is only risking temporary unavailability, not yet a risk of loss. Thanks to bd_ for pointing me to that.

From the official press release:

April 3, 2008 - The Swiss Open Systems User Group /ch/open organizes the first international Hackontest sponsored by Google as part of informatica08, the Swiss year of computer science 2008. Hackontest is a 24-hour programming competition of three teams of different open source projects. Its goals are to enhance popular Free Software projects according to user needs and to demonstrate to the public how enthusiastically open source software is being developed. Starting in April 2008 users and developers of open source software may submit feature requests for their favorite Free Software projects and rate and comment them. On Swiss national holiday August 1st, 2008 the Hackontest jury will pick the three most promising teams. They may travel to Switzerland on September 24/25, 2008 to participate in the competition located at the OpenExpo Z rich 2008. The jury is staffed of ten highly renowned open source hackers such as Jeremy Alison (founder of Samba), Bruce Perens (founder of the Open Source Initiative), Alexander Limi (founder of Plone), Harald Welte (founder of gpl-violations.org) and Jono Bacon (Ubuntu community leader). The Hackontest platform and further information about the event is located at www.hackontest.org.

I have been asked to serve on the jury. This sounds like it ll be a fun and interesting event, and if not only I finally get to meet Alexander Limi, with whom I ve worked on Plone, and Bram Moolenaar, author of the best editor around. Now, Debian! Let s get some proposals in! NP: The Good, the Bad & the Queen: The Good, the Bad & the Queen

So, sometime over the past few weeks I clocked up ten years as a Debian developer:

From: Anthony Towns <aj@humbug.org.au>
Subject: Wannabe maintainer.
Date: Sun, 8 Feb 1998 18:35:28 +1000 (EST)
To: new-maintainer@debian.org
Hello world,
I'd like to become a debian maintainer.
I'd like an account on master, and for it to be subscribed to the
debian-private list.
My preferred login on master would have been aj, but as that's taken
ajt or atowns would be great.
I've run a debian system at home for half a year, and a system at work
for about two months. I've run Linux for two and a half years at home,
two years at work. I've been active in my local linux users' group for
just over a year. I've written a few programs, and am part way through
packaging the distributed.net personal proxy for Debian (pending
approval for non-free distribution from distributed.net).
I've read the Debian Social Contract.
My PGP public key is attached, and also available as
<http://azure.humbug.org.au/~aj/aj_key.asc>.
If there's anything more you need to know, please email me.
Thanks in advance.
Cheers,
aj
-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.
On Netscape GPLing their browser:  How can you trust a browser that
ANYONE can hack? For the secure choice, choose Microsoft.''
        -- <oryx@pobox.com> in a comment on slashdot.org

Apparently that also means I’ve clocked up ten and a half years as a Debian user; I think my previous two years of Linux (mid-95 to mid-97) were split between Slackware and Red Hat, though I couldn’t say for sure at this point. There’s already been a few other grand ten-year reviews, such as Joey Hess’s twenty-part serial, or LWN’s week-by-week review, or ONLamp’s interview with Bruce Perens, Eric Raymond and Michael Tiemann on ten years of “open source”. I don’t think I’m going to try matching that sort of depth though, so here are some of my highlights (after the break).

---

• Starting small: my first package was distributed-net-pproxy, which would claim a bunch of work units which could then be distributed over the local LAN. Useful if you’re in Australia in the mid-90s and being charged by the minute for Internet access. distributed.net didn’t allow general distribution, so I asked for (and received) explicit permission to include it in Debian. (distributed.net had a ten year anniversary last year too)
• Diving straight in: I got sucked in to the mailing lists pretty quickly, and within a couple of months was up to my neck trying to redesign the way we did releases; oddly enough that didn’t turn out quite so easy, but at least it ended up with some concrete proposals within a couple of months, pretty much synchronously with the hamm (2.0) release going out (and, I guess, about a year after I’d started using Debian…). At around the same time was, I think, my first recorded comment about trade offs regarding freeness…
• cruft: My first bit of Debian specific code was cruft (that its name, not it’s value…), which worked okay as a prototype, but got snagged up in debian-policy trying to get packages to make a note of files they’ll put on the system without telling dpkg (eg, /etc/passwd, /var/cache/apt/archives/*.deb, etc). That pretty much sapped my interest in it, and cruft stagnated until Marcin Owsiany picked it up in 2005.
• Played for a sucker, part one: a few months later I was messing around doing QA stuff and fixing bugs and as part of that did an NMU of netbase (which at the time directly contained all sorts of important tools like ping and inetd directly). That went something like:

  From: Anthony Towns
  Date: Sat, Nov 21, 1998
  There are a few bugs accumulating against the netbase package which
  you're maintaining. I was wondering if you'd mind if I made an NMU
  to fix some of them for the upcoming slink release?
  

  From: Peter Tobias
  Date: Sat, Nov 21, 1998
  No, please go ahead ... I'm quite busy right now and I would really
  appreciate any help. Please let me know if you need additional information
  about the package.
  

  From: Anthony Towns
  Date: Sun, Dec 6, 1998
  There's an NMU sitting in Incoming now. It fixes a few bugs, viz:
  [...]
  

  From: Peter Tobias
  Date: Fri, Dec 25, 1998
  due to my current job I don't have much time to work on my debian
  packages. In order to have more time for my other debian packages
  I would like to give away the netbase package. Are you interested
  in maintaining this package?
  

  From: Anthony Towns
  Date: Fri, Dec 25, 1998
  Ummm. Sure. I guess. (or, iow, *Eeeeeeeeeeeeek*!!!)
  
  

• ifupdown: As part of maintaining netbase I tried to figure out a way of fixing bugs like 31745 and 39118. Basically, Debian used to do networking by generating a script on install that you could modify by hand, and that was it – so when the commands needed changed between 2.0 and 2.2 (no more “route add -net”), you couldn’t make that upgrade “just work”. Red Hat handled it with “ifup” and “ifdown” commands that would look at a whole bunch of shell-format variables in /etc, which worked but wasn’t elegant, so I came up with something I thought was actually pleasant. It’s fundamental attitude is to be a parser – the networking commands are specifed as compile-time configuration, the description of your network is your runtime configuration, and ifupdown just puts those all together without trying to actually understand what’s going on. To some degree, that works really well – it keeps all the knowledge separate so when you’re writing an /etc/network/interfaces, you’re not worried about how DHCP works; in others it breaks down – in particular if bringing up an interface fails part way through, is it up, or down, or something else entirely?
• bugs.debian.org: I’m not entirely sure why, but in August ‘99 I decided to start running a script to stop old bugs from being permanently deleted:

  From: Anthony Towns
  Subject: BTS and old bugs
  Date: Tue, 24 Aug 1999 22:33:16 +1000
  To: debian-private@lists.debian.org
  ObPrivate: Erm. I'm not sure. It is only even vaguely relevant to
  developers.
  Since bugs #9705 and #36727 don't seem like being fixed any time soon
  and Darren hasn't managed to convert the BTS to using debbugs.deb yet,
  I've made a little script to stop us from continuing to lose bug
  reports, and am running it in my crontab on master.
  ~ajt/debian-bugs/archive/ contains hardlinked copies of the bugs in
  ~iwj/debian-bugs/spool/db (except split into sub-directories). When
  the bugs get expired from the BTS, the hardlink in ~ajt remains, so
  the file doesn't get lost forever.
  In the week or so I've been running it, some 500 odd bugs expired [0].
  

  Next month I sent Darren Benham a first version of bugreport.cgi, and at some point around then must’ve sent off a pkreport.cgi too; by the month after (October) I’d evidently been added to the debbugs group, because I was merging my archived bugs into the official debbugs directories.
• testing: So a year and a bit later and there had been some more discussions about making major changes to our release process, and since I’d done some more algorithms subjects at university by this point, dove in a bit more seriously. For me, the main challenge seemed to be keeping dependencies consistent, and it turns out validating dependencies and conflicts is an NP-complete problem, and solving that reasonably efficiently seemed like a good first step. By October ‘99 I’d come up with a first pass solution, which I think was still in Perl at the time. A couple more rounds of playing with consistency checking stuff ensued, resulting in some regularly updated lists being generated by December, and by March 2000 or so that had graduated to a simulation of testing as we know and love it today.
• Played for a sucker, part two: so after a few months of maintaining a testing suite while potato (Debian 2.2) was getting finalised for release I figured it’d be useful to get broader release experience, so asked Richard Braakman if I could help out with the last bits of the potato release. At which point he said “sure”, gave me James Troup’s email address for accepting/rejecting packages etc, then buzzed off to a mobile phone related junket in the US, and laid low until the release was actually out… A cunning plan, for sure. Happily, that didn’t take too long – I think I started around June, and potato was finished baking for release at LinuxWorld Expo in August, though it did involve about 2000 lines of archive changes and stuff mailed to James over the period, along with half a dozen mails to -devel-announce.
• Junket: In the middle of that was my first ever debconf – or technically the Debian portion of the 2000 LSM/RMLL in Bordeaux, aka Debconf 0. It was awesome – met heaps of cool people, got to practice my high school French, and enjoy some lovely red wine while gossipping about free software. Also heard RMS sing the free software song live. But the wine was great!
• katie/dak: The biggest problem with the “simulation of testing” mentioned above was it was held together with paperclips and sticky-tape; or less metaphorically, shell one-liners and hardlinks. Since packages would originally get uploaded to unstable, and then move into testing, and then get deleted from unstable, you’d end up at least doubling the bandwidth required to mirror Debian, because each package would get sent to mirrors once for unstable and once for testing. Which is fine for a simulation, but for deployment, well, we needed package pools, which in turned required a rewrite of dinstall. James did all the initial work, apart from some of the schema design and the scarier SQL, and by November had it deployed for the non-US archive, and got it onto ftp-master in December. At which point the time was ripe for hooking up testing into the archive proper, which is about the point that the testing scripts got named “britney” so as to fit in with all silly names in the da-katie suite. I’m pretty sure the rationale was that I did the final coordination of the potato release (archive changes, cd images, announcement, etc), I spent from about 3am to 10am listening to a handful of Britney Spears songs on repeat. The phrase “scarred for life” might come to mind. Since that point, there’s been lots of evolutionary changes to both dak and testing (including a rewrite of the perl parts of testing into python), but it’s all built fairly naturally from that point.
• debootstrap: I’m pretty sure my motivation for writing debootstrap was a mix of just wanting to avoid having to worry about out of date base tarballs for the purposes of keeping testing in-sync, and wondering if it was actually possible to write a script to bootstrap a Debian system from the sort of minimally functioanl environment the installer has to put up with. In the end, it turned out pretty cool – it was used by the final boot-floppies, it’s part of d-i, it makes tools like pbuilder possible, I think it helps embedded folks heaps, it’s spawned some imitators, and generally been a pretty cool exercise in hackery.
• Freedom and purity: About six months earlier, there was a big flamewar and an attempted vote on whether to remove non-free from the archive. I’d written a rebuttal and counter-proposal, but it all ended up collapsing in a heap, due to disputes about the constitution. For some reason I feel like this mail was more interesting than all the previous ones combined… That ended up needing a whole bunch of changes to the constitution: one to make it clear under what circumstances the social contract can be changed, and another on what happens when one option on a vote requires a supermajority while another doesn’t, and working that out ended up taking from October 2000 until October 2003. It was actually kind-of interesting; trying to analyse a good voting system that works in the real world has all sorts of interesting maths to it, and there’s a whole bunch of election methods guys that have studied it in a bunch of depth. And since its elections, you can have fun with all sorts of scenarious of corruption – like what if the secretary’s trying to change the results. In practice, the difference between good and bad election methods seems to turn out to be negligible, but why wouldn’t you have the best one you possibly can? A couple of months after those changes were done, dropping non-free got reproposed, and I did another counter-proposal; this time they were actually voted on, with the counter-proposal winning, by a little under a two-to-one margin. Which means we get to get rid of non-free by making it completely superfluous, rather than just near enough.

Hrm, this is going on longer than I’d hoped. Oh well, to be continued!

An article by Sam Varghese appeared on ITwire today, entitled linux.conf.au: What is Novell doing here?:

A GNU/Linux system does not normally load modules that are not released under an approved licence. So why should Australia’s national Linux conference take on board a sponsor who engages in practices that are at odds with the community? What am I talking about? A company which should not be in the picture has poked its nose in as a sponsor. Novell, which indicated the level of its commitment to FOSS by signing a deal with Microsoft in November 2006, will be one of the supporting sponsors for the conference.

Novell was also a minor sponsor of the 2007 conference, and Sam wrote an article in January expressing similar thoughts, which included this quote from Bruce Perens:

“I’d rather they hadn’t accepted a Novell sponsorship. It wasn’t very clueful of them, given Novell’s recent collaboration with Microsoft in spreading fear and doubt about Linux and software patents,” Perens said.

Ultimately, I think that’s a mistaken view. Linux.conf.au is what it is thanks to the contributions of four groups:

the organisers

who create the conference, get a venue, organise a schedule of events, help the speakers and attendees to get there, and generally make it easy for everyone to just get immersed in cool Linux stuff

the speakers

who provide the core of the schedule, the reason for attendees to go, and a core depth of awesome technical knowledge and ideas

the attendees

who fill in the organisational/content gaps that the organisers and speakers miss, who make for fascinating corridor and dinner conversations, who make side events like the miniconfs, the hackfest or open day interesting, and who pay the rego fees that lets the conference happen

the sponsors

who provide a chunk of money to fill out the conference budget letting us commit to venues and events earlier (when we might otherwise have to wait to see how many people come), and let us do extra things that registration fees alone wouldn’t cover

Obviously sometimes you have to exclude people from participating, but that’s mostly only if they’re actually causing trouble for the event. For sponsors, that pretty much means trying to interfere in the conference itself, or not paying on time. Otherwise, if you’re contributing to the conference, and not causing problems, you certainly should be recognised for that, as far as I can see. For me, the same thing would apply if Microsoft was offering to sponsor the conference – if they’re willing to contribute, and not cause problems, I’m all for it. If they happen to not be doing anything constructive in Linux-space anywhere else, well, it seems perfectly fine to me to start contributing by helping make linux.conf.au awesome. In Microsoft’s case that would be hard, because all the people going “oh my gosh, Microsoft, Linux! Wolves, sheeps! Hell, snow!” along with possible mixed messages from Microsoft and our long-term major sponsors HP and IBM about the future of Linux and whatnot could really distract us from all the cool technical stuff the conference is fundamentally about. I don’t think there’s anything Microsoft could offer to justify that much disruption, but having more of the world’s software companies involved in free software would probably be worth a bit of hassle, if the disruption could be minimised. Ultimately, I guess my disagreement comes down to these couple of comments from Sam’s article:

Asked whether it was right that Novell should be allowed to be a sponsor for a conference such as this - which, in my view, is a privilege - […] […] Novell, obviously, is hoping that, as public memory is woefully short, it will be able to wriggle its way back into the community. Providing such leeway is, in my opinion, a big mistake.

In my opinion, the ability to contribute to open source isn’t a privelege, it’s something that should be open to everyone, including people who’ve made mistakes in the past: and that’s precisely what the “free” in free software is all about. OTOH, if you want to see who’s been participating most in the Linux world lately, you’re much better off looking at the list of speakers than sponsors. Novell (or at least SuSE) folks giving talks in the main conference this year seem to include John Johansen and Nick Piggin. Interestingly, the count of HP folks seems a bit low this year, with only two that I can see, which leaves them not only merely equalling Novell/SuSE, but beaten by both Intel and Catalyst. Tsk! I guess we’ll have to wait and see if that changes when we can see the list of attendees’ companies in the booklet this year…

The Open Source Iniciative (OSI) has approved two Microsoft license submissions: The Microsoft Public License (Ms-PL) and the Microsoft Reciprocal License (Ms-RL). The Open Source Definition was written after Debian Free Software Guidelines, also by Bruce Perens, and they have a lot in common. What is Hasefroch pretending with this movement? It’s not that I trust them too much, so I just don’t think they won’t have a hidden intention, but then again, they might not have it this time, who knows. It might be just a marketing show, having two OSI approved licenses, but not using them to release any significant code, or maybe they’re discovering that Open Source/Free and Proprietary Software are not exclusive and each of them might have its space. Or maybe… it was “Embrace, extend and extinguish“, wasn’t it? I’ve had a look at the licenses, and apart from some patent-related provisions, I don’t see anything in them that could make them non-DFSG-free, anyway. The difference between them is that the Microsoft Reciprocal License (Ms-RL) has a clause stating that you should release your modifications under the same license. Lets see what the future provides.

I'm not sure of the exact date - if my memory serves me correctly, it was sometime during the summer of 1997 - I was given an account on Debian's server (located, at the time, in Beaverton, Oregon). I didn't go on to upload my first package until October of that year, as I had landed my first programming job at the same time, at CKS Partners. The "new maintainer process" in those days consisted of Klee Dienes calling me up and checking that I was a real person, had a pgp key, and wasn't completely clueless. It was a very different project in many ways than it is today - much smaller, much more informal, and of course much less well known in the world at large. Some elements were in place, though - my recollection is that the "flame friendly" atmosphere, while perhaps not quite as accentuated as it at times appears today, was firmly in place even back then. In '98, '99', and 2000, the Linux world was an exciting place to be. I still recall reading about the database companies deciding to release their products on Linux, reading The Cathedral and the Bazaar, and going to one of the first big commercial Linux conferences, in San Jose, in early 1999. Debian was well poised to take advantage of Linux's growth, too. Under Bruce Perens' leadership, several key elements of Debian had been put in place, like the social contract and free software guidelines. Fortuitously, Jason Gunthorpe was working on apt in that time period as well, which was another key element in Debian's success. One of the things I've always admired about Debian in the open source world is that it is in some ways a "stepping stone" project, meaning that it's a good way for people to start getting involved with free software, to get their toes wet "giving something back", without already being an expert hacker. It's easier to maintain a package of code, if you're willing to put in the time and attention to details, than to, say, write a new kernel module, or some other piece of critical C code. I've seen a number of people take this route - they get started with Debian, and as they go, learn more about the packages they work with, and perhaps even get involved with them "upstream", as they acquire skills and knowledge. By no means is everyone in Debian in that situation, though - there are some really first rate hackers, who tend to be the small core of people that really make Debian zing along. Indeed, being an autodidact in the world of computers, outside of one very forgettable term of C++ at Lane Community College, has given me an immense appreciation for the enormous opportunities open source affords in terms of learning - and especially hands-on learning. How many other fields let you work from anywhere in the world with an internet connection, with anyone else who is interested in the same subject, at whatever time you want, with tools that you can download entirely for free? It's really an intoxicating sensation realizing that you can do anything you want if you are willing to put the time in to learn how. The learning opportunities are one of the many things I'm grateful to Debian for. These days, I'm really not involved much with Debian anymore. I mostly run Ubuntu, which I think has perhaps improved on some of the social aspects of Debian (although Mark's zillions of dollars certainly play a large role, too). In terms of free software, I don't have as much time, and dedicate more of it to my own projects like Hecl. I still love the idea of open source software, but I'm also older and wiser (or more cynical?), and must face the reality that without scarcity, you have nothing to trade with others for things like food. Due to my lack of activity, perhaps I should resign, but ... I really don't want to, and who knows, maybe I'll have more time, and an "itch to scratch" at some point in the future. Who knows what the next ten years hold for Debian?

If you would like to show your displeasure at the recent Novell-Microsoft stitch-up, you could let Bruce Perens's petition speak for you or Boycott Novell (and yes boycotts work but maybe not how you think).

Regular viewers may have noticed a reduced frequency of updates lately. This is due to unfortunate circumstances.

But anyway.

Fed up with Bruce Perens claiming to speak on your behalf? Object that someone who hasn't written any useful code in approximately forever wants to class you as being in the same category of people as him? Think it's a bit off for him to claim random things about the meaning of the GPL? Irritated that there's no way to make this clear to journalists?

Now there's a solution!

Visit Bruce Perens does not speak for me and let the world know that when Bruce says that the Open Source community is fighting the same sort of battle that Martin Luther King did, you'd rather not be included.

The day that Bruce Perens gets to tell me that Novell is the new SCO is the day that I willingly accept an offer to be sodomised with a pneumatic drill.

Novell have contributed more code to Linux than pretty much any other single commercial entity other than Red Hat. Without the Novell kernel developers, Linux would be in a much worse state than it currently is. However, I'd expect that everyone in Novell knows that they're also entirely dependent upon the developers working for other distributions. Killing every other distribution isn't advantageous to Novell. And, perhaps more importantly, the death of Novell would be a (short-term?) disaster for every other distribution. Debian may have a larger market share than Novell, but if Novell dies then that's going to be a share of a very small market.

The Linux community doesn't need to eat its own. And one very basic fact does still remain - if Microsoft couldn't sue you before, they still can't sue you. If you're legal, nothing Novell can do will alter that.

(It's sort of touching that Bruce has time to comment on this sort of thing, but didn't seem to find time to make Linuxworldexpocontinentconferencecountymeeting last month. Thanks, Bruce. Thruce. But hey, you're in the credits for A Bug's Life and Toy Story II!)

Bruce Perens pointed out some implications of the deal. This is like the Microsoft-SCO dealings in reverse: Microsoft threatens Linux vendors with patent lawsuits and Novell is the first to buy protection. If you think this sounds like conspiracy theory, see what Ballmer has to say. Microsoft presumably hopes to force Linux into a conventional pay-per-seat business model, because it's a master of that game. Look at who the press release quotes as acclaiming the deal and remember that these sponsors of Linux and free software are not our friends. They sponsor free software so long as they think it's good for business. We shouldn't expect loyalty from public corporations, nor give it to them. From the same press release, I quote:

Novell will also make running royalty payments based on a percentage of its revenues from open source products.

If you are a copyright holder of software that Novell receives and distributes under GPLv2, please ask them whether they have obtained a patent license covering your work, and if so, how they intend to comply with section 7.

I've been doing Debian for 10 years, as of this month. I reckon that's a good excuse for some ponderings... For a long time in college in Cambridge, I was a Slackware user and supporter. It was my first distribution, installed in May 1994. I sent patches to Pat for bugs that I'd found, and I helped several of my friends in college maintain their machines running Slackware too. But after a couple of years of that, I grew tired of spending more time maintaining the OS on my machine than actually using it; I had even gone through the trials of the transition to ELF by hand. Some friendly pushing by my friend Jon Rabone (at the time also a DD) was finally enough, and one weekend in October 1996 we sat down together and started to install Debian on my PC. That first installation was a nightmare! It was a major struggle, and more than one time that weekend I threatened to go back to the comfortable security of Slackware. The installer was awful, and needed lots of hand-holding. Eventually, however, we got there. hammer.chu.cam.ac.uk became a Debian machine, and most of it worked. By the end of that Sunday, I was convinced to stay with it. Next, I decided that I wanted to contribute. The NM process in 1996 was quite simple - I mailed Bruce Perens with my PGP public key and asked him for an account. The package I wanted to maintain was mikmod. At the time I was one of the upstream developers, and I wanted to make sure it worked well in Debian. Unfortunately, I had already been beaten to it - Joey Hess had already packaged it in the few days since I first started work. Some things never change... :-) I mailed Joey and took over the package, then I started looking for other things to help with. I had long been annoyed that my Slackware patches had never met with any response, so Debian seemed ideal for me - a place where I could make a difference directly. Over the following years, I took on, worked on and passed on lots of packages. At one point, I was maintaining lots of audio programs. At another I worked on lots of archiving and compression programs. Then I moved onto the debian-cd team. Debian was excellent fun: I got to use a great, stable operating system and I got to work on it and help make it better! It hasn't all been plain sailing - there have been plenty of times when I've become disillusioned with things. There have been times when I've spent an entire night or weekend hacking on things and felt unhappy that either I hadn't made any progress or (even worse) my effort wasn't appreciated. There have been times when I've gone without sleep to get a package fixed or a CD build done, because I felt it mattered. To offset that, there have been great moments: going along to Linux Expos and meeting users of my packages who wanted to say thanks and buy me beer; travelling around the world, meeting up with DDs and chewing the fat; playing Mao in the middle of the night at Debconf; most especially the feeling of achievement when my^Wour work is done and we manage to finish a release. Oh, and that first installation? It's still around, almost ten years later. It has moved onto different hardware more times than I can remember, but I've continued upgrading it regularly ever since. It was once my only computer, but now it's one of many. hammer became sledge, then jack. It's now the machine that holds my Debian mirror and serves files to the rest of my home network. That's what I call upgradeability! It's a story that I tell people at Expos, and every year it gets more impressive... :-)

Being an inveterate domain-name registerer, I've got a lot of domains sitting around doing nothing. I've only recently stumbled across Bruce Perens's Open Source Parking site. It's a clever idea -- transferring those parked domains on GoDaddy and other registrars to a page with ads for FOSS projects. tags: bruce perens open source parking domain registration godaddy

Adieu John Our friend John Usher bugged out to wt:Banff today. He's off to the Banff Centre to finish up the research he did on his Ph.D. and do some more work on goofy, crazy audio projects in the healthsome mountain air. According to John, it's really nice at the Centre, but if you go outside you have to clap all the time to keep grizzly bears away. I'm not sure if that's for real or just a prank that the locals play on visiting scientists. John's been here a few weeks -- it was really good to have him. Our apartment is just a bit too big, and I've enjoyed the space most when we have a friend or relative staying in the guest bedroom. I think in the year or so that we've lived here it's been occupied about 30-40% of the time. I know Amita June will miss having Mononc John around. They get along really well, and I was hoping that AJ would pick up some UK turns of phrase like "tickety-boo" and "manky". I'm particularly charmed by the English use of the word "cheers", which seems to be analogous to the way like Hawaiians use "aloha"; it means hello, good bye, thank you, and Mmmm! Beer!. A fine word used by fine people. tags: john usher cheers visitors banff centre

Postfix fix Over the last few days I've been tightening down on the amount of spam I get in my Inbox by trying to cut it off at the MTA (mail server) level. I have a lot of different email addresses, and I use a mix of mail forwarding and multiple IMAP or POP3 inboxes to bring everything together into one nice little bundle. I do some Bayesian filtering on the client side, and I have a call to use Vipul's Razor in my .procmailrc files, but it's great to filter this stuff further up the data path, too. Fortunately the three servers that get me the most mail all run Postfix. Postfix has some nice common-sense features that cut down on spam right out of the box. First, I made sure all three servers used wp:DNSBL lists to block open relay servers. Second, I added some checks for validity on sender address domain and domain in the HELO command. Finally, I added a filter to check the Sender Policy Framework to see if the connecting server is authorized to send mail for the sending address's domain. Of the three changes, I've found that the basic checks -- making sure that sender address domains and HELO hostnames are valid -- are blocking the most mail. But the other two kinds of checks help, too. This all came not a moment too soon, as the wikitravel.org mail server seems to be under another DDOS attack. Check out the numbers on the mail that's queued versus what's getting rejected!

evan@antipater:~$ sudo grep NOQUEUE /var/log/mail.log.0   wc -l
119150
evan@antipater:~$ sudo grep qmgr.*removed /var/log/mail.log.0   wc -l
590

Gee, three orders of magnitude difference... I'm getting about 50-50% on other servers. This is over the last 24 hours or so -- what a huge waste of time. tags: mail postfix spam spf email dnsbl

Since Joey Hess posted a short conversation we had on IRC today about the role of the DPL, I thought it's a good time to express some of my thoughts. Basically, I think that most people have a bad understanding of which tasks are really involved in being DPL (e.g. much more purely administrative crap that nobody else wants to do) and that they're quite naive about what the DPL can achieve, at least in the current climate. Let's just look at the current discussions on the -vote list. It's this time of the year when everyone pretends that its Christmas, expresses their feelings of what's wrong with Debian and where Santa Claus^W^Wthe candidates reassure them that everything will be fine. "Will you fix NM? Fix or replace ftp-master? etc." "Oh, sure I will, all of that (and more)." Honestly, would you elect someone if they told you they won't or can't? The strange thing is that the same questions get asked every year, and yet people don't get the hint and look for other solutions. I'm not overly happy with any of the candidates this year, and I was seriously considering running again, not next year but possibly later. However, this Christmas wankfest reminded me again why that may not be such a good idea after all. I remember how much time I spent answering questions on -vote myself, and while I'm all for transparency, many of the questions were just a waste of time. This year, the questions were relatively sane in the beginning but now it's just a waste of time most questions are posed in a way that it's clear what kind of answer people want to hear. I spent hours and hours answering questions, but at some point I thought "cannot we just stop talking for hours about what I'd do if elected and actually start doing all that stuff?". That would have been so much more productive. Instead of asking the DPL what they'll do to solve All The Problems In Debian, why don't you ask yourself what you can do to improve the situation? There's a bottleneck with the DAM, you say. Right, the chances that you'll be added as DAM are relatively small. But have you ever considered helping the DAM and to make their life easier? How about signing up as an Application Manager and producing such good reports that it'll be a piece of cake for the DAM to approve people based on your reports? Right, it won't fix the bottleneck, but it will make the situation so much better. Instead of bitching about the security team, why don't you prepare a package, write the text for the DSA and get everything ready in a way that a DSA member can simply take your work, recompile the package and issue the advisory? Now I'm sure some people will say that they've tried that and failed. Yes, not every upload for DSA will be accepted as it is, but how hard have you tried? And people always complain about the cabal and how hard it is to join teams. And while I agree that this is partly true, there are so many counter examples too. Look at me as an example. In 2.5 years, I became the most productive Application Manager, joined (and took over) the NM Front Desk, became a "senior" Quality Assurance member, and got elected as project leader. Am I special? No, in no way I just put in a lot of effort. Look at Jeroen van Wolffelaar, who joined at the end of 2004, and who is involved in QA (especially MIA) and lintian, is the co-author of the new packages.d.o code and an ftp assistant. Andi Barth (who got an account in January 2004) has done important QA work (bts2ldap), is a maintainer of the developers reference and a release manager. So it's not possible to join a team, you say? Maybe you're just not trying hard enough (and the right way!). (Hint: "make me a DAM/ftp-master/whatever" doesn't work as well as "how can I make your job easier?"). What I'm trying to say is that people should stop believing that the DPL will fix everything and that they should actually help out themselves. If we all work together and put effort into the areas that need work we might actually achieve something. People have been asking for a strong leader and this urge got stronger over the last few years. But, face it, we currently don't have a culture which accepts a strong leader. Joey Hess mentioned that he wants to see a DPL who pushes technical changes. I did that too, to some degree (mostly in private since that works much better than on a mailing list where a big flamewar is guaranteed). For example, I kindly asked Joey to lower the priority of the non-free question so it would not get asked in a default installation. And he did because Joey is a reasonable guy. (He also told me that me making this request made it easier for him to justify.) However, unfortunately, not everyone is like Joey. And what are you going to do if a maintainer refuses to listen, as many do? I mean, seriously, what can you do? Some are increasingly talking about the good old times of Bruce Perens who would tell people what to do and make decisions. The urge for a strong leader increased over the last years. I think that's partly a reason why Branden got elected last year people expected him to completely shake things up. I haven't talked to him and I wasn't part of the leadership team, so I don't really know what happened, but from what (little) I've heard, it seems that he tried, quickly realized just how rigid some of the structures are and gave up. You have to see things in a historical perspective (and I can only recommend that people who have access to the debian-private archives take the time to read through them). There's a reason we have had "weak" leaders since Bruce. While now a large number of people think that Bruce was the best thing since sliced bread, lots of people were really pissed off back then with him commanding people around. And what was the result? A constitution that would ensure that no leader would ever have such power again. And that's what we're currently stuck with. I think that one of the biggest problems Debian is currently facing is the inability to make decisions. There are so many endless, completely futile (and repetitive) discussions going on. We need someone who comes in, tells people to shut up and makes a decision on behalf of the project. A decision people will follow, even if they personally disagree with it. But seriously, do you think our culture would currently accept such a leader? I can tell you from experience that even people who have been asking for a "strong" leader won't actually follow a leader who tells them to take a certain course of action. We really need to fix this problem, and the problem is in our culture. And since our culture is defined by who we are, you should start with yourself first. Start by asking yourself a few questions. Do you think before posting something to our lists, and ask yourself twice whether it really adds value to the discussion? If there's an area that is problematic, will you try to help out? If asked to do something you're not particularly interested in but which is good for the project will you do it? And most importantly, will you contribute to make our culture something that is fun? The project leader is important, but don't wait for them to fix all of our problems. If there's a problem, try to figure out a way how you can solve it!

Since I find the DPL position increasingly uninteresting except as a position of technical leadership, I will probably use the following simple metric (which I think of as the "degrees from Bruce Perens" metric) to rank my choices for Debian Project Leader in this year's elections:

1. Order the candidates based on the perceived solidity of actual technical changes they propose to make to Debian.
2. Rank "further discussion" above the first candidate whom I could not bear to see as DPL.

I won't bother listing the result, it's pretty predictable. But I will here excerpt all the at least vaguely technical content from the candidate's platforms:

• Jeroen "Debian needs to focus on technical excellence with free software" "I will encourage more use of the official wiki"
• Ari / Zeke "I propose that all software in Debian be relicensed" "Also, we should remove all pictures taken by cameras with non-free firmware from the Debian Project." "I'd like to introduce a new Debian GNU/Plan 9 port"
• Steve (Steve wrote mikmod. Amazed I never connected those two dots before.) "more documentation on best-practice packaging and testing methods" "considering the impact of changes on the release schedule"
• Aj "The most important thing that I think would benefit Debian is increasing its tempo." "And sometimes doing it fast helps you to do it right" "getting updates accepted into the archive more frequently than once a day" "having frequent beta releases of etch/testing that we can legitimately call a release (benefiting from the ongoing work of the installer and testing-security teams)" "having reliably quick resolution of RC bugs in unstable" "automated testing efforts"
• Andreas "having more frequent and regular releases." "We have a good, realistic timetable for the release of Etch, and this should be made a priority," "Becoming More Purpose-Driven"
• Johnathan "When projects like Ubuntu and Progeny come along and pay people to do the boring parts of the work, we should be ecstatic." "a life-size statue on the grounds of Rensselaer Polytechnic Institute"
• Bill "Be strict in what you send, liberal in what you accept." "One of the problem of Debian is that too few developers consider the distribution globally rather than a collection of packages."