Rapid Responses to:

EDITORIALS: Douglas Carnall Medical software's free future BMJ 2000; 321: 976 [Full text]

Rapid Responses: Submit a response to this article

Rapid Responses published:

Medical Software's Free Future

Tim Benson   (20 October 2000)

free software?

Steve Hajioff   (21 October 2000)

Re: Medical Software's Free Future

Tim Benson   (21 October 2000)

GPL perfect

Nick Mailer   (21 October 2000)

Communication also enhanced under open source

Rufus Polson   (21 October 2000)

Is free not as good?

Douglas Holden   (21 October 2000)

Open Source LIMS

Myddrin   (22 October 2000)

Proper leadership

Scot Silverstein   (22 October 2000)

Comments from Richard Stallman

Douglas Carnall   (22 October 2000)

Medical software's free future

Mark Preston   (23 October 2000)

Exactly so

David Copeland   (23 October 2000)

Open Code

Charles Lister   (23 October 2000)

Not only but also..

Andrew Sims   (23 October 2000)

Open source: collaboration, not price, is the key

Jeremy Rogers   (23 October 2000)

Re: free software?

Jeremy Rogers   (23 October 2000)

FreeDevelopers.net will write Medical free software

Tony Stanco   (24 October 2000)

Some thoughts on responses so far

Dave Howe   (25 October 2000)

Re: free software, and check the licenses for the other kind...

Ronan Cunniffe   (25 October 2000)

Re: free software?

Gervase Markham   (25 October 2000)

Liability

Stefan Davis   (25 October 2000)

Open Source does not a good HCIS make

Jan Paleta   (25 October 2000)

Re: Proper leadership

Dave   (25 October 2000)

Re: liability / was: free software?

Horst Herb   (25 October 2000)

Re: free software?

Philip Hands   (25 October 2000)

Response to Dr. Hajioff

Graham Bartlett   (25 October 2000)

Bad design and use, not ubiquity

Adrian Midgley   (26 October 2000)

Open Source Operating System Software

R Ramasubramanian   (26 October 2000)

Open-source is the right solution to the wrong problem

Iain E Buchan   (26 October 2000)

Liability - not much new

Adrian Midgley   (26 October 2000)

Where do you want to GNU today?

Pierre Scotney   (26 October 2000)

Other free software benefits

Rolf Heckemann   (27 October 2000)

raising awareness

Axel M Klohn   (27 October 2000)

Ripped off

Pablo Millares-Martin   (28 October 2000)

Re: free software?

Gary Lawrence Murphy   (31 October 2000)

Medical software’s free future:

W K Abdul-Hamid   (7 November 2000)

Open Source Software

Andrew Skinner   (7 November 2000)

Windows is no less complex to support

Adrian Midgley   (10 November 2000)

Re: Open-source is the right solution to the wrong problem

Brian Rafferty   (10 November 2000)

BMJ as reference for open source definition - arrival

Adrian Midgley   (26 September 2001)

Peruvian congressman replies to Microsoft on open source software

Adrian K Midgley   (6 May 2002)

Medical Software's Free Future 20 October 2000
Tim Benson, Consultant in Healthcare Informatics Abies e-Health Send response to journal: Re: Medical Software's Free Future	The open source model (1) is so sensible that it is bizarre that closed source has held sway for so long. Unfortunately your title gives the impression that open source software costs you nothing. This is not generally true. Open source is "free as in speech, not as in beer" (2). Commercial companies can and do make money out of open source software by charging for services such as distribution, warranties, support, installation and tailoring. However, these fees are likely to have some relationship to the work involved. The up-front license fees charged for closed source software are "pathalogically" out of line with the cost structure. In no other industry are the products deliberately kept secret, where that secrecy cannot be justified by safety or security concerns? An obvious route forward for the public sector would be to mandate that all software developed at the public's expense be licensed as open source, although GNU may not be the optimum license (3). This provides optimum protection for the tax-payer. Crown Copyright, as it is currently used, does not do this. The gift culture ethos of the open source movement should fit in well with that of the NHS. As has argued elsewhere: "Open Source is the future: all we have to do is build it"(4). References 1 Carnall D Medical Software's Free Future BMJ 2000;321:976 (21 October) 2 Raymond E S The Cathedral and the Bazaar. Sebastapol, CA: O'Reilly & Associates, 1999 3 Di Bona S, Ockman S & Stone M (eds) Open Sources: Voices of the Open Source Revolution. Sebastapol, CA: O'Reilly & Associates, 1999 4 Carnall D Healthy Outlook. http://www.linuxuser.co.uk/articles/issue2/lu2-Real_Life_Linux- Healthy_Outlook.pdf
free software? 21 October 2000
Steve Hajioff, visiting fellow european centre on the health of societies in transition Send response to journal: Re: free software?	Editor Douglas Carnall's editorial (1) makes a strong case for the increased involvement of open source software in healthcare computing. Whilst many of his points are well made, there remain issues to be resolved. The first issue relates to risk management and culpability. Just as we assess the safety of the pharmaceuticals that we give to a patient, so must we be vigilant with the software that holds patient information and, even more importantly, the software that supports the clinical decision. In the event of a medical accident relating to such software there would be clear recourse against a commercial supplier. The status of open source software is less clear, would every jobbing clinician who had contributed to the development of a program share the liability should a patient receive a fatal dose of radiotherapy, for example? Further to this, would clinicians in such a case be indemnified by their employer or their insurer? The second issue relates to the way in which open source software develops. The development of open source software is incremental, with users often making only small changes and their dissemination being patchy. This could lead to technical support challenges, with multiple different versions of the same package operating, even within the same organisation. At his point it should be noted that open source does not equate with not for profit software, and the overwhelming majority of open source software is provided by commercial companies whose main revenue stream is technical support. This provides a further perverse incentive to system stability; the worse the system is, the more support calls, the more money they make. Further to this, it is well established that with each generation of code modification, software systems become more unstable (2). Thus for system safety and stability a from the ground up rewrite may be necessary. The open source approach, evolution rather than revolution, militates against such total rewrites, which tend to be performed by, or in response to, new entrants to a commercial software arena. Dr Carnall's point about professionals learning new user interfaces is well made, but this is an issue of badly designed software, not commercial versus open source; indeed open source software often has the most idiosyncratic user interfaces and does not comply to the standard conventions adhered to by some commercial suppliers . With an increasingly mobile workforce it is all the more important to see convergence and standardisation in user interface design, to place such constraints upon the open source software community may be problematic by dint of the lack of a central organisational base. Whilst there is a need for standardisation in user interface and core functionality, recent experience with the "I love you" virus highlighted the need for diversity at software code level. This virus was so devastating as a result of the near ubiquity of a single email client. Such software monocultures are as inherantly unstable as are monocultures in agriculture (3). For this reason, amongst others, there is an advantage in diversity of supply and, given the small number of players in the medical computing field, an opportunity to enhance the robustness of healthcare computing through the introduction of open source development. The way in which systems are developed seems to vary each decade, from the bespoke in-house solutions of the 1970s, to externally commissioned bespoke solutions in the 1980s we moved in the 1990s towards off the peg systems produced by commercial suppliers. More recently there has been an increasing move towards open source software, particularly in Europe, as a result of concerns at the degree of domination of the software market by a small number of US suppliers. Because of the tiny involvement of European industry in the multi billion pound international software business, it is not surprising that the EU seeks to promote open source software to counter this vast source of trading defecit with the US. Open source software development is a model that is highly fashionable at the moment. Whilst it may be an important part of the way forward for healthcare computing, there are a number of key issues which still need to be addressed. Dr Steve Hajioff European Centre on Health of Societies in Transition London School of Hygiene and Tropical Medicine, Keppel Street, London WC1E 7HT, UK Email: steve.hajioff@lshtm.ac.uk References: (1) Carnall D, Medical software's free future BMJ 2000; 321: 976 (2) Smith MF,Are clinical information systems safe. BMJ 1994; 308: 612. (3) Hajioff S, McKee M, The 'I love you' virus and its implications for genodiversity.J R Soc Med. 2000 Aug;93(8):398-9.
Re: Medical Software's Free Future 21 October 2000
Tim Benson, Consultant in Healthcare Informatics Abies e-Health Send response to journal: Re: Re: Medical Software's Free Future	**** CORRECTION ***** In my previous response, I incorrectly said "GNU may not be the optimum license" when I meant "GPL may not be the optimum license".
GPL perfect 21 October 2000
Nick Mailer, Director The Positive Internet Company Ltd. Send response to journal: Re: GPL perfect	The GNU General Public License (GPL) is undoubtedly becoming the most popular Free license. This is not because it is the most libertarian. Quite the opposite; it is a guarantee that something that is developed in the open remains as such. The philosophy is entitled "copyleft". It is a pity that the idea of copyleft could not have been adopted by the recently competing teams of researchers on the human genome.
Communication also enhanced under open source 21 October 2000
Rufus Polson, Library worker Simon Fraser University, B.C. Canada Send response to journal: Re: Communication also enhanced under open source	An excellent article. I would like to point out also that, historically, proprietary systems have tended to communicate poorly with one another, often by design, as corporations attempt to exclude one another from the market. If one succeeded, the results were monopoly. If none did, the results were poor communication between people using different programs. Free software has a strong tendency to use and develop open standards, document formats and so on, allowing good communication and interoperability between groups using different products. This is significant for such issues as transferring records between hospitals or from a referring general practitioner to a specialist being given a case. Rufus Polson
Is free not as good? 21 October 2000
Douglas Holden, Consultant intensivist/anaesthetist Ashford/St. Peter's Hospital Send response to journal: Re: Is free not as good?	As noted by Tim Benson, the free is Free as in "free speech, rather than free beer". I am not experienced in software development, but would like to dispell some possible doubts. Firstly, because the intellectual property is not kept secret, there is a degree of transparency which should ensure quality (although it could be argued that this lays open the system to malicious "hacking"). Secondly, people need not worry that because they ar running a machine using a different industry standard that they will not be able to access the system. For instance about half of the servers on the internet run Linux (perhaps even this one, and I am accesing the site using Windows withoout even worrying whether it is run by Microsoft products). Finally, it is sardonically said in the IT industry that "The nice thing about standards is that there are so many to choose from". Realistically though the dominant force in the industry is Microsoft, and open source software has to be able to interact with those standards. Given that this hurdle is overcome, open source software should be given serious consideration. Douglas Holden
Open Source LIMS 22 October 2000
Myddrin , Consultant Raliegh, NC (USA) Send response to journal: Re: Open Source LIMS	I would like to call your attention to a project that I am the "head" of currently. http://glims.sourceforge.net (or http://sourceforge.net/projects/glims) is an attempt to create a generic Laboratory Information Management System that will (hopefully) address the needs of the clinical, pharmaceutical and research medical communities as well as labs in most other disciplines. General LIMS is in the early stages of planning, and we need input from as many communities as possible. If you are interested in helping out, sign up for our mailing list or drop me a line! Thanks, RobK
Proper leadership 22 October 2000
Scot Silverstein, Director, Published Information Resources large pharmaceutical company Send response to journal: Re: Proper leadership	I agree with your editorial with one very important caveat: The finest developers in the world will have suboptimal results or will fail in clinical computing initiatives (point-of-care electronic medical records systems, decision support, etc.) unless they let clinicians, especially clinicians with a Medical Informatics background, take a leadership role. That means true leadership, not just a supportive or facilitative role. Support roles in the real world often mean that important decision-making rests in suboptimal hands. Based on my experiences, I no longer believe that personnel without a clinical background can lead such projects to optimal success, no matter how good they are technically (if computer professionals) or in business (if business people). Proper leadership is the key to success. Even if a project provides some functionality, it's become clear to me that the project could have been significantly more productive, at significantly less cost, and implemented in significantly less time, with such informatics-based leadership. Such "costs of lost opportunity" are generally not considered in clinical systems implementations. See my website at: http://members.aol.com/medinformaticsmd/ and the healthcare IT failure stories at: http://members.aol.com/medinformaticsmd/failure.htm for examples and a bit more detail. Regards, Scot Silverstein, MD
Comments from Richard Stallman 22 October 2000
Douglas Carnall, Associate editor BMJ Send response to journal: Re: Comments from Richard Stallman	Richard Stallman asked me to post these comments on his behalf: [rms comments begin] I basically like the article (as you would expect) but I found some small errors in it. 1. The whole GNU/Linux system has no single license. Various programs in the system use various different licenses. Many parts use the GNU GPL, but some parts have other licenses. 2. The GNU GPL does not require you to publish all your changes. It says that IF you publish a changed version, you must do so in a way that respects the freedom of the users of that changed version. 3. The full name of the license is the GNU General Public License, or GNU GPL for short. [rms comments end] I thank Tim Benson for citing my article in Linux User. The original HTML version (18kb) is available on my personal site: http://ww w.carnall.demon.co.uk/OpSrcHth.
Medical software's free future 23 October 2000
Mark Preston, Dental Surgeon Canvey Island, Essex Send response to journal: Re: Medical software's free future	I hope the free future for software extends to dentistry! What Douglas Carnell has written should act as a beacon to health professionals in this country to start pushing for change. There should be a choice between an open source option and a closed source option. Both have pros and cons. The problem at the moment is not only a lack of non-Microsoft options, but also the problem of human computer interaction. Most people are happiest dealing with computers that they are familiar with. For most people that means Windows and Internet Explorer. There will almost certainly have to be open-source programs that run on Windows, but surely there should be an option to run healthcare programs on other operating systems as well. For instance I would love to be able to transmit my dental claim forms to the Dental Practice Board (DPB) using Debian Linux, but there is no way at present for me to do this - even though it is theoretically possible. Open source is not for the faint hearted at present and can be very time consuming, but there is an important point of principle involved. If we as healthcare professionals are all being encouraged to take part in peer review, then why not include the software we use? IMHO there is an alternative to Microsoft in almost all areas as far as general software is concerned. However I would be interested to know if there is any major dental software supplier in this country that provides any of the following:- 1.An EDI link to the DPB from either a Mac or Linux based computer, without the need for any Windows or DOS based programs. 2.An agreement that does not involve source code escrows. 3.Any "Open-Source" software component(s). 4.A license that allows for unlimited expansion of dental practice network terminals, without the need for further license payments. Money should be spent starting to develop "open-source" software that we as dentists require for our common computing and communications infrastructure. Hardly any of us would be capable of grappling with the source code of a whole operating system, but I am sure that many of us would like to be able to "tweak" some of the functions of healthcare software by having access to the source code. The ethos behind "Open-Source" development is completely different to "Closed-Source". It allows for true peer review and greater participation by users in development and bug fixes. "Closed-Source" effectively sets the rent at just below what the market can bear, and prevents peer review. Could it be in the future that the average dental practice relies on a Linux based server with "Open-Source" software to run on PPC(Macs)? For ethernet you just plug them together. A set up based on iMacs would be economical, and probably quieter than PCs. If there was a viable non-Microsoft based alternative then I`m sure the costs of running a dental computer network would come down. In my view if Microsoft is the problem, then Linux is the solution. If present software costs and reliability are the problem then open source may be the solution. The reason that open-source products have tended not to be used extensively in the past has been that if things go wrongthere is nobody that can be sued. However, even big companies that can afford the costs of litigation are often choosing open-source products now, because they recognize the value of having the source code. Also reading the license agreements issued by most proprietary software suppliers it is clearly difficult to prove their liability. In the future the source code on which a business or healthcare system comes to rely will become increasingly important. It should be made available to the clinicians and others at the point of healthcare provision if and when required. This should allow the power to dictate changes to rest with the healthcare professionals as well as with the software supplier. From Mark Preston (Dental Surgeon working in general dental practice. Canvey Island, Essex)
Exactly so 23 October 2000
David Copeland, Montreal General Hospita. Send response to journal: Re: Exactly so	Medical software definitely needs to open-source; there will always be essential proprietary bits, but the fiasco we have had up till now is in no small part due to the lack of open-source software and content allowing one to build on the efforts of others. Sharing is the key to cooperation, and the waste of talent in past years has been a great shame. I am not saying that physicians need to become programmers: not at all--this is most often a bad idea, though there are exceptions. What we need to see is an end to the fragmentation and failure of most of the early attempts, based on the limitations of proprietary software in great measure. Next we can try to work on enabling full-text access to medical literature (copyright was intended to protect authors, not build empires!), and the power of distributed computing will enable many a medical/scientific conundrum to be solved. If done right, Medicine may become much more attractive and fulfilling.
Open Code 23 October 2000
Charles Lister, General Dental Practice, Computer supplier adviser GDP Salisbury Send response to journal: Re: Open Code	It is good to see the Open Code argument gaining ground. In dentistry, we despair from a number of dreadful data beds. The Dental Practice Board command a great deal of industry time because they do not issue the interpretation of the dental fee scale in open code and so EVERY manufacturer has to individually write code to translate the fees - incluuding all the updates! The Statement of Dental Remuneration (a stautory DH document)is in itself a tedious document, with no thought given to digital interpretation, stemming from its 40-year old origins and HMG fear of changing the earning patterns of dentists by radically overhauling it. And so there is no national list of treatment and procedure codes. Consequently the opportunities for audit and epidemiology are becoming increasingly difficult, where the desired reality is that such matters should become easier as increasing use of ICT is observed. Meanwhile, we all seem to have to 'benefit' from the software of Mr W Gates, esq, which good as it is, some of the time, does mean we have 90% of a product that we do not want, and a level of reliability that is at best acceptable and at worst harbours all the problems with Windows®. It is my opinion that the National bodies, (BMA BDA) , should fund the core open code, and then licence it to the manufacturers.
Not only but also.. 23 October 2000
Andrew Sims, Head of Computing Regional Medical Physics Department, Freeman Hospital Unit, Newcastle upon Tyne NE7 7DN Send response to journal: Re: Not only but also..	Douglas Carnall's excellent article particularly highlights the usefulness and robustness of the GNU/Linux "free" operating system. However it is worth noting that the GNU project also embraces an extensive range of "free" software tools, ranging from simple text editors to industrial strength SQL database server software. I have used various GNU tools ( www.gnu.org) in the course of software development projects for use in the NHS. Whilst some effort and knowledge is needed to make use of them, GNU software is invariably well documented and robust: attributes which are all too often lacking from "shrink-wrap" and third-party bespoke software.
Open source: collaboration, not price, is the key 23 October 2000
Jeremy Rogers, Clinical Research Fellow University of Manchester Send response to journal: Re: Open source: collaboration, not price, is the key	Dr Carnall's article hints at a different aspect of software that is of particular importance to medicine and medical software, and which motivates OpenGALEN: who owns or can contribute to the knowledge that drives these programs ? Open sourcing is usually thought of exclusively in the context of software devices and their programming code. Discussions about open sourcing often revolve on whether it is free or not to an end user who has no plans to contribute to the development, and what this means for reliability and culpability. However, the deliberate decentralisation of the software development process - and not an altruistic desire to give everybody a free lunch - is usually the main driving force behind decisions to open source, and this is of particular relevance to the knowledge component of medical software. Clinical software of the future is presently envisaged as a very different beast from the data blackholes of today. We imagine all kinds of intelligent or semi-intelligent agents, running around analysing our patient records, our published medical evidence, our local treatment policies and guiding us through the information overload. To behave in this way, such software agents will require access to considerable amounts of knowledge about medicine, stored in a way they can read and, increasingly, separable from their traditional programming code. The words - medical terminologies like SNOMED, READ, ICD and OpenGALEN - are just the start of this. Developing integrated knowledge bases of the size and sheer complexity required for medicine is a very large undertaking. The cost alone of doing it means that, notwithstanding any other interoperability benefits, it would be preferable if users only had to pay for one to be developed and for this to be widely re-used. Where such knowledge bases are being developed today, two models of ownership and control predominate: centralised as a state-funded infrastructure project or centralised as one or more competing commercial concerns. The extreme version of the open source argument is that some particularly complex forms of intellectual property can never be built satisfactorily as a centralised, closed source. To make the device work, or the knowledge base complete or consistent for all purposes, requires too many people to check it in too many different situations for a central, closed effort to be able to deliver more than a compromise. This is not only an issue of funding and organisational scaling, but also of the need to find a way around the preconceptions and blind spots that typically arise in a centralised development culture. A decentralised development framework that does not restrict the number or type of person that can be applied to the task is more likely to succeed, if a large and active community of contributors can be recruited to the task. Such a framework has other benefits: it simultaneously spreads both the risks of failure and the benefits of success - factors which certainly have the potential to stress or distort both the priorities of a central effort and the willingness of users to pay for it. The right to collaborate - a right you don't always have to exericise - is not the catch, but the whole point. Dr Jeremy Rogers Medical Informatics Group Department of Computer Science, University of Manchester, Manchester and OpenGALEN www.opengalen.org References (1) Carnall D, Medical software's free future BMJ 2000; 321: 976
Re: free software? 23 October 2000
Jeremy Rogers, Clinical Research Fellow Manchester University Send response to journal: Re: Re: free software?	Steve Hajioff raises some common concerns about open source: Who do I blame when it goes wrong ? Proprietary control and culpability generally go hand in hand, at least in UK law. However, there is the feeling that the balance of power in that relationship is presently tilted too far in favour of the computing system supplier. Customers pay a lot, but still don't have what they need and the costs of changing supplier are prohibitive. Open source may well not strike the perfect balance either, but if we are convinced that proprietary control, secrecy and other commercial barriers have become an unacceptable part of our current problem then the remedy must inevitably involve some diffusion of culpability along with the control. Correspondingly, users of mission critical open source software may need to consider a different risk management strategy for when things go wrong than 'I'll sue my supplier'. How do I cope with change ? Incremental development poses a different sort of technical support challenge for roll-out, but is this really so much worse or expensive an experience than occurs with intermittent major upgrade ? Continuous gradual change offers a way to spread out the enormous disruption that can occur with step change. Additionally, in an open source world, you're free to delay an upgrade indefinitely or, indeed, forever without fear of pressure from your supplier threatening to withdraw support for earlier versions of the software or the annual data update imports that they might require. Problems of multiple different versions are not unique to incremental development projects, and the same solutions apply. In the Linux world, the community responded - and was free to respond - to a market sector need for fixed points in the sand: Red Hat, SuSe and Caldera compete for a living taming the flow of changes, and still their 'new release' timetable remains rapid by proprietary standards. Could open source developers have a conflict of interest ? In a system where money is made from technical support, there is an incentive to design the system so that it needs more technical support. A closer examination of the proprietary market suggests that a very large portion of the initial purchase price users pay for software is for on- going support rather than the static functionality offered in perpetuity by a particular version. Why else do Windows95 and Office95 have a retail value approaching zero today ? Why else is Microsoft considering a subscription pricing model for future software ? Commercial business and healthcare software contracting is yet more explicit: an initial purchase price plus a significant rolling annual maintenance and technical support charge. In principle, technical support costs for open source software costs are optional. Users can buy as much or as little as they need or afford or they can develop their own skills. Additionally, and crucially, the developer section in open source communities seldom maps exactly onto the service suppliers and, in any case, providing such technical support is conducted in an open market. A competitive market for services, in combination with the activities of genuinely altruistic developers (yes, they do exist), is thought to be sufficient or, at least, better protection for the user against such exploitation. Both of these checks and balances are more or less absent in the proprietary world, which also makes money from technical support. Dr Jeremy Rogers Medical Informatics Group Department of Computer Science, University of Manchester, Manchester and OpenGALEN www.opengalen.org
FreeDevelopers.net will write Medical free software 24 October 2000
Tony Stanco, CEO FreeDevelopers.net Send response to journal: Re: FreeDevelopers.net will write Medical free software	Dr. Carnall is absolutely right about the efficacy of free software. If people in the medical community would like to have free software developed for the medical community, please contact me at ton@FreeDevelopers.net. FreeDevelopers [ www.FreeDevelopers.net] is an international group of free software developers. Our goal is to replace all proprietary software with free software.
Some thoughts on responses so far 25 October 2000
Dave Howe, Software Developer n/a Send response to journal: Re: Some thoughts on responses so far	I would like, if I may, to make some comments on the responses this article has so far received. Medical Software's Free Future - Tim Benson The open source model (1) is so sensible that it is bizarre that closed source has held sway for so long. The open source model is not one that works well in a vaccum - the main reason for it's recent success is the communications potential and storage available from the internet - of the large number of OS-ameniable programmers that encounter any given project, the majority will at best give it a "that looks interesting" once over, and a small percentage will download the source. Only a very tiny fraction will actually contribute actively to the project unless it is already something they need. What the internet offers to this model is increasing the pool of visitors so that the very tiny percentage is in fact a reasonable number of individuals. free software? - Steve Hajioff The first issue relates to risk management and culpability. Just as we assess the safety of the pharmaceuticals that we give to a patient, so must we be vigilant with the software that holds patient information and, even more importantly, the software that supports the clinical decision. Indeed this is true - so which is the better option - a drug you get full information on, and can legally examine the exact formula for if you have access to a suitable lab, or one that comes in a sealed box, with no information on side effects or ingredients, but you are assured by the supplier will cure all ills? In the event of a medical accident relating to such software there would be clear recourse against a commercial supplier. Software is almost unique in this respect. Routinely, almost NO liability beyond the original cost of the software is admitted to, even for bespoke/customised products. I suggest a close look at any or all licence agreements you may have (but note an alarming trend of having SOFTWARE ONLY (called click-though) licences that have to be agreed to before installing the software, but are displayed on the screen only during that install) The open source approach, evolution rather than revolution, militates against such total rewrites, which tend to be performed by, or in response to, new entrants to a commercial software arena. You are obviously not aware of [Apache] then - or [Perl]. Apache was completely rewritten from its original accumulated-patch state, and perl is in the process of being rewritten AGAIN from scratch to accomodate better the changes that have occurred in it's language. Communication also enhanced under open source - Rufus Polson Free software has a strong tendency to use and develop open standards, document formats and so on, allowing good communication and interoperability between groups using different products. I would tend to lay the credit for this one on the internet itself, rather than the Open Source movement. From its early years, it has been built with blocks that are its standards documents - the [RFC system] shows not only the evolution of the internet and the web, but contains its living history and occasional sparks of humor Proper leadership - Scot Silverstein, MD The finest developers in the world will have suboptimal results or will fail in clinical computing initiatives (point-of-care electronic medical records systems, decision support, etc.) unless they let clinicians, especially clinicians with a Medical Informatics background, take a leadership role. That means true leadership, not just a supportive or facilitative role. That is a borderline decision - yes, professionals skilled in both computing and clinical concerns (and preferably individuals skilled in both) are needed for every step of development - but many IT professionals in the medical world just aren't up to the task of leading a Open Source project - it is a completely different "feel" to planning and commissioning a software system in the closed source world, with the qualities needed being technical (to integrate the work of many individual volunteers) social (to prevent the ruffled feathers of valued contributors leading to splits and territorial fights) and aesthetic (needed to give a unified, usable user interface, prevent "feature bloat" where everyone's wishlist gets added to a single screen, and decide when you have reached the point of feature freeze (a OS term for when you stop adding new things to the current version, and concentrate on making sure everything that is currently there is as perfect as you can get it before you start trusting it for serious work)) Apache has a upper-tier of developers who pass the "ball" of leadership amongst themselves - this may not be the best model for a medical-information project, but it works for them. Based on my experiences, I no longer believe that personnel without a clinical background can lead such projects to optimal success, no matter how good they are technically (if computer professionals) or in business (if business people). I would say the converse is also true - medically skilled personnel without strong technical skills would be as bad, if not worse. What is needed is a group of people with vision - who can build a wishlist that includes all the features needed, provisions for additional features to stand outside the main stream without disturbing its structure, and yet know what is practical and doable, what is awkward but worth the effort, what is crying for the moon. They must also not get so attached to their vision they will refuse to change it to accomodate hard facts. The other aspect that must be considered is the target users for each branch of the system. A system designed for, by and with the surgical staff of a hospital may well be optimal - for surgical staff. you need a central core that will bend readily to the needs of each special interest group, without compromising its own integrity and modularity. Open Code - Dr Charles Lister BDS The Dental Practice Board command a great deal of industry time because they do not issue the interpretation of the dental fee scale in open code and so EVERY manufacturer has to individually write code to translate the fees - incluuding all the updates! I agree, this is the sort of situation that cries out for a single, industry-standard module in something portable like C. FreeDevelopers.net will write Medical free software - Tony Stanco FreeDevelopers.net is one approach to the problem of finding developers for your project (especially in the early stages); another is to start a mailing list and project area at [Sourceforge] or propose a new project at a cooperative bidding site such as [cosource] or [SourceExchange] - the latter being a bit better for initial planning. Finally, some links Not sure how helpful these are, but they may help a little. [Ten myths of open source software] an interesting read, putting some of the claims both for and against OSS into perspective [ESR's Site] considered to be the "bible" of the philosophy behind OSS [Infomarkets] an interesting idea - you pose a question (and your estimate of its value to you) and potential experts post their bid for the contract. The site itself takes 10% of the agreed price as a fee...
Re: free software, and check the licenses for the other kind... 25 October 2000
Ronan Cunniffe, Postgrad in Computer Science Trinity College, Dublin Send response to journal: Re: Re: free software, and check the licenses for the other kind...	In response to Steve Hajioff.... comments from the technical side... The first issue relates to risk management and culpability..... In the event of a medical accident relating to....software there would be clear recourse against a commercial supplier. Check the license terms of any and all software used. Most software explicitly disclaims ANY LIABILITY for damage to or loss of data. [with] open source software...., would every jobbing clinician who had contributed to the development of a program share the liability should a patient receive a fatal dose of radiotherapy, for example? This is classic example of "well don't do that, then!" Open source development has certain very valuable features, but certain types of software - clinical diagnostic software and flight control software for the space shuttle being perfect examples. The solution here is to allow anybody to *read* the source code, but when changes are proposed (by anybody!), they are vetted by a small, permanent group of experts. This is how open-source development works anyway, with the possible exception of legal liability. The second issue relates to software is incremental, with users often making only small changes. If the software is critical, then users should not make changes, end of story. The upgrades will come from a central trusted point, built of *vetted* feedback from many tributary sources. and the overwhelming majority of open source software is provided by commercial companies whose main revenue stream is technical support. No. The overwhelming majority of open-source software is built by individuals motivated by an ideal - high quality software that they fully control. It is just that all the formal technical support is commercial. Can you give an example of a piece of open source software written by a commercial company? Commercial companies support Linux, yes. They didn't *write* it, nor do they control it. Further to this, it is well established that with each generation of code modification, software systems become more unstable (2). The open source approach, evolution rather than revolution, militates against such total rewrites. ??? Then explain why the open source operating systems (ALL of them!) are a) evolving astonishingly fast and b) are renowned for stability? Each generation of code creates instability *only if it is thrown into the mix without reference to what went before*. Ironically, it is the cramped deadlines frequent in the commercial software arena that cause this problem. Open source software is ready when it's ready. Software systems that become more unstable with each generation are synonymous with bad design or development practice. I wrote this response because many of the points raised in Steve Hajioff's post derive from the current experience of dealing with proprietary software and commercial software vendors. I have made some counter arguments where I felt his points did not apply. I also wanted to make a point which had not been made - the medical community should, wherever feasable, DEMAND release of all source code to commissioned software, as a basic element in any contract. Any contractor unwilling to comply with that requirement is essentially aiming to increase their profits on subsequent 'bug-fix' releases. A model where each bug found by the community rather than the contractor results in a fine for the contractor might provide interesting results.... Yours, Ronan Cunniffe
Re: free software? 25 October 2000
Gervase Markham, Student Send response to journal: Re: Re: free software?	Re: Steve Hajioff's points: "Who do I blame? With commercial software there is clear recourse." You obviously haven't read the EULA (End User License Agreement) of any closed-source product recently. You agree, when you use Microsoft Windows (for example) that: " DISCLAIMER OF WARRANTIES. MICROSOFT AND ITS SUPPLIERS PROVIDE THE SOFTWARE "AS IS" AND WITH ALL FAULTS, AND HEREBY DISCLAIM ALL OTHER WARRANTIES AND CONDITIONS, EITHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO ANY (IF ANY) IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF LACK OF VIRUSES, AND OF LACK OF NEGLIGENCE OR LACK OF WORKMANLIKE EFFORT. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, OF QUIET ENJOYMENT, OR OF NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE SOFTWARE IS WITH YOU. 7. EXCLUSION OF ALL DAMAGES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL, DIRECT, INDIRECT, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR ANY INJURY TO PERSON OR PROPERTY, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, FOR LOSS OF PRIVACY FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, AND FOR ANY PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE, EVEN IF MICROSOFT OR ANY SUPPLIER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THIS EXCLUSION OF DAMAGES SHALL BE EFFECTIVE EVEN IF ANY REMEDY FAILS OF ITS ESSENTIAL PURPOSE." (This is only part of the agreement.) There is no comeback at all against proprietary software vendors when something goes wrong. Secondly, re: patchy dissemination of updates. Almost all successful open source software projects have a central maintainer who collects patches and makes releases. There is no reason this couldn't be done for open source medical software. Thirdly, your point about companies having an incentive to produce bad software to get increased support calls is perverse. If the software was _closed_source_, this might be the case, but if it's open source, you can fix the problems yourself (or others can) without relying on any support company. Lastly, re: the "I Love You" Virus - the problem was not the monoculture, but the culture at Microsoft which puts "features" above security. Also, the lack of education of users as to the risks of running unknown code. Gerv
Liability 25 October 2000
Stefan Davis, Software Engineer Rapid River Engineer Send response to journal: Re: Liability	As already stated, all software, whether proprietary or open source contains bugs. The big advantage of open source is that anyone can fix bugs or deficiencies. They don't have to force a particular vendor to fix a bug or wait for them to release the next version. They could either do it themselves (if they know how) or hire consultants to do it for them. The question of liability is, however, important. With priopretary systems, only a single vendor makes changes, so you may be able to get quality guarentees from them for a fee. There's no reason this can't be the case with open source. There are two common alternatives: * have company run distributions of core medical open source projects. The distributor is responsible for ensuring that it works correctly. You can purchase quality and service agreements, just like the proprietary software world. * have a distribution that is run by a trusted non-profit medical agency. Changes will only be accepted to the distribution, if all contributors (or the consultants of contributors) agree that it's a safe change. This will result in extreme quality, but will be slow to develop. Debian is an example of this model. It's quality is excellent. In fact, the quality is so high that commercial distributions (e.g. Corel and Storm) generally ship the beta development branch of Debian so that they can get the additional features it provides.
Open Source does not a good HCIS make 25 October 2000
Jan Paleta, Software Engineer Send response to journal: Re: Open Source does not a good HCIS make	The benefits of open source in relation to the issue, as put forward in your article, are small when taken in context. Although no definition of a health care information system (HCIS) was made, such systems can range from an isolated personal computer running DOS and holding a patient contact information to complex systems running in 2000 bed hospitals, managing everything from admissions to running automated laboratory equipment and processing of radiological images to isolated databases bursting with useful, but inaccessible data. The main issues relating to HCIS costs are not hardware or operating system platform, but rather maintenance and possibly initial purchase costs. A large part of the purchase cost may be related to integration of incompatible existing systems or localisation of a system designed for another country. System maintenance, left to migrating "geeks" is a recipe for disaster. The issues have, mostly, been solved. Solutions are available. Open source can play a part, although not a vitally important one. We all access vast amounts of data on the internet. The data is stored in databases ranging from MySQL running on a 33MHz 486 and served up by Apache - Perl - Linux to a DB2 database on an IBM mainframe running OS/390 and WebSphere. Yet, we can all access the data through a simple web browser. In a hospital setting, a browser interface to laboratory data and patient information through an intranet is quite adequate for many situations. Little education is involved since most professionals have come into contact with the technology. Taken in the context of the internet, XML-formatted data is the way of the future. The place to start is not with a discussion of open source, but with discussion of standards (such as HL7), that can be applied locally and extended globally. I believe that standards such as these will only be successfully rattified by a commision or body, preferably in learning institutions, by adequately trained professionals. Companies will monopolise, open source will fragment. Once standards are set, companies can be forced to "tow the line", making "lock in" less likely. But a drop in the HCIS ocean. I received my MB.ChB. in 1988 from the University of Cape Town, my Diploma in Datametrics (computer science) in 1995 from the University of South Africa. Soon after establishing a private family practice, I started my foray into software development by writing my own practice management system. I have sold and supported healthcare management systems in Europe. I am currently involved in project management, software support and developoment in Toronto, Canada, unfortunately not in the medical field.
Re: Proper leadership 25 October 2000
Dave , Engineering Computing Business Program Technologist US Send response to journal: Re: Re: Proper leadership	You make excellent points "The finest developers in the world will have suboptimal results or will fail in clinical computing initiatives (point-of-care electronic medical records systems, decision support, etc.) unless they let clinicians, especially clinicians with a Medical Informatics background, take a leadership role. That means true leadership, not just a supportive or facilitative role." Now we begin to talk about project management, systems engineering, and the like. Proper requirements analysis, testing / verification, etc.. have always been the bane of software projects. Finding a way to get the information out of subject matter experts, such as yourself, and into a software development specification is key. Open source software "applications", suffer in this respect at times, but they needn't. The politicing and persons looking for "leadership" and "recognition" as many of us were taught and encouraged to do by society and the educational system is problematic. The intellectual property restrictions placed on us by the workplace are problematic. Carefully separate your for-pay work from your hobby and attach a license to your off hours work that forces it to be free. Open Content license for papers and such (so people can freely distribute) and something like the "viral" GPL for code, to force your work into the public domain where it can be carried on once you lose interest or energy or the capacity to breathe. If you really want to be a part of the solution, get involved. We must codify your knowledge, and provide that code, those processes and principles to the free world for peer review and use. Get involved! Browse through existing projects as sourceforge.net, or freshmeat.net or consider drafting an unencumbered specification. Please! All these stufy societies that lock there results or specs up and charge or the information do more harm than good. Keep them away rom the Open Source world. "Support roles in the real world often mean that important decision-making rests in suboptimal hands. Based on my experiences, I no longer believe that personnel without a clinical background can lead such projects to optimal success, no matter how good they are technically (if computer professionals) or in business (if business people)." As a technical person (training in Electrical and Aerospace Engineering) I see this all the time as I've ended up firmly entrenched in Information Technology over the last 10 years. Information technology is still wide open and non technical folks in leadership roles (IT is still veiwed as a support function and doesn't tend to attract talented leadership) with key decision making authority are making poor decisions at a phenomenal rate. In fact, in many cases, groups are defining ill conceived non-rigorous best practices that support poor decision making (there is no substitute for formal education - the more science & engineering, the better). Getting the right experts involved is so important, and so difficult. One of the beauties of public or open projects is that those with actual passion about a project or topic naturally gravitate to it.. though they are sometimes limited as often, particularly in the early stages, there is no compensation, other than personal reward. "Proper leadership is the key to success. Even if a project provides some functionality, it's become clear to me that the project could have been significantly more productive, at significantly less cost, and implemented in significantly less time, with such informatics-based leadership. Such "costs of lost opportunity" are generally not considered in clinical systems implementations." Good process cures ills. Still, you can lead horses to water :( Keep getting the word out and remember that a good leader sometimes actually sits in the back seat at times. I always put my name at the bottom of the list of contributors, even when I am principal on a project.. it's the end result that counts and people need recognition for their efforts. Cheers, Dave
Re: liability / was: free software? 25 October 2000
Horst Herb, Rural General Practitioner, Coordinator GNUMed project Cohuna District Hospital, Victoria, Australia Send response to journal: Re: Re: liability / was: free software?	The liability issue is often cited when it comes down to listing the negative issues of free software. This is simply not correct. While amended in a few countries by law, any commercial software package comes with a long disclaimer in small print stating that the producer will not be liable for any damage incurred by use of this software. It ususally states furthermore that they will not be liable for any compensation exceeding the purchase price of the software in case the user comes to the conclusion that the specifications are not met. Please read the license of any version of Microsoft Windows as an example for such unacceptable practice. Most countries are in a legal vacuum regarding consumer protection in software issues. I have yet to learn from a single case where one of the large software manufacturers (such as Microsoft) has ever been held successfully liable for the damage they have caused by providing faulty software. Especially in case of free medical software I would expect higher quality and reliability as a rule. The developers are mostly health professionals themselves, using their own software. Therefore they will take exceptional care in making the software as reliable as possible. As a coordinator of one of the few developer groups of free medical software (and a commercial software developer for 20 years) I know that no commercial project could ever afford the painstakingly slow development progress made by reviewing the code literally hundreds of times, not releasing anything before it passes the internal quality control 100%, not accepting any compromise in quality. No commercial project could afford to simply drop a whole project and start anew when contributors come up with an even better solution. While this is not the rule for any open sourced project, it is a fact that only free projects can afford this. The legendary robustness of operating systems like freeBSD, netBSD and the Debian Gnu/Linux distribution are a result of such a slow evolutionary process, and they are still unparalleled in the world of proproetary software where the financial pressure forces developers to release software prematurely or to even withhold bug fixes so that the customers will be forced to buy the next "upgrade". "Never change a running system" is a maxime of UNIX system operators. This must have come to the ears of proprietary software developers - they have realized that few people would buy expensive upgrades if their system would work properly. Draw your own conclusions, but rest assured that such behaviour is impossible in the world of openly sourced software.
Re: free software? 25 October 2000
Philip Hands, Debian GNU/Linux Developer Alcove UK Send response to journal: Re: Re: free software?	This provides a further perverse incentive to system stability; the worse the system is, the more support calls, the more money they make. Most Free Software support contracts are done on an annual fee basis, so are most profitable for the support company when nothing goes wrong --- If you insist on that, then you can expect them to make sure it works. Unlike in the Non-Free Software world, Free Software support companies are in a position to fix problems with the software, rather than just passing your problem report up the line to the vendor. So, you get fewer problems in the first place, and the ones you do get are fixed in a timely manner. Philip Hands Free Software Specialist http://www.uk.debian.org http://www.alcove.fr http://www.hands.com
Response to Dr. Hajioff 25 October 2000
Graham Bartlett, Software engineer Pi Technology, Cambridge Send response to journal: Re: Response to Dr. Hajioff	Sir, I would like to respond to some of the points Dr. Hajioff raises. I doubt I will be the first (or the last!) to reply to this after it has featured on SlashDot (a popular website for people interested in computers, software and technology generally). For the risk management question, I'm not sure what he is trying to say. Open-source does not mean that just anyone can make changes; changes may be submitted by anyone, but are only incorporated into the main program once the person(s) in charge of the project have ensured that the changes are correct and work properly. This is merely a matter of instituting an oversight scheme to test that changes which are submitted are correct both in software and in medical matters. Risk management is actually easier when you know yourself what the risks are. If you pass the responsibility to an outside contractor, you do not know how the software is being developed, and whether any coding guidelines are being followed or if formal testing is being done. Granted, you can sue them if things go wrong, but this is of little consolation to the patient's family after the event. Regarding your second point about software suppliers, it is true that the people who supply disks to you also make money from software support. However, this is merely for the operating system (the MS-Windows part), not for the software which you would run on it (the Word or Excel part). These are two very different areas indeed, and this is a crucial point to understand. The operating system is actually written by a large group of volunteers, and fixes to code are supplied very quickly (and widely disseminated, in contrast to another of your points). What drives these volunteers is personal pride in what they are creating, which makes for a higher degree of integrity in the code. This is gives a highly reliable result - most web-servers use this operating system, as Microsoft products simply cannot be relied upon to give the same level of reliability. The "I love you" virus is a prime example of why closed-source code should not be relied upon. This virus exploited a fundamental design flaw in a closed-source program. Most people were unaware of this flaw, so the virus could continue, unchecked by any defence. Rather than diversity disrupting viruses, open-source software seeks to provide the integrity which prevents viruses from running in the first place. Graham Bartlett.
Bad design and use, not ubiquity 26 October 2000
Adrian Midgley, GP Exeter Send response to journal: Re: Bad design and use, not ubiquity	The Concept and other macro viruses up to I Love You did not cause so much trouble because of the ubiquity of a particular mail client, they caused so much trouble because of bad design of the client, and bad use of email. Attachments are usually a bad idea, and sending Word documents as .doc files should be avoided.
Open Source Operating System Software 26 October 2000
R Ramasubramanian, Assistant Professor of Anesthesiology Vanderbilt University Medical Center Send response to journal: Re: Open Source Operating System Software	In addition to the Linux operating system mentioned in your editorial (1), your readers may wish to consider FreeBSD, a free, 32-bit, advanced BSD Unix operting system that runs on Intel compatible (x86) microprocessors. FreeBSD comes with full source code. It is one of the most stable operating system that powers many of the well known web sites like Yahoo! and Hotmail. Hundreds of free application software packages are available for FreeBSD and it also runs programs written for the Linux operating system. More information on FreeBSD is available at: www.freebsd.org. May I suggest that British Medical Journal consider the idea of publishing regular reviews written by independent reviewers on open source software packages that may be of use to clinicians? Reference 1. Carnall D Medical Software's Free Future BMJ 2000;321:976
Open-source is the right solution to the wrong problem 26 October 2000
Iain E Buchan, Specialist Registrar in Public Health Medicine Cambridge University and West Herts Health Authority Send response to journal: Re: Open-source is the right solution to the wrong problem	Editor, Douglas Carnall makes some interesting observations in his recent editorial predicting "medical software's free future" (1). We welcome this stimulus to debate over open-source medical software, but we are concerned that people in positions of influence, without the necessary software engineering insight, might over-interpret such debate. The National Audit Office report on the 1992 and current (1998) Information Management & Technology Strategies of the NHS Executive emphasises the need for greater clarity (especially costing), inter- operability and timeliness of NHS IM&T developments (2). To this end, commissioners must consider the business case for open-source software. Once written and stabilised, computer software must evolve to meet the changing needs of its users and to meet changes in the computer hardware and operating systems that it runs on. Such evolution must be resourced; either by maintaining the software directly or by buying into globally maintained commercial software. Most organisations choose to share the risk of maintaining critical software components by buying into commercial products such as Microsoft Windows (a range of operating systems), Lotus Notes (a system to help groups of people collaborate on documents, messages and schedules), Oracle SQL Server (a core system for managing databases) and a range of other software. The evidence indicates that any organisation that does not have software development as its prime function would pay more and gain less from using "free" software under General Public Licence than from using commercial alternatives (3). The NHS has a history of appalling fragmentation in its computer systems, and the use of open-source software is no solution to this. Moreover, it could be a dangerous distraction. We consider that the IT needs of the NHS are more important to the public health than those of the average fast-food chain. However, a fast food chain would probably not survive if its information infrastructure was as incoherent as the equivalent in the NHS. Open-source is a good arrangement for improving the coherence of the products of publicly funded Health Informatics. There are not, however, completely open-source solutions to most of the inadequacy of NHS information systems. Such inadequacy is, however, technically surmountable using a combination of commercial core components and NHS- derived work based upon open-standards such as XML. Most good information systems harness a combination of proprietary compiled software and locally produced open-standards content; for example the web pages of a corporate intranet. The functionality of open- standards content is increasing, and as such, some of the actions performed by compiled software can be achieved through active content such as action scripts embedded in web pages. This sort of work is a long way from the quest for completely open-standards software, and it has more to offer the NHS. An example of open-standards work could be the clinically led development of XML Schemata, more specifically Document Type Definitions for pathways of care. Much of the wasteful commercial health-niche software to which Dr Carnall refers, could be replaced by a federation of robust open-standards projects in the NHS. Such projects should not be confused with work on open-source software to replace core components of NHS information systems, which could waste time and money. In our opinion, the NHS Executive and the Modernisation Board should urgently consider the arrangements for the delivery of information systems that can work for patients now, and not bury their heads in the shifting sands of open-source. Dr Iain E. Buchan Specialist Registrar in Public Health & Research Associate Medical Informatics Unit, Institute of Public Health. University Forvie Site, Cambridge CB2 2SR iain@ukph.org Mr Jonathan Honeyball Contributing Editor for PC Pro Magazine & IT Consultant Woodleyside IT Ltd., Mulberry House, Belchamp St Paul, Sudbury, Suffolk CO10 7BP jhoneyball@woodleyside.co.uk Dr Barry Tennison Honorary Senior Lecturer London School of Hygiene and Tropical Medicine, Keppel Street, London WC1E 7HT barry@ukph.org References 1. Carnall D. Medical software's free future. BMJ; 321: 976, 2000. 2. National Audit Office. The 1992 and 1998 Information Management & Technology Strategies of the NHS Executive. HMSO; HC 371 1998/99 ( www.nao.gov.uk/pn/9899371.htm). 3. Transaction Processing Performance Council, October 2000 ( www.tpc.org).
Liability - not much new 26 October 2000
Adrian Midgley, GP Exeter Send response to journal: Re: Liability - not much new	The question of liability is an important one, mainly because it worries people and is used to raise so much FUD (Fear, Uncertainty, Doubt - a classic marketing tactic in the IT industry) What is given no prominence here is that uncontrolled alteration of clinical systems is occurring frequently through a high proportion of general practice. It also occurs in secondary care, although to a lesser extent that I can see. When I say uncontrolled, I mean uncontrolled by anything except the good sense and porfessionalism of the clinical and administrative and managerial people involved, and their immediate inspection of the changed system and ability to override deviant behaviour. EMIS, Meditel System 5 and 6000, Torex Premiere and IPS Vision all have scripting languages or reasonable susbtitutes. The Exeter System has the ability to have macros - stored keystrokes that might have been typed in - defined on a per workstation basis or probably on a per user basis if one uses different identities on the workstations. GPASS-2 with its open API (half a level of virtue down from the apex that is Open Source code) allows third parties including competent users to write widgets that add items to the medical record, or drive parts of the inner, certified, kernel code. An example is one which assits with influenza vaccine administration. Protocols, SOPHIES, Guidelines, ISIS, widgets... these are such obviously necessary elements of modern GP systems that people seem to have forgotten that they are programming (albeit at a pond-life level that real programmers may feel is only suitable for users) Some of the code is freely distributed, some is sold. Who is liable for it? If it is not sold, then the user is liable, as they are for the functioning of the other tools they use. One benefit of using modifications to one's tools which have the source code available for inspection is that one can arrange to have areas that are suspicious evaluated by somebody who does not have a commercial interest in declaring that it is all fine.
Where do you want to GNU today? 26 October 2000
Pierre Scotney, Research Fellow AMRAD Pharmaceutical Research and Development, Melbourne, Australia Send response to journal: Re: Where do you want to GNU today?	Nice editorial, the more education there is about the GNU Project ( http://www.gnu.org) the more accepted the ideas and implementation will become. Since most computer programmers now know of the GNU development tools and use them, the attention is turning to computer users who through good information will realise that there is an alternative to proprietary software. With the major GNU GPL'ed projects http://www.gnome.org, http://www.openoffice.org and http://www.mozilla.org developing into excellent products the stage is set for a desktop revolution.
Other free software benefits 27 October 2000
Rolf Heckemann, Research Fellow Hammersmith Hospital, London, UK Send response to journal: Re: Other free software benefits	As a researcher in medical education, I wholeheartedly agree with the points made by Dr Carnall about the benefits of free software. I would like to emphasize the importance of open standards as pointed out in some of the comments. Such standards and free software go hand in hand. This is exemplified by the internet itself, which was a "free software" effort before this term came into its current usage. Some important practical benefits seem to be overlooked because they derive from the "free beer" rather than the "free speech" aspect of software freedom. Since no license fees need to change hands, the choice of a solution can be based purely on its technical merits. Decision makers do not need budgetary control. Transaction overheads can be saved, and (possibly most importantly) the financial risk of acquiring a partially adequate or inadequate solution is reduced. My own project aims to establish a framework for integrating medical images and text to create educational resources. It is based heavily on free software (Apache-Cocoon). Code resulting from the project will be available under the GNU General Public License. Rolf Heckemann
raising awareness 27 October 2000
Axel M Klohn, MD and chief IT systems admin Permanence de Cornavin, Geneva, CH Send response to journal: Re: raising awareness	Dear sirs, I think Douglas Carnall's fine editorial has done a lot to raise awareness on the problems posed by proprietary medical software, problems that will only worsen with the shift to more complex and network-oriented architectures. We are also trying to make a point on those issues in Switzerland. See for example http://www.medecin.ch/article.php3?sid=20 for a note (in french language) about a medical documents secure transfer project based on closed-source software (unfortunately this project is receiving EU financing BTW). As noticed in many places, some of the people with decision-making abilities in those domains do not seem to be fully aware of the raised stakes (and implicit costs) related to their choices in licensing and architectures. Yet open sourcing the key components of networked medical IT architectures seems more and more the best answer to prepare the way for a truly competitive market in terms of medical software. Best Regards, A. M. Klohn http://www.medecin.ch
Ripped off 28 October 2000
Pablo Millares-Martin, GP Leeds Send response to journal: Re: Ripped off	I went to a meeting today with our local Health Authority regarding future IT for our practice and many others around. I was excited about the possibilities raised by your editorial regarding free software and a common platform for all[1]. I was hoping to hear that some common sense was going to spread around. But unfortunately nobody knew about this meeting you mentioned. Even more, nobody seemed to have read the editorial. I have to doubt there is going to be any movement from existing software suppliers. We are going to continue been ripped off by this companies that are able to promise many facilities in their software and maintenance packages when ultimately you get a product below minimum standards without a proper back up. What is even worse is that because it is a very competitive market, and companies are taking over one each other, new programs can become obsolete on the day of delivery, as it happened to our practice: Two days after installation we were told we have to move again to a different platform as our new software was not going to be supported by their new owners, as they have got already different programs to offer. And time has shown us that the program we believed to be optimal is unstable, unreliable, and a source of discontent for our staff. I am pretty sure if the Government were interested in a better NHS, where electronic communication and sharing of information could improve standards, they should have created an IT division to create a unique package for everybody. It should have been cheaper, and less traumatic for the health professionals to adopt. The current situation only improves the pockets of the many different companies sharing this vast market of hospitals and practices, unable to share information because each program data has to be read by the program that produced it. It can not be shared. The Government can blame GPs of been reluctant to change , but he is the one to blame for the mess that surrounds us. A software program could or could be not a Linux, a Windows or an Apple, but some standards are needed that are not in place: -all database should be in the same format, and different programs, different interfaces could transmit data from one practice to another when a patient moves practice (not a few pages of small print that you can not even scan). -practices should be able to have two different programs to read the data, so when the main one is crashed, at least the possibility is there to see (if not to change) what is going on. Ideally the computer should not crash, but it seems to ask for too much nowadays. NHS does not have the same code of practice than airport control towers. -a paperless NHS can not take place unless all communication between primary and secondary care is done electronically and we are far beyond that. Trying to get all letters from hospital scanned is a waste of human resources. In the same way, it should be possible to get the data for a single patient to be transmitted to a laptop or a floppy to be read elsewhere (GP doing a visit, patient moving area, ...) -security at present standards is poor and needs tightening. If I were a Dr Shipman with my current system I could easily get prescriptions as signed by someone else and falsify the signature, so I were not tracked. -etc. In summary, the message for the the Government should be: Give us the chance to feel we are improving the National Health Service, that we are cost-effective, that we are not moved backwards and forwards, that our staff is not trained and retrained unnecessarily, and GPs will be more than keen on adopting the IT revolution. We need to see the light at the end of the tunnel, but at present we are just weathering the storm. 1 Carnall D Medical Software's Free Future BMJ 2000;321:976 (21 October)
Re: free software? 31 October 2000
Gary Lawrence Murphy, CEO Teledynamics Communications Inc www.teledyn.com Send response to journal: Re: Re: free software?	All of Steve's comments are perfectly valid, but what is neglected is they are equally valid for proprietary software. The primary difference with open source in this respect is, should your current vendor prove less than adequate, you are free to take your project to someone else in the same way that you can take your car somewhere else if your local car dealer proves less than satisfactory. Do remember that "open source is not magic pixie dust" and bad software and bad management can happen anywhere, however your options for recovery in such situations is significantly less when the software sources are open.
Medical software’s free future: 7 November 2000
W K Abdul-Hamid Send response to journal: Re: Medical software’s free future:	Editor - The call of Douglas Carnall for the use of free software like Linux in the National Health Service made a very interesting point (1). I am sure that Dr Carnall’s opinion is based on his experience that clearly indicates a deep knowledge of computer systems and languages. The problem with the use of this form of software will rise in small health departments and practices and remote hospitals where there is already inadequate computer support. Even with the proprietary windows system, there are often problems related to crashes during which medical secretaries experience difficulties in getting support for the relatively low-tech use of computers in getting access to patients’ data systems or even undertaking simple word- processing of GP letters. There is much less support and training for free software compared with proprietary software like Windows (2). It might be practicable to use free software in large academic medical departments where there is more computer support and more technically computer literate professionals. Problems will rise in small district hospitals and GP practices with little or no in-house computer support. The free operating systems need familiarity and knowledge of the text-based language like Dos. A recent article in the Guardian supplement Online (3) gave good examples of the difficulties and problems associated with the use of one of the most famous free operating systems– Linux. In addition to the problems with the lack of familiarity and knowledge with the language of this software there were problems in the interface with other software applications particularly those related to networks and Internet access (3). The Guardian article gave an example of the typed instructions needed in Linux to access the computer CD rom drive which is: mount –t iso9600/dev/cdrom/mnt/cdrom/. For medical practitioners with little computer training, these instructions might be more technically demanding than the windows point-and click easiness. W. K. Abdul-Hamid, Consultant Psychiatrist, Linden Centre, Woodlands Way, Chelmsford, Essex CM1 7LF. T. Hamid, Computer Service Manager, West Thames College, London Road, Isleworth, Middlesex TW7 4HS. References: 1. Carnell, D. Medical software’s free future. Open Collaboration over the Internet is changing development methods. BMJ; 321:976. 2. Stutz, M. Getting Help With Linux. Linux Journal, No:53. August 1998. 3. Willmott, N. Linux is cooking in my kitchen,. Online, p 9. The Guardian, Thursday October 26 2000.
Open Source Software 7 November 2000
Andrew Skinner Send response to journal: Re: Open Source Software	Editor - Douglas Carnall (BMJ 21/10/00 p976) is correct when he says that the NHS is having problems with software procurement. However his view of "open source" development is too rosy. Any large datahandling project is a huge undertaking and needs expert developers who need to make a living. The NHS simply does not employ these people in quantity and it seems unlilely that developers working elsewhere will program for altruism's sake. Like all open source projects these developers would gain income from support, leaving us just as tied in to their system as any other and still paying for the system. Free software is free as in "speech", not as in "beer". The idea that having the source code would allow us to "fix" problems and take over the system's development is again optimistic. Reading code written by another developer (even if it is well structured and lavishly commented) is very, very difficult. Bugs are as likely to be introduced as fixed. The real problem with lots of the software used in the NHS is, frankly, that it is badly written. We have turned to software developers needing so much, so quickly, that large numbers of low ability programmers are able to make money with low quality software. The ubiquity of Microsoft Windows (tm) as a desktop operating system with its visual development tools has meant that it is frighteningly easy to turn out, say a database, with little or no knowledge of good system design. Often such systems work well in the author's setting, with the constant support and tweaking that brings, but they are incapable of configuration for a different site with different requirements. The real cost of a data system is the cost of collecting and inputting the data, its real value the information that you can get out of it. The cost of licensing software is trival in comparison. The real software problem is that we need better programmers, lots of them, and we need to pay for them. Andrew Skinner Consultant Anaesthetist Whiston Hospital L35 5DR Conflict of interest The writer writes free Windows Software, largely for fun.
Windows is no less complex to support 10 November 2000
Adrian Midgley, GP Exeter Send response to journal: Re: Windows is no less complex to support	The example of the mount command for a CD ROM on Linux is correct, however if you choose to use one of the GUIs for Linux (descendants of the X-Windows system that predates MS Windows, and like all these interfaces originally derived form the Xerox Palo Alto Research Centre work) then you will find that the mounting and unmounting is hidden from you in normal use. KDE on SuSE for instance - www.suse.com meanwhile in Windows - as soon as you get into serious use, it is back to the black screen to check network connectivity and typing in commands no less abstruse than mount. For instance, it is just possible that some reader may find a use for this... Disable Dial-In Access (Windows 9x and NT) It's possible for users to setup a modem on a Windows machine, and by using Dial-up Networking allow callers to connect to the internal network. Especially in a corporate environment this can cause a major security risk. Registry Settings: Key: [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Network] Value Name: NoDialIn Data Type: REG_DWORD Data: (0 = dial-in enabled, 1 = dial-in disabled) As for the supply of support technicians and engineers - apart from the fact that the generation who learned to run computers before MS are still around, in general anyone who is good at programming or supporting in one operating system will be able to switch to another. And anyone who is not good at it, another large and pressing problem, will be no worse. It is entertaining to place a Linux workstation in an office, with a modern GUI showing, and see how long it is before anyone notices that the interface is not Windows. Try it.
Re: Open-source is the right solution to the wrong problem 10 November 2000
Brian Rafferty, Sr Programmer Analyst Parkland Health & Hospital Systems (Dallas) Send response to journal: Re: Re: Open-source is the right solution to the wrong problem	If your institution has Information Systems Department with a programming staff, as many large hospitals have, you should realize that they could not exist without "source code". The purchase of systems that includes the source code allows customization for improved performance, functionality, and interfacing with other systems. The real production environment is the last and best place to iron out problems in the code. No test environment will truly simulate the real world data or real "creative" users. If you only get executables when you purchase software, you are completely at the mercy of the vendor. You have even lost control of your budget in some cases. It is rare that the end-user will anticipate every need that they will encounter in their work and communicate that to the software vendor/creator on the first request. Major items are frequently left off because the needs analysis is not done correctly before purchase or implementation. Major rewrites are then mandated. Costs can skyrocket. Deadlines are missed. If you need anything added, you have to get out the corporate wallet and pay and pay and pay. We can be talking amazing numbers of dollars here. This was supposed to be a plan to conserve money at first (usually). One size does NOT fit all in the healthcare industry ! That means you are looking to purchase custom or customizable software. This is expensive. Vendors who do not include source code may say that it will be less expensive for you to purchase from them. This has not been true in my experience. The initial cost is often lower but the follow up costs are still high. Proprietary software that does include the source is typically more expensive up front but cheaper to maintain, upgrade, customize, or integrate with other systems. Open-source has the advantages of the source-including packages, and it is lower in its initial cost. It is not cost free. You must shop and carefully consider what you need and can maintain, just as you would with closed-source "proprietary" software. I also believe that open-source projects do not usually advertise themselves as being better or more complete than they really are. They can never sell you vaporware because you can see the source whenever you want. Unfortunately, since open-source projects operate with a lower budget, you often have to look for them a little harder than for higher- priced (with advertising budgets) software. Government projects are another place where open-source code applications are generated. Since the "public" are funding the creation of this software, it is public property. Excellent applications from this area often are overlooked. If you want to deliver the highest quality information in the most cost-effective manner, you should at least include open-source in the list of options to consider.
BMJ as reference for open source definition - arrival 26 September 2001
Adrian Midgley, GP (half time sabbatical) Exeter Send response to journal: Re: BMJ as reference for open source definition - arrival	Seeing the link from the Medzope project page (0) naming this article (1) as the reference for readers to find a definition of open source is very good. References 0 www.medzope.org/aboutpage 1 http://www.bmj.com/cgi/content/full/321/7267/976
Peruvian congressman replies to Microsoft on open source software 6 May 2002
Adrian K Midgley, GP - sabbatical on health and internetworking Exeter ex1 2qs Send response to journal: Re: Peruvian congressman replies to Microsoft on open source software	The Peruvian Congress contains at least one congressman who has grasepd the essential points, and this letter of reply to Microsoft's response to a bill in congress is one that should be valued by anyone who is faced with the usual UFD (Fear, Uncertainty, Doubt) that is raised at suggestions of Free (Libre) Software in public life. http://www.gnu.org.pe/resmseng.html Since the Web may be voltile in include a trnaslated text below:- A letter from Dr. Edgar David Villanueva Nuñez, Peruvian Congressman, in response to a complaint from a General Manager for Microsoft in Peru. 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 analyse 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 indespensable 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 specifiy 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 reguarding 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 analyse 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 limites 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. por Decreto Supremo 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 fullfilment 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, competitvity 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 judgement 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 favour 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 subsidising 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 licences; 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 reponsible 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 licencing 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 proprietry 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 (RedHat, SuSE etc Gnu/Linux distributions), software which is free and not charged for (Apache, OpenOffice, 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 truely 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 precding 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 stament in two parts. Your first argument, that migration implies high costs, is in reality an argument in favour 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 favour 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 demotivates 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 incentivates 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 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 licences) 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 whehter 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 homogoneous 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 Republica of Perú.