LawFont.com

As I said in my last post, there are two issues that people have been hassling me about. One was Lexmark. And the other one is whether the interoperability provisions are useless.

My thoughts on the interoperability exceptions? In short, the Exposure Draft is even less generous than the US law in the form of the DMCA. In the US, you get to distribute interoperating programs – in Australia, arguably, you don’t. amazing. and very much needing to be fixed, methinks.

To my mind, interoperability is one of the hardest things to think about in this space. Because when you say “we have provisions that allow people to make interoperable programs”, you have really to work out – well, what do you mean by interoperability here? Because I think there are different types of interoperability, and the needs that you might have in making interoperability real have changed over time.

Let’s go back for a minute. What does interoperability mean anyway? According to the CLRC, interoperability means this:

Now, back in 1994, when the CLRC wrote that, it was operating in days pre the widespread contemplation or use of DRM type technology. The CLRC believed, at that time, that all that was necessary, to make an interoperable program, was to decompile the program to work out the interface information necessary to allow new programs to interact with (exchange information with) the existing program. This is obvious from their report:

Section 47D, the Copyright Act’s interoperability exception, is very much written with this in mind. Section 47D provides that a reproduction is not an infringement if:

1. it is made by, or on behalf of, the owner or licensee of the copy of the program (known as ‘the original program’)
2. it is made in order to obtain information necessary to enable the owner or licensee to make independently another program (‘the new program’), or an article, to connect to and be used together with, or otherwise to interoperate with, the original program or any other program
3. it is made only to the extent reasonably necessary to obtain the information
4. to the extent that the new program reproduces or adapts the original program, it does so only to the extent necessary to enable the new program to interoperate with the original program or the other program; and
5. the information necessary to interoperate is not readily available to the owner or licensee from another source when the copy is made.

So you can see that the whole exception is structured around obtaining interface information (and, perhaps, reproducing some of it).

The interoperability exceptions in the Exposure Draft are written the same way. The ban on circumventing (s 116AK), on selling circumvention devices (s 116AL) and providing circumvention services (s 116AM) does not apply if it does done to enable a person to do an act which will:

1. be done in relation to a non-infringing copy of the original computer program;
2. not be an infringement of copyright in the original program;
3. will be done for the sole purpose of obtaining information necessary to achieve interoperability of an independently created computer program with the original program or any other program; and
4. the information is not, or will not be, readily available to the person from another source when the act is done.

Pretty much a match, as you can see – and the reference to ‘no infringement’ harks back, one would think, to section 47D. So, if you need to get past a TPM in order to get the interfacing information, well, that’s all very well.

But here’s the issue. Imagine this situation. What if you do all this, and you write the interoperable program. But what if, to interoperate, your independently created program needs to perform some kind of ‘secret handshake’, or authentication sequence, in order to work with the program. That, you would think, involves a circumvention, right? Your independently created interoperable program might be a circumvention device, right? But look back at the interoperability exceptions in the Exposure Draft. It doesn’t go that far, does it? It doesn’t do anything to say – and once you’ve written the program, you can distribute it.

The situation I’ve just outlined isn’t particularly far-fetched. Imagine that you are creating a program that is going to communicate with a server, and the server is a Microsoft server. Your client program may well have to do some kind of sequence, which could well be a TPM. That, I think, is potentially pretty problematic.

What do they do in the US? Well, interestingly, if you look at the DMCA, their exception looks decidedly broader. I’m going to quote it in full:

That’s a lot of language, but the key bit is in subpart (2) – the bit I have put in bold. You can see, from that, that the exception applies to obtain information or (and I repeat, or) or for the purpose of enabling interoperability of an independently created computer program with other programs. In summary, then, under US law you can circumvent to write the interoperable program, and you can sell your program even if it circumvents, as long as it does so only to interoperate. Under Australian law, you can circumvent to write an interoperable computer program, but arguably, you cannot distribute your interoperable computer program. How utterly useless is that?

This has to be fixed in the Australian draft, or we are left, I suspect, with a pretty not-useful interoperability provision.

There is, of course, a third type of interoperability, which I’ve so far left to one side. And that is what you might call ‘format’ interoperability: this is where a person wants to write a new program that will read data files created by an original program. Basically, this is where you want to, say, write an open source program that will read Microsoft word documents – or a DVD player that will read Hollywood movies, or a program to play iTunes songs. If you go back to our definition of interoperability, such activities would seem to fall within the literal reading of the definition:

But even though the kind of format interoperability I described above might falls within the literal definition of interoperability, there is still some significant room for controversy here. I’m not a programmer, so I’m not sure whether programmers would draw a distinction between a program that ‘exchanges information with another program’ and a program that reads data formats like Word files or iTunes files. But I think that policy-makers would draw a distinction (indeed, in their Feb 06 Report, LACA did draw a distinction here, making the following Recommendation 15 on interoperability:

This last form of interoperability? I’m not sure where it lies. It’s not included in terms in the legislation. It might be covered in some circumstances by a reading of the existing exception. Although that reading – which would be a broad one – might be precluded by the LACA legislative history which distinguishes between the forms of interoperability.

What a court does would depend, I suspect, on how the courts end up reading the exceptions drafted. There’s a problem though. From a policymaker perspective, you might want on the one hand to allow the making of programs that will read things like Word documents or Excel files, because otherwise, it’s very difficult to compete. On the other hand, you might not be so keen to allow the writing of programs to read DVDs, because of the fear that people will write a program that reads – and copies – DVDs. The first scenario might be taken care of, however, by the requirement for liability that a TPM be applied to a work by, with the permission of, or on behalf of a copyright owner. That would be true of the protections on DVD movies, but would it be true of any TPM that a program like Word might apply to documents? What is more, it may not be clear that any TPM applied by a program like word is aimed at preventing or inhibiting an act of infringement – which means it wouldn’t be an ACTPM at least on the Exposure Draft definition.

In summary, for this last form of interoperability, I’m not sure just where we are at. But it’s definitely something to keep an eye on.