Hi!

How can a system integrator protect itself in a
situation when they implement an application based on free or open source software and does a start-up and a handover to the client? Besides, it provides the source code to the client. Suppose that the client modifies the provided source code and this results in an accident or simply poor performance. How can the system integrators be sure and, taking it to the extreme, be able to prove in the court of law, that the original source code had been modified and a flaw had been introduced (deliberately or not) by the client?

On one hand, the idea of OSS should enable the client to make modifications. On, the other hand, the contractual warranty should be null and void in such case and the system integrator should bear no responsibility or, according to the circumstances, this responsibility has to be limited.

My solution is to calculate md5 sums of the code and put them in the project handover document. Besides, these md5 sums should be registered (time to time) to log files.
Can anybody think of a better solution? The logs may be tampered, too...

Andrey Romanenko
[email protected]

 

Your situation has nothing to do with whether the software is genuine libre "open source" or just a run of the mill "work for hire". The identical question could arise whenever source code is delivered to the customer (i.e. most consulting projects). Most software projects of any type get delivered with full source to the company that is paying all the bills. If I hired someone to do a custom software project, I certainly wouldn't pay them until they handed over the source.

Your question is a legal issue, not a technical one. If you are really concerned about this, you need to consult a lawyer in whatever country you happen to live and work in. The question isn't so much how could you technically show that something had been changed, but rather what are the
courts in your country prepared to accept as evidence? If this is a serious concern, you may be able to deposit a copy with a credible third party (e.g. a lawyer or someone similar) who can produce it as evidence in court. This
situation shouldn't be too much different from being able to prove that a copy of a contract or engineering report is a true copy.

The MD5 idea sounds nice, but it isn't going to do you much good if a court doesn't view it as being the sort of evidence that they can clearly understand. It may however be of help in keeping the case from going to court in the first place by being able to show a customer that your copy (source *and* binary) matches what you said you delivered while their current version does not. Not having to go to court is better than winning in court.

Something else that can help your situation is to establish formal, documented software development procedures. In other words, you would need to show that you have careful, methodical working practices. You would need to store the source and build parameters properly, and be able to track versions. CVS or something similar would probably help quite a bit in establishing an audit
trail (remember to keep regular off site back-ups). Keep written records of every version you install or test at the customer's premises. Good record keeping may count for a lot more in a lawyer's eyes than purely technological
means such as check-sums.

Companies that sell "shrink wrap" commercial software avoid these problems by refusing to offer any warranty or accept any liability for their products. They won't even guaranty that there is any software on the disk they sell
you. This sort of attitude probably wouldn't go over too well with your own customers however.
--

************************
Michael Griffin
London, Ont. Canada
************************

 

Hi Andrey,

One option is to burn an image of the file system onto CD (or DVD if necessary) at the time of handover. Then if their's an issue just check against this.

Regards

Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 

Is this really a problem? I had the impression that most clients prefer their applications implemented in such a way that poorly-qualified maintenance personnel can change them at 3am...

(Actually, the maintenance personnel are generally well-qualified, but in a different field. Getting a car mechanic to fix your shoes works about as well as getting a cobbler to fix your car.)

In any case, you can password-protect the programming interface, or place a physical seal on it. In cases where safety is involved, the seal would probably be the best approach, and may even be mandated by the relevant safety board.

Other physical security is also a possibility; for instance, for PC-based applications, if it's loaded from a CD-ROM, altering it will involve switching disks. This may be the most practical approach for PC-based applications (in combination with locked and/or sealed cabinets).

At that stage, the OSS nature of the work is purely a guarantee to the client that they can change suppliers at will, or even just an artefact of the development software used in the application.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Michael,

Thank you very much for your input and please see my comments below.

On March 15, 2004, Michael Griffin wrote:
> Your situation has nothing to do with whether the software is genuine libre
> "open source" or just a run of the mill "work for hire".
> The identical
> question could arise whenever source code is delivered to the customer (i.e.
> most consulting projects). Most software projects of any type get delivered
> with full source to the company that is paying all the bills. If I hired
> someone to do a custom software project, I certainly wouldn't pay them until
> they handed over the source. <

Here I try to give a bigger role to OSS. When it is a custom project, the rules are as you described. However, suppose that there exists an good open source alternative to proprieraty control software. Using it you just do the implementation, integration, commissioning, and so on, just like it would be if it were an off-the-shelf proprietary product. You are right that most times the shrink wrap vendors issue a disclaimer to protect themselves. But, even in this case, the system integrator will be held liable if something goes wrong. Open-source software allows additional flexibility, and I think it is good. I would like to give the source to the client not only because of a typical contract terms or because the client wants, but because I want to do it.

> Your question is a legal issue, not a technical one. If you are really
> concerned about this, you need to consult a lawyer in whatever country you
> happen to live and work in. The question isn't so much how could you
> technically show that something had been changed, but rather what are the
> courts in your country prepared to accept as evidence? <

It is both, actually. MD5 is a possible solution, be it good or bad. Another idea that I had was to sign the source with GPG (GPG). Lawyers don't need to understand technical details. They (and the courts) ask experts to do it. Any of us may be asked to give a technical opinion in court. That's why I decided to bring this question to the attention of this list.

> If this is a serious
> concern, you may be able to deposit a copy with a credible third party (e.g.
> a lawyer or someone similar) who can produce it as evidence in court. This
> situation shouldn't be too much different from being able to prove that a
> copy of a contract or engineering report is a true copy. <

Thanks, this is a possible solution. In my opinion, yes, this is a serious concern. We are reaching a phase where open-source software is becoming robust enough to be deployed in industries. It has shown its quality in the IT worlds, but the industrial sector is a completely different story with its own pecularities. We better first look around for possible gotchas before we dive into it.

> The MD5 idea sounds nice, but it isn't going to do you much good if a court
> doesn't view it as being the sort of evidence that they can clearly
> understand. <

I completely agree with you here.

> It may however be of help in keeping the case from going to court
> in the first place by being able to show a customer that your copy (source
> *and* binary) matches what you said you delivered while their current version
> does not. Not having to go to court is better than winning in court. <

Precisely. For that, you have to have technical means to show the client that its copy is different from what you had delivered.

> Something else that can help your situation is to establish formal, documented
> software development procedures. In other words, you would need to show that
> you have careful, methodical working practices. You would need to store the
> source and build parameters properly, and be able to track versions. CVS or
> something similar would probably help quite a bit in establishing an audit
> trail (remember to keep regular off site back-ups). Keep written records of
> every version you install or test at the customer's premises. Good record
> keeping may count for a lot more in a lawyer's eyes than purely technological
> means such as check-sums. <

Oh yes, the implementation of formal quality assurance systems not only help a lot to show that you know what you are doing, but also help you do it in a rigorous matter.

Once again, thank you very much for your opinion.

Andrey

 

Seems to have been mutual... What I was trying to say was basically what Michael Griffin wrote - that there's nothing specific to FLOSS here - except he wrote it much better than I and then went through the consequences from a different perspective (and one probably much more useful to you).

Like he writes, if you want to know how to prove something in a court of law, ask a lawyer.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools