First time I’m doing ping-pong on a blog … but I need to respond to MJ Ray and I can’t leave comments on his bog.

He’s worried that I’m using the word “pragmatism” to defend my ideas. He also defines himself as pragmatist… and that’s right. Most of us choosed free software because that was the best option for us. We’re all pragmatists in that sense.

Part of this common pragmatism is to be able to fix things when they go wrong. Right. However pragmastism doesn’t mean that we should be able to fix things where nothing can go wrong.

What do you want to fix in the Firefox logo ? in its name ?

Of course, that doesn’t apply to firmwares, they may contain bugs and we might be interested to fix them. However removing them serves no purpose : users don’t have working drivers, and free replacements won’t appear just because we decided to remove them.

Pragmatist means that *we compose at best with what currently exists*. You can’t take into account “uncertain future outcomes”. We take what works now and if something better (in terms of freeness and in terms of quality) comes later then we replace it. We can’t anticipate with what’s going to happen.

That’s my vision of pragmatism applied to Debian. That’s why I believe my proposal makes sense. I do not propose to include arbitrary non-free stuff but only things which are __useful__ to existing free software. I’m happy to discuss further how to define more precisely the scope of “useful” in the above sentence.

This was expected. One of the most radical Debianer (Mj Ray) tried to contradict the arguments I gave in my previous post about the original meaning of point #8 of the DFSG. And clearly without historical background, the interpretation of that point can lead to confusion. (Hint for Matthew: That’s why arguing with him is worthless right now.)

Can we then try to correct the formulation of the DFSG to avoid problems like the one we have now ?

I don’t have a patch ready for proposal but I can explain quickly what I have in mind. And if I get some support I may even try to draft a general resolution…

Contents (possibly non-free) which would serve the purpose of a free work and which are freely redistributable could be accepted into main together with the free work in question.

Of course the limitations of those “contents” would be documented in the copyright file of the package.

This idea solves all our current problems :

• with trademarked names and logo : we can use them;
• with firmwares : clearly firmware are non-free contents that serve the purpose of free drivers;
• with GFDL document with invariant section : the invariant section is non-free content serving the purpose of the free software documented.

Would this exception be a disservice to our users ? I don’t think so.

For the pragmatic point of view it’s clearly a win, we can keep the names of well-branded software, we can have drivers working out of the box and we can keep the most valuable documentation we actually have.

From the philisophical point of view it may look like a step backwards, but it’s not. Non-free content is only accepted if it serves the purpose of a free work. And I used the term “content” on purpose, a “program” would not qualify as “content”. Otherwise a non-free software enhancing a free software could have been accepted. But clearly that’s a no-no. We’re about “free software” and that’s what matter for us, so we do our best to spread them and this may require to distribute them together with useful non-free contents.

We probably also need to write a special documentation describing in more length the spirit in which each point of the DFSG has been written and clarify with recent history what is commonly accepted behing each buzzword (i.e. “work” can be program, textual content, multimedia content. and other points like this one). But that’s for later I bet.