The-Source.com

Color me not-surprised

Look. I wasn’t surprised when Microsoft launched yet another patent/IP FUD attack against Linux and Open Source, and I’m not surprised that some organization with the Business Software Alliance as a member is attacking Open Source.

It is what they do. If you are surprised or shocked, you aren’t paying attention. Let me just illustrate another fallacy card in the deck of disinformation being dealt.

Break it on down now

You need to understand something: the BSA is basically a front organization for Microsoft and has consistently and continuously lobbied against Free and Open Source Software.

They have done everything anti-Open Source they can short of printing up stickers of Calvin pissing on a penguin.

To understand where the BSA is coming from – or if you find yourself in need of an emetic – read its 2005 publication Open Source and Commercial Software: An In-Depth Analysis of the Issues. The bias against Free and Open Source Software is present in virtually every single sentence; much of it serves as talking points for Microsoft apologists and the IIPA “report”.

A small universe

Here’s the problem with much of the BSA’s position in this publication – along with those who parrot it 5 years later -  all source is “open source” to someone.

What do I mean by that? Within the confines of the proprietary software development team, the source is open: they can all see it, they can all modify it, they can work on derivatives of it, they can redistribute it to one another and so on. In that small and closed-off universe, the source is “Open”.

In this sense, Closed Source software is a sub-set of Open Source software. A horribly limited sub-set, to be sure – but what it means is that any problem Open Source has, Closed Source shares.

Examples, if you please?

Take if you like, the footnote of page 10 of the BSA publication:

³ See the classic paper by Ken Thompson, one of the fathers of UNIX, “Reflections on Trust” (http://www.acm.org/classics/sep95), where he notes that no amount of source-level verification or scrutiny will protect against untrusted code. The open source process cannot find clever subversions, no matter how many people look at the source code.

This is true. It is also true that the closed source process cannot find clever subversions, no matter how many people look at the source code.

How many “backdoors” and company-unauthorized “easter eggs” have been found in proprietary, closed software? How many have not?

The Open Source / Closed Source divide is irrelevant to finding clever subversions. Secure code requires an analysis process. It requires developers that are security-minded. It requires many things that are independent of source visibility. An Open Source project may have them. It may not. A Closed Source project may have them. It may not.

It is as foolish to imply that Open Source automatically can not find security problems as it is that Close Source can.

Here’s another example, same page – main body:

Some open source solutions have vulnerabilities that have remained undiscovered for years notwithstanding public availability of the code.

This is true. It is also true that some closed source solutions have vulnerabilities that have remained undiscovered for years notwithstanding availability of the code (to the developer).

And, I must point out that it is also true that some closed source solutions have vulnerabilities that have remained unfixed for years notwithstanding public revelation of the issue. Which could be quite a bit worse, by the way.

In every single case that the BSA report points out a security “weakness” in Open Source, it fails to acknowledge that very same problem applies to Closed Source. The truth is that the Open Source and Closed Source face the same development challenges, because those are Software Development challenges.

The development methodologies do not differ on the problems they face, only in how they attempt to deal with them. There is no magical guarantee that a Closed Source project has robust security processes or especially qualified developers.

Even the most high profile, tightly closed, well-funded Closed Source projects are released riddled with vulnerabilities known and unknown to the developer.

I Love my Converses

I could go on and on – for the BSA report, indeed much of Microsoft’s bogus criticism, is mired in this fallacious reasoning; only ever pointing out the issue with respect to Open Source, when in every case that the truth holds, it also holds for Closed Source. The bottom line is that any criticism you care to apply to Open Source can be applied to Closed Source.

The thing that is so beautiful is that the converse is not true: Closed Source must share all the problems of Open Source, but it can not share all the benefits. Again, this is because Closed Source is a crippled sub-set that is only “Open Source” to a small cadre of authorized developers, but true Free and Open Source Software is not so constrained.

One of the upsides of the recent news that 75% of Linux kernel development is now being done by paid developers is that it further discredits Microsoft’s FUD attempts here. Large FLOSS projects can attract qualified developers, get them paid, and implement practices that increase the security of the code.

But! In actual practice in the real world, Large FLOSS projects benefit even more because they can have volunteers in addition to the paid developers. Open Source has that additional opportunity in addition to paid developers. Closed Source does not. It can not, by definition.

The Open Source universe is vast.