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

[Mark Preston]

Hi all,
Chris Croughton wrote:

> 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.
>  
Agreed. But most official bodies have got their snouts in the trough 
already though, and you can include governments.
A lot of the software industry is built around "de facto" standards and 
"killer apps".

>  
>
> > [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).
>  
I think the point the complainant was trying to make was that the 
program he was currently using wasn't going to be upgraded to run on Win 
95, ie it probably was a program that runs only on DOS. Without access 
to the source code the user hasn't the option of paying a programmer to 
upgrade the program.

>  
>
> > 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!)
>  
You're missing the point here too. The point is that companies in a 
position of power gained through use of proprietary software programs 
will ensure that they use this power to maximize future revenue streams. 
They certainly don't use it to encourage easy upgradability and easy 
data export to other rival programs.

>  
>
> > 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).
Agreed.

> Your problem is that you bought (or had produced) software without
> ensuring that it adhered to open standards. 

Not my problem. I never used company A B or C programs in the above 
example, but if I had used CompanyC (formerly the company with the 
largest userbase and using an open standards database) then I think I 
would have some grounds for being disgruntled at the turn of events.

> 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.
Indeed, but if it's closed source you can't even pay somebody. So 
therefore "open-source" is highly relevant

> 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...
>  
In my view it makes all the difference.

> 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).
>
>  
Try this. Take an OO.o .sxw file and put it in a directory all by itself 
under Linux. Open the directory by visiting it with using a bash shell. 
Type
unzip OO.o .sxw at the prompt.
Still having problems exporting from OO?
Regards,
Mark Preston