Posts Tagged 'kernel driver'

Linux Kernel Drivers – AU Law on Interoperability

For those of you who haven’t seen it, some of the Linux Kernel developers have issued a statement on the use of closed source drivers in conjunction with the kernel (summary – it’s a Bad Thing ™).  My suggestion on this is that the interface for drivers should prohibit non-GPL drivers unless the driver’s author positively  asserts that the driver is not a derivative work.

This announcement has triggered off some discussions in mailing lists about how to determine whether or not something is a derivative work of the kernel.   Someone mentioned that derivative works should be functionally based, citing Linus Torvalds here.  I intended to chime in saying that the Australian High Court had actually said something like that some time ago, but then the short email got out of hand.  So now I’ve done a blog post on…

Some Observations on the Australian Law on Interoperability


Some time ago, the highest Australian court endorsed a functional analysis when identifying infringement of computer programs (ie if something is copied and is essential to the operation of a copyright program, then it’s an infringement), although it appears to have stepped back from this position more recently.

The current authorities still hold that the reproduction of a data set, even for the purpose of interoperability, will be an infringement if there is copyright in the data set.  Moreover, the courts have simply looked for a causal connection between the original work and the reproduction.  The re-implementation of a work by piecing it together from observation may still result in an infringement.

The legislature has introduced an interoperability exception but it seems to be worded in a way limited to reproductions for the purpose of gaining information – and therefore doesn’t seem to be a lot of help in practice.

The Australian position for the makers of device drivers is not clear.  There are particular problems when an implementation requires the reproduction (albeit indirectly and notwithstanding that it may be necessary for interoperability) of part of the kernel in which copyright subsists.  In this case there is a risk that the requirement to GPL may be invoked by virtue of clause 2(b).

Autodesk v Dyason

There is an interesting case in Australia called Autodesk Inc v Dyason [1] which held that copying 127 bits (yes, bits)[2] from a multi-kilobyte program (I have quoted 32Kb in the past, but now cannot find the reference – if you know please tell me where to find it) constituted a reproduction of a “substantial portion” of the larger program and was therefore a copyright infringement.

The 127 bits were in part of a chip in a dongle included by Autodesk in the package with their software.  The defendants observed the operation of the chip through an oscilloscope and used this information to produce their own dongle which mimicked the operation of the Autodesk dongle.  These bits were said to infringe the copyright in the program (called widget c) which queried the dongle.

Some interesting aspects of the case are –

  • this is a case about primary infringement of the reproduction right;
  • the dongle was a hardware implementation.  In response to queries by Widget C, it responded in a certain way based on the electrical operation of the various hardware gates in the dongle.  In effect it operated as a look up table, but there was no look up table “stored” in the device;
  • the relevant defendant had no access to and did not analyse the Widget C program.  They only analysed the dongle (see para 85 of the judgment at first instance);
  • there are in fact two decisions by the High Court, with the second on procedural issues.

The important part of the decision is that the court expressly took into account the fact that the key/bytes were essential to the function of the computer program. From McKeogh, Stewart and Griffith Intellectual Property in Australia third edition at para 8.6 (who, incidentally, criticise the decision):

“However, the emphasis on the function of a computer program as determining what is a ‘substantial part’ was maintained by the majority [of the court in Autodesk No 2 -see below], who emphasised that the [127 bits] was ‘essential’ or ‘critical’ to the operation of Widget C.”

This is a decision of the High Court – the ultimate court of appeal here equivalent to the US Supreme Court.

The defendants sought leave to the High Court to have the issue reheard (this is very unusual), the High Court gave judgement on whether or not to look at the issue again (ie, they were determining an issue of procedure, they were not re-examining the substance of the appeal) the following year.[2]   The defendants were unsuccessful (3-2) although the then-Chief Justice (in dissent) indicated reservations about applying a functional analysis when determining substantiality for the infringement of computer programs.  His reasoning was later to be cited with approval in …

Data Access v Powerflex

In Data Access v Powerflex the court unanimously stepped back from the “essential to the operation” analysis in the Autodesk v Dyason Case (only one of the Autodesk judges remained on the bench by that time – see her short concurring judgment at the end) saying this at paragraphs 84ff:

There is great force in the criticism that the “but for” essentiality test which is effectively invoked by the majority in Autodesk No 2 is not practicable as a test for determining whether something which appears in a computer program is a substantial part of it. For that reason, we prefer Mason CJ’s opinion that, in determining whether something is a reproduction of a substantial part of a computer program, the “essential or material features of [the computer program] should be ascertained by considering the originality of the part allegedly taken”

In order for an item in a particular language to be a computer program, it must intend to express, either directly or indirectly, an algorithmic or logical relationship between the function desired to be performed and the physical capabilities of the “device having digital information processing capabilities”. It follows that the originality of what was allegedly taken from a computer program must be assessed with respect to the originality with which it expresses that algorithmic or logical relationship or part thereof. The structure of what was allegedly taken, its choice of commands, and its combination and sequencing of commands, when compared, at the same level of abstraction, with the original, would all be relevant to this inquiry.

That being so, a person who does no more than reproduce those parts of a program which are “data” or “related information” and which are irrelevant to its structure, choice of commands and combination and sequencing of commands will be unlikely to have reproduced a substantial part of the computer program. We say “unlikely” and not “impossible” because it is conceivable that the data, considered alone, could be sufficiently original to be a substantial part of the computer program.

It follows that we are unable to agree with the approach to determining “substantiality” which the majority took in Autodesk No 1 and Autodesk No 2. Because of the importance of the question, we think that the Court should re-open the question of what constitutes a substantial part of a computer program. To depart from the reasoning in the Autodesk cases does not necessarily mean that the outcomes in those cases were wrong. In our view, the look-up table in Widget C was merely data and was not capable of being a substantial part of the AutoCAD program unless the data itself had its own inherent originality. However, re-opening the reasoning in the Autodesk cases does not require the Court to express a view on whether the look-up table in that case had its own inherent originality.

The Data Access case was about whether the re-implementation of a programming language (called Dataflex) was an infringement of copyright in the reserved words of the language.   Surprisingly, this argument was successful at first instance, but was eventually knocked on the head in principle, but not necessarily in practice in the High Court.   The reason it was not knocked on the head in practice is another look up table used to implement a compression algorithm which was at the centre of the case.

In that case the Dataflex program stored its program files in a compressed form.  A form of compression called “Huffman coding” which implements a lookup table was used to implement the compression.   The lookup table in this compression scheme is created by identifying commonly occurring strings in sample files.  In order to create a competing program which read the compressed files (or to create compressed files for use with the Dataflex program)  then it was necessary to reverse engineer, and re-implement the compression table.  The defendant re-created the table  by creating a number of test files and seeing how the Dataflex program actually compressed them (see paragraph 117).  The court found that the original compression table was a literary work and that re-creating it in the manner described was a reproduction (para 124):

The fact that Dr Bennett used an ingenious method of determining the bit string assigned to each character does not make the output of such a process any less a “reproduction” than if Dr Bennett had sat down with a print-out of the table and copy-typed it …

This comment may raise problems for those wanting to create interoperable programs.  Anyone, it seems, can structure their program in such a way that the reproduction of a copyright work is necessary to interoperate with the program.  I will defer to the programmers out there on whether and how this might apply to drivers accessing the Linux kernel.  The legislature might have addressed this in…

Section 47D of the Copyright Act

Since the Data Access case the legislature has implemented section 47D of the Copyright Act.  It says that reproducing a copyright work that is a computer program (which includes literary works incorporated into a computer program) for interoperability is not an infringement… in certain circumstances.  Those circumstances are:

(1)  Subject to this Division, the copyright in a literary work that is a computer program is not infringed by the making of a reproduction or adaptation of the work if:

(a)  the reproduction or adaptation is made by, or on behalf of, the owner or licensee of the copy of the program (the original program) used for making the reproduction or adaptation; and

(b)  the reproduction or adaptation is made for the purpose of obtaining information necessary to enable the owner or licensee, or a person acting on behalf of 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; and

(c)  the reproduction or adaptation is made only to the extent reasonably necessary to obtain the information referred to in paragraph (b); and

(d)  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 connect to and be used together with, or otherwise to interoperate with, the original program or the other program; and

(e)  the information referred to in paragraph (b) is not readily available to the owner or licensee from another source when the reproduction or adaptation is made.

(2)  Subsection (1) does not apply to the making of a reproduction or adaptation of a computer program from an infringing copy of the computer program.

McKeogh, Stewart and Griffith cited above argue that s 47D is a complete answer to interoperability questions (see section 8.7) but I don’t see it.  The key words of this are in paragraph (b) and (c) which make it clear that the “reproduction” which is excused by this section is the reproduction for the purposes of getting information (another section, section 47AB gives “computer program” an expansive definition which would probably cover the Huffman table in the Dataflex case).  Paragraph (b) also makes clear that the reproduction in question must occur prior to the making of the interoperating program.   The key point is that it says nothing about whether you can use the information that you obtain in this way, and the reproduction which occurs when this information is actually incorporated in the interoperating software does not appear to be covered by this wording.  Paragraph (d), which you might think covers it, is worded as a qualification on paragraphs (a), (b) and (c).

For example, I can’t see that the outcome of the Data Access case would have been different if s 47D had been in force.   McKeogh et al correctly observe that the compression table in the case would likely be within the extended meaning of computer program in the legislation.  However, the compression table is not the relevant thing being reproduced because a reproduction of it isn’t “made for the purpose of obtaining information…”. On the contrary, it is the information which has been obtained as the result of some other reproduction.

Some thoughts on 47D

In my view section 47D is not drafted in a manner which is of much practical assistance to someone wanting to create an interoperable software program.  Perhaps someone might be able to hang their hat on some Explanatory Memorandum, Hansard (hint: try around 30 November 2006) or a CRC report somewhere to explain its purpose, but to do so seems to require stepping outside the words of the section.   Incidentally, if there is a problem with section 47D, then there is also a problem with the exceptions to circumvention of technological protection measures, since it forms the basis of one of the exceptions.  I made submissions on behalf of OSIA asking for section 47D to be reworded in the course of the AUSFTA negotiations over the past couple of years (because this exception is relevant to the added prohibitions on technological protection measures).  Incidentally, the Senate Committee agreed with me (see recommendation 13 here).  Strangely, it didn’t make it into the final draft of the legislation.

So, while the legislature seems like they intended to address the interoperability issue, it’s not clear they’ve gotten there.

[1] [No 1] (1992) 173 CLR 330.

[2] Actually, the judgment is not clear.  In some places it looks like it is 127 different 127-bit strings in other places it refers to a single 127 bit string – see eg paras 12-14 of Dawson J’s judgment. See also the decision of Northrop J at first instance.

[3] Autodesk Inc v Dyason (No 2) [1993] HCA 6; (1993) 176 CLR 300 (3 March 1993).

[Addition 26 June 2008.  In response to Bruce Wood’s comment here is a more complete quote of paragraph 124/125 of the judgment (my emphasis):

124. In addition, in our opinion the Full Court was correct in holding that the process undertaken by Dr Bennett constituted a “reproduction” of the standard Dataflex Huffman table. The fact that Dr Bennett used an ingenious method of determining the bit string assigned to each character does not make the output of such a process any less a “reproduction” than if Dr Bennett had sat down with a print-out of the table and copy-typed it into the PFXplus program.

125. The finding that the respondents infringed the appellant’s copyright in the Huffman table embedded in the Dataflex program may well have considerable practical consequences. Not only may the finding affect the relations between the parties to these proceedings, it may also have wider ramifications for anyone who seeks to produce a computer program that is compatible with a program produced by others. These are, however, matters that can be resolved only by the legislature reconsidering and, if it thinks it necessary or desirable, rewriting the whole of the provisions that deal with copyright in computer programs. ]

[Addition 27 June 2008.  The Decision on appeal to the Full Federal court describes the table (under the heading Huffman Compression Table) as being 256 lines of source code (presumably one line to assign each character value).]

Blog Stats

  • 273,965 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