fsfe-uk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fsfe-uk] Gnu/Linux and freedom (was Linux in Thailand.)


From: Chris Croughton
Subject: Re: [Fsfe-uk] Gnu/Linux and freedom (was Linux in Thailand.)
Date: Wed, 7 Jan 2004 01:04:45 +0000
User-agent: Mutt/1.2.5i

On Tue, Jan 06, 2004 at 11:34:25PM +0000, Nick Hill wrote:

> Chris Croughton wrote:
> > On Tue, Jan 06, 2004 at 11:18:51AM +0000, Nick wrote:
> > 
> >>Freedom is the key. If you use non-free software, you are binding 
> >>yourself to secret proprietary interfaces. The user interface is a small 
> >>facet of this. Bigger facets are secret data formats. Secret file 
> >>formats, secret authentication protocols, encoding your personal 
> >>documents in a form only one organisation knows how to or has the right 
> >>to decode. Extending control from one platform (eg desktop to server or 
> >>to PDA) by making the desktop clients only talk the secret language when 
> >>communication is needed.
> > 
> > Not true in many cases.  If I use a proprietary POSIX-compliant library,
> > say, how doe that bind me to "secret proprietary interfaces"?  If I use
> > (say) PDE, a proprietary (closed source shareware) text editor for
> > Windows, how does that bind me to "secret data formats"?
> 
> Of course proprietary software *can* conform to public interface
> specifications. Just that the most dominant proprietary software
> achieves dominance through not doing so.

I don't disagree with that.  But you wrote that "If you use non-free
software, you are binding yourself to secret proprietary interfaces",
which is not true in absolute.  It is true in some cases, certainly.  It
may be true in most cases, or even in the vast majority of cases, but it
is not true as an absolute statement as you made it.

The proprietary software which I use conforms to published interfaces,
protocols and formats at least to the extent I need it to do so.  For
instance, Windows (any version) contains unpublished APIs but it doesn't
affect me because I don't use them.  If there is something I can't do
using the published APIs then I'll find a different OS which does let me
do what I want because Windows will obviously be not the right tool for
the job.  The same with any other OS, programming language or other
tool.

> > All you are arguing for is open interfaces and protocols, the
> > implementations can be as proprietary as they like.  All you have to
> > do is verify them (or have someone you trust verify them) against
> > the public standards.
> 
> How better to achieve this than through using free software?

Using free software may be the 'best' way of doing it.  Or using "open
source" software may be just as good (if what you want is to do "code
walkthroughs" to verify its compliance with the published protocols
etc.).

But your claim was that all non-free software (and if you're using that
in the sense the FSF do then you are also including things which are
open source but which (for instance) have licences which insist on all
patches being copyright to the owner of the code) uses "secret
proprietary interfaces" etc.  That is just not true, as I have
demonstrated.  I can take the output from a proprietary Windows text
editor and read it using vi or whatever.  I can take the Gerber output
from a proprietary CAD/CAM package and feed it to any other.  I can take
MIDI files from any music package and feed them into any oter that I use
(I wouldn't use it if it didn't conform to that open standard).  And so
on.  I can't take an OO.o .sxw (or whatever it is) file and expect
anything else to understand it, even though it's "free software",
because it doesn't conform to any published open standard (sure, I have
or can get the source, but I don't have time to wade through it to find
the code which implements the format).

Open standards for protocols, interfaces, formats etc. are much more
important in interoperability than open source.  Sure, if you have the
latter you can get back to the former (eventually, and in the meantime
someone else can have tweaked it to do something different), but only
the open standards guarantee interoperability.  And if your package says
it conforms and it doesn't then it is broken, no matter whether it is
'free' software or not...

Chris C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]