The Digital Software Security Act [LWN.net]

One example of engagement with government is the Digital Software Security Act (DSSA), which is proposed for enactment in the state of California. This bill is strongly supported by Red Hat, to the point that CTO Michael Tiemann is leading a march to the San Francisco city hall on August 15. The law may look good at a first glance, but it is not clear that this is really the best way to promote the free software cause.

The DSSA is strict and unambiguous in its requirements. If a given software package does not come with source, and the ability to modify and redistribute that source, the state of California would not be able to buy it. If no suitable open source package exists for, say, the management of mineral rights or the operation of automated tollbooths, then state would simply have to do without. Chances are, some of the operations of the state of California would be adversely affected by this law.

The proposed law is extreme, and its chances of passage are minimal. Which is just as well. Imagine the backlash that would result once people figured out that, since nobody has gotten around to creating a SourceForge project for welfare case management, tracking of health insurance complaints, or the secure creation of drivers licenses, the state would no longer be able to perform those functions. This law would not last long.

More generally, free software is supposed to be about choices and freedom. That includes the freedom to choose software that does not necessarily meet the Open Source Definition. There are situations where a mandate of openness makes sense for governments: file formats for the storage of public data and electronic voting software come readily to mind. It is certainly in the interests of governments - and the governed - to use free software in situations where that software can do the job. But a heavy-handed law that requires the use of free software in all situations - even where such software does not exist - is excessive and counterproductive. World Domination is best achieved through better software and respect for freedom, not by legislative fiat.

to post comments

The Digital Software Security Act

Posted Aug 15, 2002 3:00 UTC (Thu) by jamesh (guest, #1159) [Link] (3 responses)

For a lot of the software Governments need, there isn't a big enough market for off the shelf solutions. Usually these would be put out to tender. With a law like this in place, it would simply mean that "being free software" would be one of the conditions placed on the tender. I am sure some company somewhere would send in a proposal. As a bonus, the government would not be restricted in which contractor to choose to extend or maintain the software.

The Digital Software Security Act

Posted Aug 15, 2002 13:27 UTC (Thu) by omg_foo (guest, #3276) [Link]

This is very true. The government should put out an RFP for an OSS solution, get bids, and award a contract.

Additionally, this law is not about OSS philosophies. It's about the use of public tax payer funds to provide excessive profits to an industry that is controlled by a monopoly. I don't have anything against software companies making profits, but under rules that provide fair competition, and today these rules do not exist. I applaud any effort in government that will balance the competitive playing field, including legislating OSS software for government use.

It's also about security. Relying on a single provider for a closed source application does not allow either public or internal audit of the actual functionality of the code.

We need rules that promote fair competition and security. Rules that don't lock the government in to a single source provider (for services, upgrades, maintenance or product). I see OSS type rules as the only valid solution.

We all pay an enormous cost because of the state of the software industry. It needs reform.

The Digital Software Security Act

Posted Aug 15, 2002 22:37 UTC (Thu) by DeletedUser816 ((unknown), #816) [Link] (1 responses)

What do people think about the quality of open source 'software for hire'?

Software that's not general-purpose enough to draw all those eyeballs to the code and to attract volunteers to support might not be the best fit for open source development. The contractor develops the stuff as cheaply and quickly as possible and then moves on. Now who deals with all the bugs and security holes?

Seriously, this could work if the source code were provided under proprietary license, since there would be an ongoing business for support and for sales beyond the initial sponsor.

But is that what this bill has in mind? Or is 'open source' here being used as a code for 'non-monopoly'? In that case, demanding open file formats would be a more reasonable (and maybe more effective) approach.

Besides, the kind of custom, vertical-market software contracted out by RFP is exactly the thing that's gonna keep 'the rest of us' gainfully employed once open source takes over all the commodity stuff. And maybe that's how it should be.

The Digital Software Security Act

Posted Aug 16, 2002 1:23 UTC (Fri) by omg_foo (guest, #3276) [Link]

"Or is 'open source' here being used as a code for 'non-monopoly'? In that case, demanding open file formats would be a more reasonable (and maybe more effective) approach"

This is only part of the problem. I have much first hand experience. Say we take the authors example of a program for "the management of mineral rights". Obviously, there is no COT software for this. Say you send out an RFP, evaluate bids and hired a contractor that writes a large monolithic proprietary application in 1995 using Win 3.1 and Paradox for DOS as a back end. Say the project costs you $500,000 for the product. Now you want to upgrade the product to an new platform, you have little choice but to hire the original contractor for whatever he charges. Otherwise you waste money paying another contractor to rewrite the entire application from scratch. You can't even produce a fair and balanced RFP that multiple contractors can bid fairly.

"Software that's not general-purpose enough to draw all those eyeballs to the code and to attract volunteers to support might not be the best fit for open source development. The contractor develops the stuff as cheaply and quickly as possible and then moves on. Now who deals with all the bugs and security holes?"

Just because it's proprietary don't expect the developer to not cut as many corners as possible. As you stated they will "develops the stuff as cheaply and quickly as possible and then moves on" independent of the license agreements. After all this maximizes their profit and, if it's proprietary they can lock you in for improvements afterward. I've had contractors intensionally low ball bids, barely meet specifications, and rape me later to make the product functional.

In fact my recent experience with specifying some OSS solutions is quite the opposite since the OSS developer has a wealth of available free tools they can apply to the product that simplifies and improves the product without affecting the
delivery cost.

The Digital Software Security Act

Posted Aug 15, 2002 4:57 UTC (Thu) by odonnell (guest, #3265) [Link]

I think that the article exaggerates the extreme nature of the proposed DSSA. The DSSA essentially only requires that when the state purchases software, it receives software. The so-called "purchase" of proprietary software normally does not involve the actual acquisition of software, but only of executable code and a limited license to execute it under certain conditions.

Phrases such as "software that does not necessarily meet the Open Source Definition" invite a misinterpretation. Neither "Open Source" in OSS, nor "Free" in FS, actually describe the quality of the software itself. Rather, they describe the rights that come with the software. The DSSA does not limit the software that may be purchased by the state. Rather, it limits the conditions under which software may be purchased. Similarly, the phrase "law that requires the use of free software in all situations - even where such software does not exist" is misleading. Under the DSSA, the state may purchase any available software. But it may not license the execution of software under highly restricted terms. One may argue the wisdom of such a restriction on licensing terms, but it's not particularly extreme.

Compare the proposed DSSA to a law that prohibited the state police from using cars that they leased without the right to perform safety inspections. As far as I know, nobody has ever offered to lease cars under such terms, but if such leases were common, it might be very reasonable for the state to refuse by statute to take them.

BTW, the DSSA appears to me to allow the state to engage in contracts by which companies use their own software to perform operations on behalf of the state, with no requirement that such software carry an open source license, or in fact any license at all. Such contracts can give the state the benefits of executing proprietary software, while making the contractor totally responsible for performance of the specified operations. The responsibility of a mere licensor of software is probably much less.

Mike O'Donnell

The extreme language is just a starting point

Posted Aug 15, 2002 19:01 UTC (Thu) by ssavitzky (subscriber, #2855) [Link]

It's my understanding that the idea is to start with something so extreme that it has no chance of passing, only so that there will still be something useful left after all the compromises have been made. If they started with something reasonable, there wouldn't be anything left by the time the legislative process got through with it.

Turnabout

Posted Aug 16, 2002 22:09 UTC (Fri) by crouchet (guest, #1084) [Link]

All arguments of practicality aside, it does give me a chuckle to think of MS cursing and fretting over this as we have often done when one of their proposals came to the fore.

The Digital Software Security Act

Posted Aug 18, 2002 0:04 UTC (Sun) by Baylink (guest, #755) [Link]

I concur with Jamesh in noting that the point of this is not to restrict the *buyer* to only open-source solutions, but to restrict the *sellers* from failing to give the sources to the State.

And I don't know that the law requires that the seller give the source to *anyone*, merely the buyers.

If that's the case, it's probably workable...