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

[Chris Croughton]

On Tue, Jan 06, 2004 at 10:25:52PM +0000, Mark Preston wrote:

> FWIW I agree with what Nick Hill has written. Free software (FLOSS) can 
> be modified and kept secret, it's just when you start to redistribute 
> your modifications you are obliged to give the recipients the same 
> rights as you received when you started using the software. Once you 
> start interfering with this process signing away your rights by agreeing 
> to proprietary software licenses you no longer have the security of 
> knowing what is being done to the software you are using.
> I wish I was as trusting and as capable as Chris Croughton, but I'm not.

Me, trusting?  It is to laugh.  I know that the formats of the
propprietary programs I mentioned are 'open' because (a) they wouldn't
work if they weren't using the established formats and (b) I have looked
at the data (if you ren't cable of doing that yourself you can hire
someone who can).  Another example is with CAD/CAM, the formats are open
because every application in the area has to be able to accept data from
the others, so I know that I'm safe in buying whichever one I like (I
just have to check for the relevant keywords, and if they aren't there
as supported I know the product is substandard).

> Here is a practical example of how things appear to me to be going in 
> practice as far as proprietary software is concerned. This is exactly 
> what I believe Nick Park is alluding to in his posting. Legally the 
> proprietary software licenses are becoming more restrictive to users, 
> not less at the current time.

Some of them.  Not all.

> Problem:
>   I am a [CompanyA program]  user and wish to export my clinical notes 
> to another application. [CompanyB]  tell me they cannot do this as the 
> notes are encoded using an algorithm, yet they can export the notes to 
> [their program]. I want to have the freedom to chose my own software 
> provider.  [CompanyB] could not even answer my question as to whether it 
> would be possible to export from  [their program] to another application 
> if I did not wish to stay with them is a few years time. Before 
> [clinicians] commit their clinical notes to a computer system they 
> should realise that they will become tied into it. If they move to a 
> different company they may not be able to access their notes in a few 
> years time and not from that software.

Yup.  So what you need is open /standards/, preferably backed up by an
official body of some kind.  And then you need to hold your software
provider -- proprietary, "open source" or "free software" -- to those
standards, and write in your contract that that's what they will
provide.

> [CompanyA program] will not run 
> on future windows sytems and windows 95 and 98 cannot be run on modern 
> computers.

Huh?  Windows 95 and 98 can't be run on modern computers?  Where do you
get that from?  I have seen Win98 running fine on both AMD 3000XP and on
Pentium 4 computers (in fact Win98SE is the latest version I'm willing
to run of the 'domestic' versions, NT4 the latest of the 'professional'
ones).

> Will your old PC stored in the attic fire up in 10 yrs time 
> when you have a medico legal problem? Be warned!

And how does this differ if the source is available?  Sure, you have the
source code from 10 years ago, what are you going to do with it?  Will
you understand it?  Will anything else even read the media your data (or
the source) are on?  Hint: a lot of programs written with pre-ANSI C++
(for instance using gcc 2.95.x) won't compile on the ANSI-compliant gcc
3.x.

For that matter, would you even have the source?  Do you always get and
archive the source of every package you install?  I don't -- I often
fetch it but I don't archive it for 10 years.  Sure, the source for free
software is available (for up to 3 years, I think the GPL says) but how
many people bother?

(And if you have 10-year-old data which you can only read on a machine
you haven't fired up in the last 10 years and yu need it urgently, you
have bigger problems than whether you have the source code or not!)

> My Analysis:
> This may be a deliberate policy on the part of [CompanyB]. [CompanyC - 
> formerly the company with the largest userbase] used to use Btrieve (now 
> Pervasive) and as such the DBMS was available to any programmer/company. 
> [CompanyB] who have taken over [CompanyC] uses it's own proprietary 
> DBMS, I believe, and have presumably started converting their takeover 
> customers to this. One of the best ways of increasing your market share 
> as a "closed-source" software company is to make sure that you can 
> import data from as many of your competitors databases, whilst at the 
> same time making it as difficult as possible for your database data to 
> be exported. Is this is what they mean by algorithm? If I'm mistaken 
> about this then I hope someone in the know will correct me. As you state 
> this leaves [clinicians] in a pretty poor position, essentially 
> "locked-in" once they have signed to use the software.

I don't know what they specifically mean, and (being paranoid) I suspect
that they are indeed deliberately "locking you in".  Which you have let
them do by not insisting on the protocols, formats etc. being open.

However, you have missed my point.  I do not claim that no proprietary
software tries (and succeeds) to lock in the customers.  What I object
to is the claim that /all/ proprietary software does this, and that the
only way to avoid it is to buy 'free' (or open at least) software.  That
latter claim is not true.  If you make sure that the software you use --
/whatever/ it is, proprietary, 'open' or 'free' -- conforms to open
standards then you will avoid being "locked in".  I can safely buy a
CAD/CAM package, for instance, knowing that it will at minimum input and
output in the standard Gerber format.  I can safely buy a web browser
which conforms to the HTML (and other) standards (and if it says that it
does and it doesn't then it is breaking trading standards and is
fraudulently advertised and I have the law on my side).

Your problem is that you bought (or had produced) software without
ensuring that it adhered to open standards.  Whether it is closed or
open source is irrelevant to that.  Yes, if it's open source then you
might find (or be able to pay) someone to convert it to some other
format for you, but at the least that will cost you a lot of time and
probably a lot of money as well.

If the product adheres to the appropriate open standards, for its
interfaces, protocs, formats etc., then there is no problem whatever its
'openness' state.  If it doesn't, you will have problems whatever its
'openness' state.  Yes, being open source may make it possible to
(eventually) convert it if needed, but whether it will make much
difference in feasibility is a different matter...

Chris C