Republicanism and FOSS

Self-governance is one of the core principles of classical republicanism. Free and Open Source Software (FOSS) is closely related to the idea of self-governance and hence classical republicans should promote its use. The opposite of FOSS is proprietary software.

Why is proprietary software a problem for classical republicanism? Since the source code of proprietary software is usually closed, users of such software are dependent upon its supplier for fixing bugs and other useful updates. This dependency decreases the ability of communities to exercise self-governance and increases the power, and consequentially the potential of power abuse, of software companies.

On the other hand, free and open source software enables members of the public to contribute to the development and improvement of software. If a supplier of a certain software package would decide to quit its development, its role could easily be taken over by other developers. In the case of proprietary software, however, this would be illegal as it would be an infringement of intellectual property, unless explicit permission would be granted.

Given the ongoing process of digitalization of society, the need of FOSS is greater than ever. Modern governments are virtually impossible to run without computer systems and associated software. By using free and open source software, the state is able to prevent becoming a hostage of software developers, which could under mine public interests.

Also the use of proprietary software is a (potential) national security risk, as software developers could hide back-doors in essential software. Back-doors could be abused by foreign powers and terrorists to disrupt society. FOSS allows people to inspect code on possible back-doors and the subsequent removal of those upon discovery.

Advertisements

2 thoughts on “Republicanism and FOSS”

  1. As to your last point, the security risk, I can make a direct comment. I’m still under NDA and so can’t provide any specifics but my story matches many others. I was the architect for a specific product area within a large company supplying a vast array of heavy-weight IT products some of which had significant security requirements. The bulk of the development was done outside the U.S. and mostly by contract companies (not organic foreign divisions or subsidiaries) and those companies often had contract employee. Even simple checking of credentials (like college degrees) was quite lax so you can imagine other checks of the integrity of the people was lax. I’m not down on outsourcing per se as I had numerous visits to the teams in their country and with decades of experience, all the way back to old days, with U.S. based software development I rate our outsource teams, overall, as good as any U.S. team. So that’s not the issue.

    The issue was how could a large chunk of software with over 100 developers be reviewed for hidden security flaws? The finished product was run through a battery of security checks (conducted by a subsidiary well known in security) and passed completely but I knew a backdoor could easily pass all those tests. The answer was the U.S. staff (who were held to a higher standard of background checks plus within the reach of the law) had to do it. Who was the U.S. staff? One person, me. There were other U.S. employees in other positions of project and program management, but only one person had the technical competence to actually do code review. Needless to say that was not my only responsibility. The amount of code was so large even if I devoted 100% effort to the review it would have taken longer than our schedule would have ever permitted (by upper management pressing us on schedules, as usual). So the best I could do was a few spot checks. I didn’t depend just on visual inspection, instead often running under the debugger at certain points and actually examining the active content of some critical objects. I looked for code that made no sense (actually found a fair amount of that, but it was partly stylistic difference between my traditional U.S. style and the style of the outsource country). I mostly tried to use the possibility that I would spot a problem as the deterrent, i.e. as a very senior architect no newhire programmer could fool me.

    But I know that product was shipped with a definite possibility of a hidden flaw (I did actually respect the team and their managers so I doubt that happened). BUT, after the initial development, to a relatively high-priced outsource contract firm, the maintenance of the product was turned over to a different firm, in a different country, of very dubious character (our outsource company held up this contract and our endorsement as a major part of their credibility so I believe it was important to them to do their own reviews, but the replacement company was a bottom feeder low bidder).

    All this said, I concur that the threat is real BUT given my experience of attempting to review for backdoors I seriously doubt open source solves the problem. I was paid to do what I did and it was my obligation to do it well. The idea that most developers contributing to open source are doing even the level of review I did seems implausible to me. The only way the hidden features might be found is the random chance that some other developer decided to dabble in the part of the code containing the hidden stuff. To assume all the team, unpaid and probably with intense day jobs, sit around doing high quality code reviews, but even more, actually test running code and look in RAM, not just dependent on visual inspection, seems unlikely.

    So which software effort really can do this job best. My view is it’s not possible to make a general conclusion, i.e. sometimes proprietary would do this better, sometimes open source. Obviously a open source project with many participants would be more likely to do better than a smaller team BUT at least in the case I mention there were people who would have been held accountable, to the level of legal actions (plus never working again had they failed) and the lack of accountability in a group of volunteers again reduces their probability of doing better to chance, not an inherent character of open source vs proprietary.

First comment? Please read our comment policy first

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s