There has been a long-running debate on GPLv3, one which
has recently re-surfaced with the subject of binary-only drivers as the
centre-point.

It was clear to me from much of that discussion that there is very
little understand of what the "freedom" part of free software is all
about, and even less understanding of quite why it is so important.

In order to address this, I've created this posting, which includes some
components of the FSF's own pages, and some commentary of my own.

So, let's start with the bit about where it's defined. Why? Because a
recent poster indicated that the use of binary-only drivers is just a
slight compromise of intent, whereas, in reality, it compromises 3 out
of 4 of the intended freedoms of free software. So, a peak at the FSF's
own definition is in order:

" The Free Software Definition

We maintain this free software definition to show clearly what
must be true about a particular software programme for it to be
considered free software.

Free software is a matter of liberty, not price. To understand
the concept, you should think of free as in free speech, not as
in free beer. "

So, we are mostly concerned with liberty, and not price. A binary,
proprietary, driver, might be free of charge, but it is not free in
other key respects, those respects are listed here:

" Free software is a matter of the users' freedom to run,
copy, distribute, study, change and improve the software. More
precisely, it refers to four kinds of freedom, for the users of
the software:

The freedom to run the programme, for any purpose (freedom 0).

The freedom to study how the programme works, and adapt it to your
needs (freedom 1). Access to the source code is a precondition
for this.

The freedom to redistribute copies so you can help your neighbour
(freedom 2).

The freedom to improve the programme, and release your
improvements to the public, so that the whole community benefits
(freedom 3). Access to the source code is a precondition for this. "

So, if we have all of these, is it free? Yes:

" A programme is free software if users have all of these
freedoms. Thus, you should be free to redistribute copies, either
with or without modifications, either gratis or charging a fee
for distribution, to anyone anywhere. Being free to do these
things means (among other things) that you do not have to ask
or pay for permission. "

But, if we are charged for it, is it /still/ free? Well, yes it is, at
least, in the terms of the GPL and the freedoms enumerated above. The
fact that a binary driver might be free of charge does not mean that it
meets the definition of free software above. You might argue that this
doesn't matter, however, this is not the case. Why? Because of
lock-in; if you have a binary-only blob, you are limited to the usage
which the supplier intended, and any other usages it can /accidentally/
perform. Because, if you want to use it on a different platform, for
example, an nVidia binary driver on a PPC, then you need to be able to:

" You should also have the freedom to make modifications and use
them privately in your own work or play, without even mentioning
that they exist. If you do publish your changes, you should not be
required to notify anyone in particular, or in any particular way. "

Clearly, if the source-code is not available, even on the x86 version,
and you find one of the very many bugs in the nVidia driver (just look
up on the web to see just how many there are), then you are unable to
fix and patch the driver. This is precisely the reason why
free-software drivers have, over time, come to massively outperform
their closed-source counterparts, because the problems and bugs can be
fixed. Also, if you cannot get access to the source code, then you have
a problem here, too:

" The freedom to run the programme means the freedom for any kind of
person or organisation to use it on any kind of computer system,
for any kind of overall job and purpose, without being required
to communicate about it with the developer or any other specific
entity. In this freedom, it is the user's purpose that matters,
not the developer's purpose; you as a user are free to run a
programme for your purposes, and if you distribute it to someone
else, she is then free to run it for her purposes, but you are
not entitled to impose your purposes on her. "

You cannot run the binary-only software in any situation except the few
which the supplier considered worthwhile. It's been suggested in cola
that, for example, users of PPC machines are too few to be considered
worth worrying about, that we should only worry about the "majority" of
users, that freedom is something which is unimportant, that we should
compromise this area. Well, if you cannot run software, then it fails
in its purpose completely. If that means that you, the user, is unable
to user the hardware and software as you wish, then you have been
locked-out by the vendor. This is not an acceptable situation, and
clearly breaks the intended freedom of free software.

Now, what happens if your friend has a similar machine to you, and you
want to help them do the same thing you're doing? Here:

" The freedom to redistribute copies must include binary or
executable forms of the programme, as well as source code, for
both modified and unmodified versions. (Distributing programmes
in runnable form is necessary for conveniently installable free
operating systems.) It is ok if there is no way to produce a
binary or executable form for a certain programme (since some
languages don't support that feature), but you must have the
freedom to redistribute such forms should you find or develop
a way to make them. "

Of course, with binary-only software, then you cannot help in this way.
In my own computing room, whilst I can have nVidia cards supported on
some combinations of x86 machine, I cannot take that same code and run
it on the PPC machine. I'm not free to use my own computers as I see
fit.

" In order for the freedoms to make changes, and to publish improved
versions, to be meaningful, you must have access to the source
code of the programme. Therefore, accessibility of source code
is a necessary condition for free software. "

In case you missed it, I'll repeat the above point again:

"Therefore, accessibility of source code is a necessary condition for
free software".

So, to everyone who thinks that binary drivers are okay, I hope the
above has demonstrated precisely what the problems are with them; to
everyone who thinks that binary drivers are just a slight shift in
position, I hope it's become clear that they drive a JCB through the
middle of the intention of free software.

Here's a sentence guaranteed to switch off 99% of people on this planet:

"The open-source development model is mostly about economics, using copyright laws to build legal defences around shared engineering work."

Most people find economics fairly incomprehensible, and consider technology to be magical black arts performed by bearded and white-cloaked
druids, and the law to be something which rich people buy. Whilst there is some truth in all of these, political sharks know these views well. A good political orator can convince most people of almost any kind of technical or economic argument without needing a single shred of proof, because what politicians rely on is sheep-thinking.

Sheep-thinking? Well, given a choice of having a nice meal, or resolving the complexities of n-dimensional time and space, most people choose the meal, especially if it comes with aperitifs, wine and liqueurs. They like others to do the thinking for them, ideally, whilst they're tucking into their mutton and madeira pie.

So the deal offered by politicians looks good, at least on the surface: "You go out and get drunk, and we'll do your thinking for you".

Sheep thinking is really that most people are, mentally at least, out to lunch all the time. Or perhaps dinner, or supper, or maybe just a mid-morning snack. Thus, they need to get their opinions from somewhere, and quite handily, there are lots of really nice politicians who can offer them opinions by the cart-load. All that's left for most people is to check with their closer friends which particular viewpoint is generally agreeable, and Bob's your uncle, thinking done.

Not only do most people not know what could be considered to be fact or fiction, truly, they actively do not care, and do not wish anyone to wake them up from elevenses to explain things to them.

This leaves politicians in a very powerful position. Not only to they get to do the "thinking", but they get to be judge and jury, too. And this works very well for everyone, at least, until something disruptive comes along.

Disruptive ideas, like disruptive business models, attack accepted ideas. This is a rotten state of affairs for politicians, since they succeed or fail by being in touch with sheep-thinking, by knowing what the accepted ideas are, and by influencing them where they need to. Disruptive ideas attack the basis of political power, because it's not clear just what the outcome will be. Which viewpoint will prevail? Which horse do I back?

The politics of any large organisation is much the same, and disruptive ideas, such as open-source, are often seen as a threat rather than an opportunity, with the messengers painted as harbingers of doom, or as zealots rather than the experts in economics and technology which they really are. The bring facts, facts about economics and facts about technical development methods, but they bring them into a space where fiction and fact are rarely discriminated between. Where shooting the messenger is as valid an advancement method as any other.

But, it is the politicians who will ultimately make the calls. Most people are "out to lunch" with their thinking, so they will wait to see which bandwagon looks the biggest, and get on that one, perhaps kicking a few others out of the way in the process. The consequence? Well, it seems to me that in order to influence the politicians, you need a substantial bandwagon, and you need to get it any way that you can. It's of little value understanding the pros and cons of licensing methods, intellectual property, cathedrals and bazaars if the political types don't see many "voters" out there.

A good recent example of this working in practice would be the Dell decision to offer linux-based computers as part of their standard line-up. When enough people voted, senior people in Dell supported the work.

Simple.

You don't need to worry about facts or fiction, just get the votes.

Yesterday, I finally got around to loading the open router firmware onto a my linksys WRT54GL. I've imaginatively named it wrt54gl1.marknet, installed iproute2 on it, and recreated the policy-based routing on my current main server.

Next steps are to install bind on it, transfer a copy of my domain information, and then set up the DHCP server to replace the one on the main server. Basically, I'll move as much as I can onto it, as I'm splitting the main server, giskard, into multiple low-power machines, including a mythtv box from efficientpc.co.uk, and a file server from somewhere unknown so far, but it'll be a low-power one.

There is something very satisfying about secshelling to my linksys router from my Nokia 770; how far linux has come!

On the strange-event-of-the-day front, I found out why some of my emails from work to personal account were disappearing - they were getting grabbed into the spam-catcher bucket. I've requested that my email address is removed from this bucket, although I wonder how they will cope with spoofed from addresses? Time will tell.

Some will surely know that I edit a daily News digest, culled from the postings of the linux advocacy group popularly known as cola. I've been an inhabitant of cola for many years, have contributed to the FAQ, have contributed to the weekly stats package, and have made thousands of posts of my own.

I originally went to the cola group because it was debating many of the issues which were fundamental to my day job, essentially, the pros and cons of free software, Linux, the GPL, a new business paradigms around support, new development models built on the internet.

I've been all of positive, helpful, irritated, angry and even unreasonable at times, and have regularly taken part in political debate much wider than the politics of cola. Many of the people there I have the most respect for are the ones I most often disagree with. Except one group, these are the anti-charter, off-topic trolls; people who, in my view, should not post in this group at all.

In the main, I have them killfiled, a few at the leafnode level so they never enter my spool, but most in my slrn score file. I do it that way because I'm not the only user of my news server.

I watched again, today, as one of the regular trolls (usenet speak for people who knowingly present a false and provocative argument, frequently inappropriate for the group, in order to gain an audience. Well, today, I responded to the chap who had been trolled, with one of the most poetic pieces of prose I've ever written. Even I became sad on writing it, yet, I feel it is probably a reasonable summary of the character in question, so I've reproduced it here. Perhaps you'll resonate with it, perhaps not.

<--------- quote --------->

> Crowing would be me PERSONALLY bragging about it at every opportunity,
> manually typing "Look tosser, I've got a degree in this, I know what I'm
> talking about".
>

One can only imagine that he's either jealous, or merely trying anything he can to troll a response from you. Personally, I suspect the latter, he's just trolling, because he knows that you'll respond to this, even if just to tell him he's wrong.

I have a mental image here of a sad and lonely man, in a bedsit or cramped flat, dishes stacking out of the sink, and the remains of the last take-away meal waiting to be put into the rubbish bin. The room is fairly dark, perhaps a single light bulb, but most illumination comes from a PC monitor, sat pride of place, on an untidy but obviously well-used desk. There are piles of old PCI cards nearby, and lots of "windows for dummys" books, and perhaps an MCSE certificate in a frame on the wall, in view of the computer user.

There is a phone, but it rarely rings, and a mobile he uses to take pictures of what he likes outside the room. He transfers them to the PC in his room, of course, and would like to share them with someone, but is lacking in sufficient social connections to do so. His email account is full of messages from contacts in Microsoft, people he once knew well, people he envies because they were employed when he was not. These, of course, are the ones with the Comp Sci degrees...

He is at once fascinated with and terrified of Linux and free software. His terror stems from his lack of relevant academic qualification, but his fascination, in equal measure, from awe of those who write the code, who can manage the machines, and who are not scared. Deep down, he knows that free software is on an unstoppable march to an inevitable victory. He knows that his flimsy certifications will become worthless, and that he'll have to change or find another career, but he hopes that if he rants for long enough, like those foolish courtiers of King Cnut,that he can wish the tide back out.

So, he fills his empty hours with busy minutes, convincing himself that there is some value to his interaction with the usenet community he came to harass. The busy minutes often feel like exciting seconds, as he trolls someone into a response, perhaps justifying a point, or disputing, yet again, the same argument he made last year and the year before, in those endless, lonely days of empty hours, stretching back as
far as he chooses to recall. When he was younger, he used to look down on the old men, sat on their parkbenches, but now, he avoids gazing at them, because he's terrified of seeing himself, in 20 years, looking
back.

Don't feed the trolls - pity them.

<--------- /quote --------->

Want the quick answer, you know, the one which troubles you every time you upgrade your broadband and you /really/ believe that the streams will be reliable this time? It's because adding bandwidth in connectionless systems does not eliminate congestion, since the two issues are orthogonal, and what's more, most people actually know this from personal experience, at least, those people who drive a car in a congested urban area, anyway.

Road management agencies have long tried to address the congestion problem by adding lanes to motorways, but the result is not typically what was hoped for, as all it does is release further previously suppressed demand. Furthermore, adding lanes to roads does little or nothing to alleviate problems at junctions and other pinch-points, in fact, it can make them seem worse. Other techniques have been tried, again, to little positive effect; London's partial bus-lanes are well known to regular commuters in London. What use is weighted queueing up to the traffic lights when you're stuck 20 car-lengths back behind a car?

Well, none at all, really.

The whole queueing argument is one of the 21st Centuries best "snake-oil" sales pitches, but the flaws are easy to spot. Consider the bus-lane example above and think about how you /could/ make it work. In order to be 100% certain that the bus can get onto the bus-lane, the only way is to have a guaranteed access to it, which is essentially arguing that the bus-lane must be extended right back to the previous flexibility point, be it a junction, traffic-light or roundabout. At this point, though, the connection is no longer connectionless, rather, we've reserved bandwidth which is only available to the bus and nothing else between two flexibility points, or to put it another way, we've made a *connection*. Consider this in terms of a router function, we are effectively saying that a queue within the router is not going to be able to guarantee that a particular packet can get onto its queue if there is congestion on the incoming link.

Of course, you can now try to use the M25 needs another lane argument, and make the incoming link larger, which seems to address this problem, but in reality, it merely pushes the congestion problem to somewhere else in the network. So, just like the road system so many of us are so familiar with, there is no way to address the congestion problem using connectionless technologies, it is always going to be "best effort", and we need to look for another approach.

...Or do we?

One of the great strengths of the internet is that the vast majority of traffic which uses it has highly resilient transport protocols. It doesn't matter a great deal in most cases if packets are lost, misrouted, delayed or damaged, as the various layers of the IP network will recognise these different kinds of defect, and handle them appropriately. Lost packets can be requested again, or perhaps recreated using checksums, misrouted packets can be discarded as they do not belong to our link, delayed packets can be re-inserted into the link after a short delay in responsiveness to the user, and damaged packets can be re-requested or perhaps fixed using checksums.

All of this admirable behaviour is quite fine for two classes of traffic, the file, and the message. Files are typically fairly large, but
can be transferred using whatever bandwidth is available at the time. There is typically little requirement for a rapid file-transfer, merely a requirement that it be completed in the end with no errors. Messages are similar, but typically much shorter, and have some requirements regarding reasonable latency.

However, there is a third class of traffic, one becoming increasingly important in the Web2.0 world, that of the stream. Streams have one unique property, something shared by neither files nor messages, this is a requirement for temporal consistency between information units. This requirement is non-negotiable, and fixed within some very tight limits indeed, because for streams, the human brain-ear and/or brain-eye is involved in the link, and the brain cannot tolerate any significant amounts of jitter, wander, echo, packet-loss, errors, noise, distortion or any number of other impairments.

Sadly, all those fixes noted above for defects in transmission cannot be used for streams, because, quite simply, there is no time to request additional packets, nor time to re-queue misaligned packets. Streams are unique. This is why, exactly why, no matter how much bandwidth is made available, voice or streams on the internet are nev nev nev never going to be perfect using the current de de designs.

Well, now we should be asking ourselves a new version of our question, which is: can this be handled using the new protocols we have available?

Sometimes, history is kind to us, and on this occasion, is it extremely kind and generous, because all we need to look at are existing telco networks for inspiration regarding what needs to be done. Traditional telco networks are at the apex of many years of development of plesiochronous and then synchronous digital networks, these networks are designed for optimal latency performance, and tailored very tightly to the needs of voice telephony. All the same issues which were the bane of early internet adopters, analogue modems on dial-up lines, low speeds and so on were a direct result of using the switched voice network, optimised for streams, for the new and upcoming internet, which at that time was dominated by file and message transfers.

The bandwidths now, in the noughties, used for the internet are colosal when compared with those required for voice networks, although it's possible that video streaming networks, if commercially successful, could result in networks of much greater bandwidth still.

Well, what exactly did those telco networks do well? Connections. They set up connections, on the fly, very rapidly. They created the equivalent of a dedicated railway line or personal motorway lane or bus-lane from the very start to the very end of the connection. The bandwidth was /never/ shared with anything else, rather, it was dedicated to the voice stream in question, and had the other fascinating property of being fully duplexed with guarantees that there will be no significant latency between the two directions.

Which brings us right back a decade to look at some of the erroneous assumptions which were being made during the 1990s about the then future network designs, ie., those designs of today. A great many pundits and equipment manufacturers were arguing strongly that all traffic types should be merged in layer 3 on IP, instead of on layer 2, SDH or WDM, but many of us were then quite convinced that this could never work, because of the peculiar, but unavoidable, needs of streams.

The right answer was right where we were, that we should mix our traffic at layer two, where it is possible to keep connection-oriented links separated from connectionless ones, so that we can have a best-effort internet which can co-exist with connection-oriented streams. So does that mean we're stuck with the highly expensive TDM interfaces? Well, not necessarily; some colleagues of mine have been working on Carrier Grade Ethernet, now known as PBB-TE, directly aimed at resolving this set of pressures. It gets the gains of ethernet in terms of interface costs, but can be managed using existing telco management infrastructure, keeping introduction costs to a reasonable minimum. PBB-TE offers connection-oriented packet switching, rather like ATM did, but without the small-packet limitations of ATM. You can read more about it here: http://en.wikipedia.org/wiki/Carrier_ethernet_transport

This issue also has strong implications for the net neutrality debate, in that it essentially eliminates it! Telcos will be able to charge for bits moved no matter whether those bits were on the connectionless or connection-oriented side, so there will be little disadvantage to telcos if people choose to use a best-effort voice-provider, since the bits could be charged for in the same way anyway.

Looked at the other way around, it could be possible, by judicious use of PBB-TE, to make Skype or Gizmo as reliable as the PSTN *all* the time, not just some of it, similarly, streaming from network based servers could be made reliable by extending PBB-TE connections from the net-side server back out to the customer premises equipment.

This is a longer-term view, of course, and in the first instance, the core of carrier networks will be addressed, as this is the most sensible first step. The question I'm now pondering is how we get PBB-TE capability embedded into standard linux applications and perhaps into the kernel, too. Because, until we fix that, internet streaming is n n n ne neve ...