inamerrata

Issue 19

19.1: Do the decompilation amendments achieve the intended balance between owners and users of software?

One of the considerations of the review is the changes to the copyright act made back when Y2k was looming. These changes concerned allowing users to demcompile programs they own for compatibility reasons, and to fix bugs in them if the copyright owners weren’t doing that. This was considered fairly important when the Y2k-bug was going to destroy civilisation, but has gone back to being something of a niche field now.

Interestingly, it seems to be so niche that the review team apparently hasn’t received any information about the results of the clause at all. Hopefully the various interested parties will be defending their turf.

The issues paper makes a couple of points about this, including:

6.3.5 There is a concern that [the qualifications on the exemptions for decompilation for compatibility and debugging abandoned and orphaned software], in effect, provides exclusive rights to all commercial and non-commercial clones, derivatives, extensions and patches in relation to the original software.

6.3.7 Also, users’ interests have suggested that it is not clear under these provisions the extent to which educators, researchers and technical journalists can decompile an application, examine the source code and publish or otherwise communicate the findings of their research and include illustrative small extracts of the code without infringing copyright.

This area is certainly interesting, because, hey, decompilation is just plain fun. And Australia happens to be one of the safest places to do it, too. On the other hand, it’s not very common or useful in some senses, because it’s just plain so hard to do; analysing code that’s meant to be read by humans is hard enough, analysing code that’s written for machines, or deliberately obfuscated is beyond even most professionals. The Samba team, who do some of the best and most useful reverse-engineering for compatibility purposes on the planet, specifically avoid doing decompilation both to avoid legal risks and to ensure they’re not distracted by any poor coding in the product they’re trying to be compatible with.

Given both the absence of harm to copyright owners, and the limited utility of the clauses, maybe this is something to consider extending, instead of just defending?

19.2: Are any further amendments required to include other exceptions or to clarify the existing exceptions to the definition of “infringement” (as referred to in this section) to better preserve the balance between owners and users of software, including the extent to which, if any, there are issues with use of or access to orphaned or abandoned code?

An interesting further amendment in this area is mentioned immediately beforehand:

6.3.8 […] Nor has any data been made available to the review that present solutions to any problems that are identified […], for example, the creation of a “code repository” where source code which is either live (and therefore possibly under escrow), abandoned or orphaned code could be stored and the administration and the licensing of source code from such a repository.

This is very similar to one of Lawrence Lessig‘s pet ideas — that copyright owners should be required to submit their source code to the government, so that when the program enters the public domain they can make modifications without having to do decompilation. Lessig links it to copyright terms in two ways — one, that copyright terms should be shorter for them to have any relevance to software, which rarely continues to be useful for the entire length of its current term; and the other that software should simply not attract any copyright without source code escrow.

It would certainly be useful for dealing with abandoned or orphaned code; bug fixing with the source code is hard, but much easier than without. Managing such an archive might be tricky — authors would certainly be very leery about giving out their source code. On the other hand it might make an effective counter to one open source argument: hey, if we go away (which we won’t!) you can get the source code from the government anyway! A government policy of not using software that’s not escrowed in such a manner could go some way towards providing an incentive, without being unreasonably protectionist.

One way of handling such things might be to have a policy that after ten years, copyright will only be enforced if the copyright owner can be contacted, and is willing to continue providing the product (for a reasonable price presumably?). Having a centralised copyright database would make this easier — both for users, as they have a simple place to look for the author, and for authors, because they only have to inform one person that yes, they’re still here and still want their copyright. There may be problems with this sort of rule and the Berne Convention, however, which requires copyright to be automatic, and last for fifty years after the author’s death.

The issues paper also points out that when fixing bugs in programs abandoned by their owners, customers can’t share their fixes, and asks:

19.3: Is any clarification required in relation to the application of the existing amendments to the following particular circumstances:

• the publication of research undertaken under the exceptions; and
• the distribution of programs and error corrections created under the exceptions.

If the issues paper is correct that customers can’t collaborate on fixes for abandoned software they both happen to use (which I wouldn’t have guessed from the act itself, but they don’t seem under any doubt, and unlike me, they’re lawyers…) then that’s probably not good.

One of the difficulties in making submissions for this review is they expect arguments to be supported not by opinions or petitions but rather by solid economic arguments and data. Curse them!