Archive for July, 2008

Victorian Inquiry into Access to Public Sector Information

The Victorian Parliament has recently announced it is conducting an inquiry into Improving Access to Victorian Public Sector Information in which they specifically want to cover creative commons and open source licences.  They have produced a 75 page discussion paper.

It is important for the open source industry to be heard on this issue (and to create collateral for submission to other, similar inquiries), but without funding someone to draft a submission it is difficult to see how an adequate submission could be put together.  Specific vendors might be able to put in partisan submissions I guess.  How will the industry address this?

Submissions are due by 22 August.

Advertisements

Piracy and Malware – Pfft!

Piracy and Malware – Pfft!

Brendan Scott July 08

A frequent meme in piracy trash talking is that piracy is linked to malware (example). If your child is downloading pirated material (so the argument goes) they will be downloading it from a malware infected site and infecting their own computer resulting in poor performance, data loss and ID theft.  A variant of this argument is that the downloads expose the kids to evil pornographers.  Therefore piracy is bad and the government should pass laws to stop it.

Neither malware nor pornography is present on legitimate sites. If children are avoiding legitimate sites it is because the prices charged for the material are unreasonably high. It is these high prices (combined with marketing and network effects driving demand for these products) which are causing children to visit illicit sites to acquire software. No children are infected by malware when acquiring open source software. There is no pornography on open source websites. All open source software is legitimately available from legitimate sources. If all software was open source, this problem would not exist.

Increasing penalties for infringing copyright will do nothing to change this dynamic. Indeed, it will make it worse. Any expansion of copyright further, or more rigorous enforcement of existing rights, simply insulates copyright holders from competition, permitting them to raise their prices further, thereby pushing more children towards illegitimate sites. Increasing penalties or enforcement in the hope of reducing malware infections would be like pulling the control rods out of a reactor in the hope of shutting it down. It is exactly the wrong thing to do.

We can concede that malware infecting children’s computers is not only a serious problem, but also a problem on which the government ought to take action. However, further subsidising the closed source software industry is not the solution – these subsidies are the problem. If government wishes to protect children from these evils it would use only open data formats for data storage and interchange and strongly promote the widespread adoption of open source software.

Annoying Wiki Registration Requirements

The current wiki for iTalc – a really interesting looking (I haven’t installed/used it yet) piece of software for managing student workstations – says to see the INSTALL file in the source tarball if you want post-install set up instructions on Linux.  Since you’re supposed to be able to download precompiled binaries for several packages I thought that it would be better if these contents (which describe how to set up iTalc post-install)  were replicated to the wiki.   So I tried to edit the page – only you have to have an account to do that.  So I try to create an account quickly.  I don’t include my email address (since it says on the create account page that it’s optional).  But it doesn’t allow me to edit unless my email is confirmed.  So, back to the preferences page to have an email confirm sent to me.

It says it’s sent the confirmation email… but it still (having typed this post) hasn’t arrived at this end.

So, what should have been a 5 minute edit has turned into a 15 minute struggle just to set up an account.  Now I’m giving up.

Surely a small project like this isn’t being bombarded with so much spam/false edits that it can’t have an easier editing process for small changes?

Thanks Readerware

One of my pet hates about closed source software is registration codes.   In order to install software that you’ve legitimately bought, you need to find the relevant registration codes.  If you’ve misplaced them (eg you’ve moved house, or you have kids) then you can kiss goodbye to  however many hundreds of dollars you spent on the thing.   Even if you haven’t lost the codes it can take anything from 5 minutes to hours to actually find them again.  Several years ago this was such a hassle for me when upgrading or changing my system that I decided to foreswear closed source apps to the extent I could.

I made one exception, when we moved house a couple of years ago.  I bought a program called Readerware* to catalogue our books before we moved  – a vain and thankless task but, now it’s done, I thought I might update it with the books we’ve acquired since.  So I dug up my old version of readerware from one of the backups to find that it didn’t seem to work on my current system (which has evolved a bit since then, particularly in May this year – I think it is looking for a 32 bit version of glibc).   I even had the CD – and the registration code.

On a whim I downloaded the most recent version of the product and entered my registration code – it worked.   I had to pay for neither the move to 64 bits nor the new version of the product.  How nice (there is no fee for upgrades within major releases 1, 2, 3 etc – the current version is 2.984).  Thanks Readerware.

I now face the task of identifying what files I need to copy to restore the database… (done) and find what box I put the neat bit of the dot bomb (see below) in.

PS:  I even got a neat bit of the dot bomb at no extra cost when I bought the package.

* At the time Alexandria was a no-goer, although it seems to have come along since then…

The Invisible Closed Source Overhead – 2

Brendan Scott, July 2008

Acquisition Costs

Acquisition – Internal Requirements

Because of the Tragic Closure of closed source software, a purchaser is typically required to make a decision to buy one of a range of products, each with overlapping feature sets and other characteristics (rather than, for example, buying one at random and supplementing the software with third party or custom built components to cover any feature gap involved).  In such an acquisition therefore, a wrong decision can end up being very expensive. As a result the decision process becomes invested with much more weight than it really ought to.

How do you know what you’re buying?

When drafting any contract, the drafter is faced with something of a philosophical problem – how do I describe the obligations on the parties.  In particular, if acting for a purchaser, how do I describe the thing being bought?  In many cases this is done by establishing a some form of enumeration (for example, you might use the serial numbers on equipment to describe them).  Sometimes it is simply a general description of the purchased item (eg a slotted screwdriver).  This is important because if the vendor supplies something you weren’t expecting, then it will only be a breach of the contract if the item has been correctly described there.

In the world of physical items making sure the description is correct is comparatively easy to do because a visual inspection of the device will quickly determine the issue.  For physical items this is primarily because, while it may be a complex marvel of engineering, it usually only has a limited number of characteristics which are relevant.  Moreover, often a vendor will provide a sample of the thing, so the contract can reference the sample provided (for example, a certain make and model of car).  Compliance with these contracts are comparatively easily verified by the purchaser.  For example, you will know if the wrong make or model of car has been delivered to you.

The same is not true of software.  Software is often “sold” (a misleading term, since it isn’t typically sold) by signing a licence agreement with the person acquiring the software.  The licence agreement needs to first identify what is licensed, then it needs to decribe the scope of the licence.  While the second part is comparatively easy, the first entails some difficulties.  For example how would a purchaser verify that they have received the right software?  If the licence refers to a different thing to what has been loaded the software is unlicensed.  If you sign a licence agreement for (eg) Software version X when you buy a computer how do you know that that is the copy of the software which is actually installed?  If it says “version X” on the splash screen, is that enough?  Logically it isn’t.   In fact, what constitutes version X is determined arbitrarily by the maker of the software (well, not entirely arbitrarily, its determined by what will likely maximise sales).  You don’t even have access to the gold masters to verify that what you have is the same (even if you did your supplier has probably customised some things for you, so it would be unlikely to be exactly the same).

Writing Specs

For a small purchaser this is typically a leap of faith.  They simply assume that the licence corresponds to what has been installed. Its functionality is typically too complex to verify for themselves (and for new software, they are unlikely to even know what it is they are looking to verify).  Larger purchasers address this problem not by identifying the software, but by identifying its characteristics.  That is, the contract says (in effect), I don’t care what you give me, as long as it complies with the description at the back called the Specifications.   What comprises the specifications varies depending on the circumstances.  In theory, the specifications are a detailed description of what the software does and how it does it.  Specifications can also be used earlier in an acquisition process to cull inappropriate software or determine the vendor who will supply the software.  The trade off involved when drafting specifications is of detail against certainty.

If you are a company of any size, then management will require that the contract be reasonably specific about what it is that is being acquired and the terms of use.  This means that a precondition to securing a licence is having an adequate specification for the software.  This, in turn means not only money spent on developing a specification (assuming it’s not “complies with the documentation”, which, by the way, has some substantial risks) but also time.

The creation of a specifications document means extra work for the acquiring organisation.  If it is not identified early enough, this work can start happening at the time the acqusition is being negotiated.  This means that the specifications are drawn up in parallel with the contract.  This is not necessarily a bad thing (apart from the fact that it is a key document defining what it is that is being acquired), but it means that the contract shouldn’t be executed until the specifications are completed (sometimes this is fudged at the acquirer’s risk).

These issues do not arise in the open source case because there is no risk that the software will not be delivered, or that the software which is delivered will be different from what has been reviewed (since they are one and the same thing).   A company may want to create specifications for their own internal purposes, but such specifications will not need to be at the level of detail required for an effective contract.

Look-ahead Costs

If your vendor has different licensing terms and/or, (more likely) different licensing fees depending on some aspect of your implementation (eg is it virtualised, run on a certain sort of hardware, distributed or updated in a certain way etc) this raises additional costs.  These are costs of attempting to anticipate your organisation’s actual needs and making sure either that the scope of the licence is broad enough to cover those needs or that there is some ability to upgrade the licence in the future to do so.  In each case this is likely to involve additional licensing costs – costs which may not be utilised in the future (eg if, as it turns out, you don’t need the features covered by the licence extension).   If a licence extension is not sought it is likely to also involve additional soft costs.  You may, for example, need to restructure a deployment because you have chosen to forego certain features to save on licence fees.   This involves at least an opportunity cost because you can’t use those features in your organisation, and it may involve additional internal costs of having to re-engineer the solution (eg to accommodate the missing functionality).

Over time, many of these cases turn out to involve additional costs simply because it is very difficult to foretell the future.  While at the time of acquisition the organisation may well have thought it had no need for feature x, in three years time the world will have moved on and feature x may now be extremely important (and perhaps more expensive to licence, and, of course, with an increased opportunity cost until the feature is acquired).  In the worst case scenarios a decision to forego functionality can result in a solution design which forecloses that functionality, or requires substantial reworking to implement.

Acquisition Delay

An contract negotiation typically takes a long time, much longer than either of the parties anticipates (although their lawyers will probably have a pretty good idea). Where there is proper will on each side a contract negotiation can go very quickly, but this is usually not the case. If you’re dealing with a large organisation then the chances are you will be presented with a contract and you get the choice to take it or leave it. This makes the contract negotiation process speedy indeed!  Just as with feature sets, the contract terms are designed on an 80-20 rule and, moreover, are designed to inherently favour the vendor (exactly just how biased they are varies from vendor to vendor). If you’re one of The Many for the contractual terms, then no problem (I note here that there is not necessarily any correlation between The Many for features and The Many for contractual terms). If you are one of The Few, this may cause major problems because the consequences for copyright infringement are now completely disproportionate to the loss which such infringement occasions. Indeed, infringement in a commercial context can carry with it criminal liability.

For example, licensing of software often assumes specific business models and matches the licence to the vendor’s expectations of the model. If you have a different business model the licence terms will prohibit it.  In the past many people would have signed the terms and ignored them, making the pragmatic assumption that if the vendor is paid, they don’t much care about whether or not you’re complying with the licence. With the introduction of criminal sanctions for infringement this option changes becomes extremely high risk (because a vendor has a discretion to pursue a civil infringement, but no discretion in respect of a criminal one and these actions will typically be initiated by a disgruntled employee).

Going through a licence negotiation then involves educating the vendor about your business model and convincing them that they should be willing to change the terms of the licence to accommodate it. Because these things are typically outside the scope of authority of the people typically tasked with negotiating the terms, these aspects need to be passed back up the chain within the vendor – causing delays. The overall process can be both lengthy and time consuming. Note: industry sectors which are highly regulated face similar challenges when negotiating with their vendors.

While the ideal situation is for organisations to get all their licensing ducks in a row before commencing on a project, it would not be unusual for this to be left until the proverbial last minute. This often puts undue pressure on the contractual negotiations (ie to not press sufficiently on specific issues). Where the licence terms are inconsistent with your business model giving up on some contractual terms is not an option (because to do so would invalidate your model). The only options are to push your way through negotiations or give up on the model/product. However, this means that whatever dependencies there are on the product (eg your product release) will likely be blown out and you still face the prospect of last minute re-engineering to back the relevant component out and either replace it with something else or live without the functionality (if the licence negotiations are not successful,  or are not quick enough).

If the software is for inclusion in a consumer device this sort of delay can be fatal.


Blog Stats

  • 240,253 hits

OSWALD Newsletter

If you would like to receive OSWALD, a weekly open source news digest please send an email to oswald (with the subject "subscribe") at opensourcelaw.biz