A running response to Kenneth Brown in the spirit of Alexis de Tocqeville
Version 0.0, 11 June 2002
Copyright © Leon Brooks, 2002
Permission is granted
to copy, distribute and/or modify this document
under the terms
of the GNU Free
Documentation License, Version 1.1
or any later version
published by the Free Software Foundation;
with no Invariant
Sections.
|
Are you
coming to sunny, friendly Perth |
The Alexis de Toqueville Institute (AdTI) has released (and possibly retracted) a White Paper entitled `Opening the Open Source Debate' in which they seek to restrain the current rapid acceptance of Open Source Software (OSS), and in particular its acceptance in government, by either conedmning aspect of it outright, or damning it with faint praise.
Ironically, Alexis de Tocqueville himself toured North America in the early 1800s, was much impressed by the liberty he found, and returned to France to try to duplicate the obvious benefits that he saw. He said `Democracy and socialism have nothing in common but one word, equality. But notice the difference: while democracy seeks equality in liberty, socialism seeks equality in restraint and servitude.'
You might feel justified in thinking that AdTI is following in his footsteps in opposing, by whatever means available, moves to mandate the use of only or primarily Open Source software in government. The reality is subtly but powerfully different.
A mandate for an Open Source preference in government operates to restrain private monopolies who have already, by default, begun to emplace restraints on the details of how government operates.
Does a restraint on restraint equal a liberty? Probably not. Is it the best solution likely to be actually implemented? Probably so. Does it operate against `servitude'? Certainly, possibly even excessively — we shall see. To follow in Alexis' spirit, therefore, one would support Open Source. Why didn't AdTI? Why did they publish against it?
It seems that the first guess of many people upon seeing so many of the phrases common to Microsoft's own railings againt OSS in the document is `because Microsoft paid them to', and sure enough, AdTI do take money from Microsoft.
At least as damning as the common phraseology would be the focus against the General Public Licence (GPL). Microsoft evidently don't have a problem with the less forceful BSD-style OSS licences, having incorporated large chunks of it into their own software tools and even operating systems. What makes them single out the GPL, as AdTI have done here?
My own pet theory is that AdTI took and trusted documentation from Microsoft, even though this is akin to relying on a fox's opinion of hen-house management.
I own and operate CyberKnights, a small consulting firm in Western Australia which deals as much as possible with OSS systems. CyberKnights derives most of its income from OSS-related work. I also work through Computer Clinic (WA), a similar firm.
On the other hand, this work is arriving at such high and increasing levels that I am earnestly seeking more OSS-skilled workers to cope with it all. An increase would simply give me more choice in the work CyberKnights accepted, rather than correspondingly increase CyberKnights' income.
To keep this document at a manageable size, I'll only respond to points that I regard as manifestly incorrect. This means that the commentary below will be more legible with a copy of AdTI's release to hand. This commentary necessarily relates to the `old' document since at the time of writing, there was no new one published.
`The source code is unrecognisable to most' is highly dependent on the kind of source code. Something like ulambda or assembly might be totally incoherent to Joe Sixpack, something like Python or BASIC would be reasonably easy to follow, if Joe Sixpack cared. Either way, it is only a `secret formula' if it is indeed hidden away, and even then, both source and binary code are simply expressions of a formula, in the same way that a painting or a Lego model are expressions of their subjects.
Completed software is generally not locked, it is compiled. This is like turning a blueprint into a useful object, which can then be run off cheaply by the million and sold. Not by coincidence, another name for machine code or compiled code or binary code is `object code', and it doesn't `operate the software', it is the software. `Executable software' is yet another name for the binaries.
Keeping code secret is generally not `the prerogative of the programmer', it is usually a decision taken by the company employing them. Many employee and contract programmers who would like to Open Source their work in order to avoid `reinventing the wheel' again and again are forbidden to by their employers, sometimes for genuine IP reasons, sometimes out of habit, sometimes in response to FUD (Fear, Uncertainty, Doubt) marketing.
The GPL is here branded `one of the most uniquely restrictive product agreements in the technology industry.' It is most certainly not the most restrictive agreement around, or anything like it, which is what a straightforward reading of that sentence implies. AdTI also contradict themselves by later quoting David Wheeler as saying that a `less permissive' licencee is required for commerce.
The GPL is unique, but the restrictions it imposes are nothing like those of many of, say, Microsoft's End User Licence Agreements (EULAs), which among other things require you to allow Microsoft to tinker with, cripple and even disable the software on your own machine, forbid you to swap parts around in it, forbid you to publish any test results based on it, or (for Windows 98) rent, lend, lease, split up, decompile or on-sell it. Furthermore, you must destroy the software if Microsoft decide that you didn't stick closely enough to the EULA!
The GPL does not require that software using other GPLed software be GPLed, only the parts that include the GPLed source. For example, if you use a GPLed web browser to power your encyclopaedia application (perhaps you added proprietary plugins, perhaps you used it as-is), there is no requirement to GPL the whole product. There is a requirement that you make the source to the browser available with your product, and if you modified the browser then complete source for the modified version must be made available instead.
The programmer also has the option of not merging his code with GPLed code. To see how ridiculous the argument is in context, say that you successfully decompile a copy of MS Internet Explorer and merge it with some of your own software. How happy will Microsoft be about you selling the result, with source code or not? What licence applies?
As to David Wheeler's quoted opinion, all I need say is `MySQL' or `Mandrake'. MySQL use a dual licencing system in which the other licence is less permissive than GPL, Mandrake GPL everything that they can. Two different approaches, and they are both working.
The FSF are most definitely not committed to ending patents on devices at all. You can read every word of their philosophy page and the articles linked from it, and you will find them speaking only against inappropriate patenting and copyrighting (restriction) of the likes of scientific research results and software.
There is no question: Alexis would side with the FSF on this one. And I would expect the FSF to have some stern words about your public misrepresentation of them.
Richard Stallman has always been regarded by some as `extremist' and `fanatic'; AdTI must by now surely agree that promulgating a strong viewpoint carries this risk.
I note that AdTI avoids mentioning that Mosaic carries a BSD-style Open Source licence, not GPL. Both Navigator, and Internet Explorer (via SpyGlass) were derived from Mosaic. Had Mosaic carried a GPL style licence, the `infuriated members of the open source community' AdTI mention would have had instant redress available for their grievances: change it so that it obeys the standards.
Microsoft paid no NCSA licence fees either. Both Netscape and Microsoft are and were `commercial browser companies'.
AdTI also left an important part of the tale untold. In commercialising the first Mozilla, Netscape essentially destroyed it. When Navigator was eventually released to the community, the only real option was to rewrite it from scratch. And it was done. The second Mozilla has been done right – with a GPLish licence – and adheres to more standards than most people care to know about. I plan to attend a first birthday party for it tomorrow.
The `success' of industry-government development partnerships has been the subject of prolonged complaint from a number of quarters. For example, after the USS Yorktown was left helpless by a cascade of Windows failures, many questioned the wisdom of giving Microsoft open slather (and pretty much an open chequebook) on future US Navy Smart Ships.
The more traditional partnership has been between government and academia, and in many cases the results have been OSS or freeware anyway.
The GPL does not require `patches to wander in', a big part of the freedom inherent in it is that the impacted agency has the power to fix a problem, on the spot, and share the fix at essentially no cost with other impacted agencies. Trying to do that with proprietary software is generally illegal.
GPLed software is no more `hapless', and often better tested, than proprietary software. What is certain is that users of GPLed software become instantly `hapmore' than proprietory fellow travellers when their software developer goes down the gurgler.
It's worth noting that AdTI speak against themselves again by quoting `releasing the binary executables would give away too much information' and `having the source code will not make it easier to “crack”' immediately after stating that `this poses unlimited security issues'. The auto shock absorber example does not speak to government.
Bear in mind that the agency developing the software is under no obligation to distribute it, even if the OSS model they choose is the GPL.
The `limitless potential for backdoors' is much higher in pig-in-a-poke proprietary software, as has been able demonstrated by (surprise) Microsoft (`Netscape programmers are weenies' and others), Kazaa, 3Com, Blizzard, iChat, ID Software, and numerous other vendors.
The FAA example is another classic non-sequitur. Where is a black-hat going to get a control tower or a Jumbo to test out his copy of the software? And again, if the FAA develops software, they are not abliged to distribute the source where they haven't distributed the binaries. If they did anyway, the likely outcome would be a rash of breath-takingly realistic control-tower and flight simulator games, rather than `pirate' control towers.
Concern about distribution has already been met and conquered by the OSS community, and, again, continues to function after the demise of parallel proprietary systems. Originally, the concern was for corruption – lest it interfere with smooth automated updates, but the defenses work just as well against hostile interference as against faults.
And again, Microsoft have also distributed viruses both on physical media and from their update sites. Clearly, secrecy and obfuscation didn't help? Again, why buy a pig-in-a-poke when you could inspect the merchandise if it were GPL?
And once again we return to the issue of commercialisation of GPL software. As Perúvian Congressman Doctor Edgar David Villaneuva Nuñez suggested in his response to similar points directed by (again) Microsoft at his government, why not sell and support OSS? Yes, users will have the source as well as the binaries, but how many of them are going to go into business against you? And if the licence you choose is GPLish, will not their advantages and improvements be yours as well?
The biggest objection I can see against the point is that a vendor may wish to demand an inappropriate level of control over government and entities within government – backdoors into their systems and the ability to control or disable them, for example – and that objection is one of the strongest reasons for adopting OSS in government.
The reality is that the government is too big a market for vendors to turn their backs.
Far from being a beacon, the inadequacy of current US IP laws, and their propensity for spawning frivolous lawsuits and generally giving the overworked legal system even more of a hammering, is rapidly dissolving into a joke. When protecting the IP of a record company involves killing your Mac's CD drive, one has to stop and ask whether the cost is legal, moral and ethical.
When IP laws are used to promote information piracy, one has also to ask a different kind of basic question: are they working?
The US patent laws originally covered an item for 14 or 17 years, depending on the type of patent. The intent was to prevent apprentices from taking unfair advantage of their masters' unique expertise, in competition, for two apprenticeship lengths (plus a half for certain types, rounded down). Now – using copyright law originally limited to 28 years – cover extends for 70 years after the death of the last author.
In the world of computer software, a program is generally quite obselete 5 years after release, and to lock down the use of same for 70 to 120 years or more seems more tragic than ridiculous. How is `motivating, compensating and protecting' to operate 60 years after the author has died, and the world at large doesn't even remember a time when the required hardware ever existed?
Patenting also requires registration of enough detail to completely reconstruct the process or object. Before railing at IP abuses, perhaps we should mandate that in order for digital IP to be patentable or copyrightable, enough pieces of it to allow reconstruction (ie complete sources including any necessary tools if not already registered) be deposited as is the current practice with biological samples. If the repository can't compile and run what has been deposited, the patent or copyright is invalid. Since the repositories had complete details, and could use parsers on the source, plagiarism would be much easier to detect automatically.
It's also worth noting that patent and copyright laws are often used to quash innovation, not to protect it. Apple and Microsoft sued each other over niggling user interface details that were actually pioneered by Xerox. British Telecom tried to exercise a patent on the hyperlink – not to motivate or protect innovation, but to hamper it, bleed it for money. UniSys and GIF, the list is apparently endless.
It seems fair that a genuine innovation should have some head-start time, but not forever. Something like 7 years seems adequate for software with restrictive licencing. Mozilla, KDE, Gnome, The GIMP, OpenOffice.org and many other large, useful software projects didn't even exist 7 years ago, even as predecessors.
We'll set the issue of manuals aside for a moment, and deal with the silly assertion that GPL `reverses the intellectual property model'. The GPL uses the intellectual property model to protect intellectual property, exactly as it was intended to be used, the only difference is in the copyright holder's choice of what to protect it from.
The traditional approach has been Shylock-like, to demand a pound of flesh, taken from about the heart, as the price for using the protected software. Under the new system, the price is a share of the interest (improvements) for everyone. Reasons for preferring this protection outcome are many, but include limited development or testing resources (including internationalisation), a desire to establish a fair or basic standard/benchmark/framework, to achieve rapid market penetration, to address a diverse market, philanthropy, craft, fame/reputation/demonstration (it would take Linus Torvalds about 10 minutes to find a new job, and most of that would be flicking through offers).
The new approach is not to fight for a bigger share of the market pie, but to make the whole pie bigger. The view that financial compensation is the only serious motivator is far narrower than the reality. I wonder if there is a way to account for the enormous, unrecoverable losses of creativity and productivity which that tunnel vision has already entailed.
Filings for patents and copyrights are also an extremely skewed measure of innovation. Many inventors already do not file for the very simple reason that filing exposes their invention, and they don't have the resources to protect it against the larger players. They simply rush to production and rely on `prior art' for protection if it's needed. Another hazard is having your idea ruled unpatentable because it superficially resembles one of the bazillion other registered patents, or a patent which is being `sat on' by its owner. The approach here is to produce anyway and hope to grow large enough to afford a lawyer in the event that you are indeed sued.
Real-life software warranties are generally a joke. If you are afforded any genuine protection, it is by consumer legislation, not by a manufacturer's warranty.
Manufacturer's documentation suffers from a number of difficult shortfalls. One of them is that the manual writer knows what he's talking about, and the manual reader does not. Bridging that gap can be a traumatic experience.
OSS documentation tends to at least include a HOWTO, a simple recipe/tutorial for getting basic things done. Learning from such an example is often much faster and more comprehensive than a cover-to-cover reading of a reference manual. In many cases, the HOWTO will cover the most common case or cases, and for those in a hurry can be used recipe-style.
This approach is carried across into the source: most OSS source includes two files called README and INSTALL. README will be a simple description of what the package does, perhaps the conditions of use (sometimes these are in a separate file called COPYING or WARRANTY), contact information, dependencies, credits and the like. INSTALL will include a simple HOWTO-style recipe for compiling and installing the software (often `./configure; make install').
Manuals, for packages complex enough to need them, tend to focus more on the nuts and bolts of how to reach this or that result than on enumerating every function call alphabetically (for exceptions, consider Apache or PHP). PHP's manual is notable for being an early adopter of online user annotations. Again, this means that real users – without the full context that the developers have and presume apon – are putting real experiences up for others at their level to learn from. They are also documenting what the software actually does, not what the developers planned for, expect it to do, or think that it does.
Manuals and internationalisations also tend to get written for or translated into the languages favoured by their developers/users, rather than those favoured by somebody's marketing department.
That last point about languages also applies at the level of drivers and file formats. Such things tend to be explored by OSS people who need them rather than by accountants deciding which market will be worth investing in next.
The results of reverse engineering can be interesting. For example, when the WINE developers were reverse-engineering Windows applications to find out which API parts they needed to support, it was noticed that some applications did not call the API correctly, and so it became possible to tweak the API to work around bugs in some applications (or in some cases bugs or poor wording in Microsoft's documentation). Similarly, reverse engineering a Samsung ML-85G host-controlled (dumb) printer resulted in a faster, more reliable printer driver than the `real' one.
It's hard to make the case that `if software is freely re[verse]-engineered , it will inevitably impact the value of software in the market' for software like a printer driver, which for the manufacturer is basically a regrettable expense needed to remove a roadblock to selling printers. Because of this viewpoint, drivers only get written for the few most popular OSes or applications, and those drivers tend to be pretty rickety.
Windows 9X covered a lot of sins, and one of them was shoddy driver design. If your system is going to crash five times a day anyway, ramping that to eight crashes because of a shoddy printer driver isn't going to be as noticeable as ramping it from zero to three crashes, as would be the case for FreeBSD. It's another good illustration of the `hidden' (unappreciated) value in OSS.
The case for a network protocol is still hard to make, especially when (as was the case with SMB/CIFS, painstakingly blackboxed to build Samba) it was undocumented partly to keep competitors out and partly because the `owners' of the protocol didn't actually know exactly how it all worked themselves.
Working up a level, we come to application file formats. Will this finally impact software prices? It already has. StarDivision (now absorbed into Sun) reverse engineered Microsoft Office's file formats before Microsoft deigned to publish them, and wrote StarOffice based on this; the files turned out to be basically a memory-image dump of what OLE2 was doing when the user hit Save. The released documentation was, as usual, wrong.
Sun soon Open Sourced most of StarOffice as OpenOffice.org, allowed to Open Source community to iron out some bugs, and then claimed a copy back to form a new StarOffice, much as Netscape did with Mozilla, but skipping the rewrite. Sun are now selling StarOffice 6 for much less than Microsoft Office, and OpenOffice.org remains an OSS freebie. This is going to nuke the office suite market, which I guess has been a long-term dream for Sun, so at first glance AdTI's contention may seems justified.
But no. Microsoft's idea of their fair share of a market is apparently 100% [find “maples”], and once they get something like that – standard business economics practice, this – they treat it as a `cash cow' and milk it while they can. This provides poor value for the end users, since the focus is now on milking the cow, not feeding it. What Sun has done is kick the cow. The end result will be better value and more choice for the end users. And less money for Microsoft, due not to Open Source laws, but to market pressure. Sun know that if they free up the office suite market, they can sell more Sparc boxes.
So yes, reverse engineering can help to crack open a monopoly, but the showcase example was a proprietary undertaking, not OSS.
Employing authors of GPL software is a perfectly valid way of obtaining proprietary software, if somewhat difficult to arrange if there are many authors. It also, in some degree, is supporting the GPL software, both by supporting the programmer(s) financially and by giving them opportunities to learn and refine things.
You can't legally link to a piece of GPLed code, you need LGPLed code for that. The FSF has been at this game for at lot longer than AdTI, and have had to deal with more such issues than you can imagine. You're the new kids on the block.
Of course, there is the ancient proprietary tactic of simply stealing the GPLed software and hoping for the best. The consequences of getting caught, of course, include implicitly GPLing all of your code, so it's not as simple as it looks. People do get caught, of course, often enough that the real theft rate is extremely low. It's really embarrassing to get caught stealing free stuff. (-:
AdTI seems to have missed a major difference between the `typical' OSS development scenarios and proprietary software development.
Say that a developer has built a rough but nifty tool, call it Ethereal. To start with, no stuffed-shirt product manager is going to use `Sniffing the glue that holds the Internet together' as a marketing slogan. So say Gerald Combs throws together enough of Ethereal to be useful for his work's purposes. Then he GPLs and publishes it. For very little effort, he's been able to help others, and in the process be helped by (at this point in time) roughly 160 other people to turn Ethereal into a leading world-class traffic analysis tool.
How do you cost-benefit that?
From Gerald's viewpoint, and his employer's viewpoint, all of these people made his product better for free.
Gerald is now famous within his circle and will never wait long if he needs a job.
His employer has a famous employee, and that value can be used to enhance his business.
Each contributor got a neat network tool for free.
They also got a small name for themselves, an important resume bullet.
Everyone learned.
Everyone got to do something worthwhile.
Some of them probably also got paid to help.
All of their employers now have better-equipped, more knowledgeable employees.
Countless other people, non-developers, got a neat network tool.
Some of them also appreciate the programming examples and centralised protocol documentation.
Who lost out?
There are three important points to consider, unmentioned by AdTI, before addressing what they do say.
1. OSS is typically more stable than proprietary software, so costs less to support.
For example, the City of Largo supports 900 Linux users on 400 workstations with 2 part-time staff. They also support a few score Windows workstations (in their library) with 8 more staff.
No Windows network would survive for long without virus scanners everywhere (more cost, more support), but Linux networks never seem to need them.
Note that these comparisons are made between Windows and OSS. The advantage is still there with, say, Macintoshes or Sun boxes, but it is much, much smaller.
2. OSS, if the problem lies with the software, can be diagnosed and fixed on the spot.
3. OSS generally results in significant savings across the board, which can then be committed to support, if needed.
That said, `if it requires technical know-how to operate, doesn't offer built-in support, and demands constant attention, it won't feel free for very long'. That's absolutely true! And if you've paid up front for proprietary software like that, how does it feel? Free?
Real-life OSS is as point-and-click as anything else, the built-in `support' of proprietary products – where it exists – is often completely useless, and OSS very rarely demands attention. For example, I have Linux workstations in my care with uptimes of over 300 days, and COTS Linux servers with over 500 days. The usual reason for killing such an uptime is a kernel upgrade, and the recent advent of suspend code plus a few other developments for the kernel may soon mean being able to swap even operating system kernels on the fly. And of course by remote control.
As to `open source inherently offers no guarantee or warranty whether it comes with a virus, back door, or any other serious technical problem, and GPL open source only exacerbates these shortcomings', I guess the real litmus test is how often it's actually happened, and how much difference having the source made.
I can remember exactly one such incident, the case of an OSS product being backdoored on the FTP server, and it was actually the binary copy which was backdoored: nobody who built from source got spyware, many downloaders were notified promptly, the malicious code was strictly passive, not all who downloaded it installed it, not all of those installed were exposed to the net, many of those routinely installed the next version when it arrived, and so unless the black-hats concerned can find those few remaining servers before they're updated, they're out of luck.
The list of proprietary products virussed at the point of distribution, even if not backdoored by design is legion. And how will they be found out, if the sources aren't available?
The remaining cost issues raised have already been addressed in passing.
I get non-technical feedback by being married to a non-techie. Other techs share accomodation, have parents, children, friends and siblings, workmates, customers... well, I'm sure you get the idea. Non-technical feedback abounds. And Open Source techie ears are available to hear it where no marketing survey penetrates.
OSS already has wizards and plug-n-play. In some cases it works better than the proprietary originals (e.g., my wife plugs in our camera, her Linux workstation sucks out the images, movies and sounds, organises them, and scrubs the camera 100% automatically in seconds). My Mnandrake 8.2 Linux workstation found my Acer 620S scanner by itself when I plugged it in. What more could you want?
Big-picture manuals? Not yet, maybe next year as more writers come aboard, but meantime the elderly couple just read the questions from the Internet Wizard to their ISP, key in the answers, and after that just click on the nice menus.
I would like to personally thank AdTI for not mentioning installation. Installing a recent Linux is usually easier than Windows (yes!), and of course very few people do it themselvres anyway, so it's a non-issue. You were wise to skip it. (-:
The licence is often shipped as the file COPYING or LICENSE because – among other reasons – it comes out first or nearly so in an archive or RPM package. These are subject to possible truncation (which would produce large and ugly error messages) but not to corruption or loss of leading information. If a .tar.gz (.tgz) or .tar.bz2 or .rpm archive is corrupted in transmission, the decompression fails noisily, the unpack fails. It is not credible to argue for corruption on a useable machine, and certainly not of the licence.
Notice of the GPL licencing is generally included in every source file. It is not reasonable to argue that GPLed code could be accidentally merged, in fact accidental merging with other proprietary software is much more likely and legally at least as catastrophic.
GPL tools would not be a licence-bleed risk, GPL (not LGPL) libraries would. Would proprietary tools and libraries be a risk? Microsoft's certainly would, they've taken to making it illegal to develop GPLed software with their SDKs. Have you looked at Microsoft's terms for distributing, for example, the Visual Basic runtime libraries?
If you violate the terms of the GPL, you (not the author) automatically void your right to use their software. There are no conditions mentioned in the GPL for the author(s) deciding to terminate your right. It is, after all, not an EULA. It's the same as if AdTI's software required someone else's proprietary ActiveX control and AdTI didn't distribute it correctly.
OSS is not the issue. To quote Wolfgang Pauli, that worry is `not even false'.
Your combinatorial worries can be solved very simply by not entering any grey areas. Either you merged or edited GPLed code to produce what you have, or you didn't. You can't half-merge a file. If you did, consider the result GPLed; if you didn't, don't.
Open Source software and the GPL in particular already constitute a burgeoning community and software industry of their own, no thanks to prevaricating naysayers, or Microsoft's strident and consistent FUD campaign. Expect it to keep thriving, no matter what you do.
Your choices are:
Do I ride this bandwagon now – or let it pass me by, carrying my competitors?
Do I remain a slave to proprietary lock-in forever – or do I start untangling myself now?
Do I play licence roulette forever, and settle for what I'm handed in return – or do I go for safe flexibility now?
Am I following yesterday's strategies – or tomorrow's?
I apologise for the dearth of links or detail in these last few sections, they will be added in the next revision. Expect more links, and more detailed answers throughout the document as the comments flow in during the coming weeks. This hasn't even been spellchecked yet. It's late. Goodnight. (-: