Exposure draft 1 September 2011.
In the 1987 decision of Hanimex, Gummow J commented at 285 that '[t]he evolution of the meaning of "authorisation" in the 1911 Act and the 1968 Act has pursued perhaps an even more tortuous course than the doctrine of contributory infringement in the United States'. The Court concurs with such statement, and it has become even more apt in the years following that decision. Despite the legislature's attempt to simplify the relevant considerations pursuant to the Copyright Amendment (Digital Agenda) Act and s 101(1A), the law of authorisation has continued to grow more complicated and unwieldy, with a litany of competing and contrasting considerations, and with one statement of principle frequently matched with a contradictory one. The authority on authorisation has become a mire.
The City of Adelaide case is not authority for including "permit" within the ambit of the meaning of "authorize".
The history of the words "sanction, approve, countenance" show that there is more to an authorization than merely the acts of the person alleged to be authorizing. In addition to those acts, the mental state of the person carrying out the primary infringement is a necessary ingredient. In particular, the primary infringer must have some belief that the authorizer has the right or power to grant such an authorization. Acknowledging this component of "authorization" will make the various decisions much more sensible, and less miresome.
Note: this draft is made available for comment.
The High Court has recently granted special leave to appeal in Roadshow and others v iiNet (the iiNet case). This case is concerned with the liability of Internet service providers for authorizing infringements which occur through the use of the Internet service provider's infrastructure. Under the law relating to authorization a second person can be liable for an infringement carried out by a first person in if that second person has "authorized" the first person's infringement. The concept of authorization has been treated on many occasions in Australian case law. Its history is summarised by Gummow J in the Hanimex case. In particular, the High Court in the Moorhouse case held that a university library, by locating a photocopier near to racks of shelving containing books, some of which were still subject to copyright, had authorized infringements in relation to those works which occurred when people photocopied then using the photocopiers which had been so located.
In order for authorization to be made out, a "primary" infringement must be proven. That is, simply saying to someone "go and make a copy of this" is not an infringement if they do not then go and copy. However, if they do go and copy, then there are two infringements – the primary infringement, being the making of a copy, and the authorization of that primary infringement. In the iiNet case this primary infringement is that of "making available online". When a person "makes available online" a copy of a copyright work that "making available" itself constitutes an infringement. In this case, the infringement is of the right to communicate to the public (defined in section 10 of the Act). Is in the lower courts this infringement has been established by users using peer-to-peer software and having the relevant copyright work within a particular folder for sharing by their peer to peer software.
Authorization isn't – where is "sanction, approve, countenance"?
Unfortunately, in the Act, the word "authorize" has been interpreted to mean something other than "authorize". Rather, courts have read into the term "authorize" the concepts of "sanction, approve, countenance", based on some words of Gibbs and Jacobs JJ in Moorhouse.
" The word "authorize", in legislation of similar intendment to s. 36 of the Act, has been held judicially to have its dictionary meaning of "sanction, approve, countenance": Falcon v. Famous Players Film Co. (1926) 2 KB 474, at p 491 ; Adelaide Corporation v. Australasian Performing Right Association Ltd.  HCA 10; (1928) 40 CLR 481, at pp 489, 497 ." (Per Gibbs J at paragraph 10).
The third judge, McTiernan A.C.J. did not write a separate judgment, but agreed with the others. So this wording is essentially unanimous. I note here that no dictionary I have gives "sanction, approve, countenance" as the meaning of authorize.
However, this appears to be simply wrong. This is discussed in the end note below.
It is hard to see that Adelaide Corporation is authority for Gibbs/Jacobs JJ's statement.
That is, in comments by a single judge of the three judges that heard the case). Note also here that the words used are "sanction, approve and countenance" (my emphasis). These were faithfully reproduced in Adelaide Corporation, but were transformed into "sanction, approve, countenance" in Moorhouse. The disjunctive form has survived in the iiNet case – "The word authorise, when used in s 101, has its dictionary meaning of sanction, approve or countenance." (per Emmett J at paragraph 24, emphasis in original).
I note here that Tomlin includes "give formal approval to". It is also important to note that Tomlin J gives the dictionary "meaning". in Falcon, Bankes LJ left out the first component, relating to the giving of formal approval to. However, in Falcon Bank LJ doesn't say this is the meaning. Rather, he says that it has it's dictionary sense of "sanction, approval and countenance". This might be considered a reasonable interpolation of the actual meaning given by Tomlin J. Presumably, Bankes LJ felt the addition of "and" was sufficient to read out "give formal approval to" when proposing the formula he did. Isaacs' wording in Adelaide Corporation is consistent with this, referring to the dictionary "sense".
The whole of the court in Moorhouse has purported to give "authorize" its dictionary meaning and then failed to do so. The Moorhouse court adopted not even the dictionary "sense" averted to in the authorities cited, but rather, have substituted a new formula entirely – that of "sanction, approval, countenance" (into which later judges have read "or"). This almost completely upends the earlier authorities cited in support.
That is to say that what Bankes LJ is stressing in Falcon is the mental state of the primary infringer. However, the Moorhouse decision has only taken part of the Falcon meaning. Indeed, while the Moorhouse case does identify the need of a mental element, it is placed wholly on the authorizer.
What all of these cases establish is that the absence of service or agency is not intended to defeat a claim of authorization or rather, the purpose of the inclusion of authorization under the 1911 Act was to overcome a particular limitation found in the case law. However, for all of them, the background of the discussion is one in which the primary infringement is a natural, if not necessary, consequence of the action of the authorizer and that this is known or understood by the primary infringer. In Monckton, it was the expectation of both the seller and the purchaser that the record would be played after it was purchased. In Hulton, it was the expectation of both the seller and the purchaser that the manuscript would be published. In Falcon, it was the expectation of both the seller and the purchaser that the films would be shown in the theatre. Further, in each case it was reasonable for the purchaser to believe that the seller had the power to allow the purchaser to do the relevant act. [As an aside, it is likely that Moorhouse can be fit within this requirement, Cooper possibly, but iiNet unlikely] Consider a thought experiment in which each of these cases was re-run, except that the seller was selling to a purchaser under a common understanding that they would be broken into its elements for recycling (to recover the paper in the manuscript, the shellac of the records and so forth). Had the purchaser turned around after the sale and then published, played and so forth it is hard to imagine an authorization by the seller would be found in these cases, despite the seller having done the same acts.
The highlighted wording is significant. While this wording does not form part of the judgment, it demonstrates the assumption of the copyright owner in pursuing the case. Therefore, if the court is to give to "authorize" it's ordinary, contemporaneous meaning, these submissions, coming as they are from the copyright holder, are relevant as evidence of that meaning.
This wording also identifies the common, but unstated thread running through all of these cases on which the meaning of "authorization" is based. That is, to say, whether a person A "authorizes" another person B to do an act is not purely a matter of the conduct of A. In addition to the conduct of A, B must have a particular state of mind. B must have some perception not only of authority flowing from A, but also of A's right or ability to grant such an authority. This is consistent with the "ordinary" meaning of authorization.
End Note: Did Adelaide Corporation treat "authorize" and "permit" as synonymous?
Knox CJ does not refer to authorize.
Inactivity or "indifference, exhibited by acts of commission or omission, may reach a degree from which an authorization or permission may be inferred. It is a question of fact in each case what is the true inference to be drawn from the conduct of the person who is said to have authorized the performance or permitted the use of a place of entertainment for the performance complained of" (Performing Right Society v. Ciryl Theatrical Syndicate).
So, it was appropriate for Bankes LJ to phrase things in this way because both issues were put before the court in that case. Gavan Duffy and Starke JJ are simply quoting the wording of Bankes LJ (the quoted section appears in the judgment of Bankes LJ).
Here authorization is not being used in its Copyright Act sense.
"For the word "cause," which had been given a restricted meaning, there was substituted the word "authorize," and that word is now understood as importing the sense of "sanction, approve and countenance" (see Falcon v. Famous Players Film Co.). Along with that significant change, there was inserted the sub-section now under consideration, which is a necessary complement in the scheme of protection. It extends the previous limited responsibility of proprietors of halls who merely hire them out for remuneration without being directly connected with the performance itself. The gist of the sub-section is that such a person who "permits" the performance of a copyright piece is to all intents and purposes as much an infringer of the copyright by providing for gain to himself the necessary means of infringement as if he directly produced the performance, unless he proves that "he was not aware, and had no reasonable ground for suspecting" that the performance would be an infringement.
Neither of these references treats "authorize" and "permit" as synonymous. Indeed, it assumes them to have distinct meanings.
But again, this is not a reference to authorization in the Copyright Act sense. Indeed, it distinguishes the "giving of authority" and permission. A review of Cyril, the case cited, also reveals a repeated reference by their Lordships to both "authorize" and "permit" as separate concepts, with no attempt to identify them as a single concept. One can concede that "indifference, exhibited by acts of commission or omission, may reach a degree from which an authorization may be inferred." and that "indifference, exhibited by acts of commission or omission, may reach a degree from which a permission may be inferred" but this does not justify a conclusion that "authorize" and "permit" are synonymous – just as tables and dogs both have four legs, but this does not make tables dogs.
Adelaide Corporation is not authority for identifying "authorize" and "permit". Indeed, both it, and Cyril, the case it primarily cites, are authority for distinguishing them, especially given that the legislature chose to use "permit" in section 2(3), and "authorize" in section 1(2).
As an aside here, the Cyril case was concerned with whether the manager of a corporation had authorized the infringement by the corporation's players of a particular work. At first instance both the corporation and its manager were found to have authorized. However, the manager brought an appeal against the decision, and it was his appeal which their Lordships were considering in Cyril. In many respects Cyril is very similar to the iiNet decision in that the manager may have had the relevant elements set out in section 101(1A) (or at least to a similar level as iiNet has of making available infringements), yet he was still found not to have authorized the performance based on principles of whether, as an officer, he had made the tort his own.
I have run some numbers on how the size of the (Australian) Copyright Act has changed over the past century or so. With one exception, these numbers were generated automatically from electronic versions of the legislation. Before counting the words I stripped out the table of contents and everything from "The Schedule" on. This is because a bigger Act automatically means a larger table of contents and an older Act means more notes about when sections came into force, were repealed etc. The one exception is the Copyright Act of 1905, a word count for which was estimated by manually counting words on 3 pages, generating an average per page and multiplying by the number of pages. There are a couple of versions of the Act from between 1905 and the 1970s which are not plotted (as I don't have access to a full copy of them) but everything I could find from 1970 on is there.
The Statute of Anne (1709) has about 2,500 words in it. It took roughly 200 years to reach 7,500 (in our 1905 Act). For your reference, the NSW Conveyancing Act 1919 No6 (which actually does deal with property) has about 82,000 words (ie about the number of words added to the Copyright Act in the last 10 years). We might speculate whether there will be enough paper in the world to even print the Act in 20 years' time.
And, for a laugh, the BSAA reported piracy rate (from the annual reports produced by IDC etc) overlaid. I would not want to endorse the BSAA numbers as they don't seem to me to be well founded and any variation in them can easily be explained by changes in IDC's sampling procedures/calculation methods. In addition, they are advocacy documents so need to be taken with a grain of salt.
It is hard to see any relationship between the amount of legislation and the reported rate of piracy (which seems to be in a long term, albeit slow, decline). To the extent there is a relationship, the reported rate seems to lead changes in legislation.
Over the past twelve months or so I've noticed an upswing in enquiries about free software compliance. For example, someone might be seeking access to source code for embedded devices with Linux and/or Busybox on them. One of the key problems for pursuing compliance is the legal concept of "standing". That is, does the court think you have a right to press the claim in question? So for example, if you see someone (A) breach a contract with someone else (B), a court will probably not let you sue A, basically because that is B's business . B might not be concerned about the breach, or B might have a relationship with A (or someone else) that might be jeopardised by suing A, so it should be up to B to make the decision about whether to proceed with a suit. Moreover, A has not infringed a right that you have, so why should you be able to sue? You've not suffered damage, so why should you be able to sue? In short, a court seeks to limit the people bringing actions to only those people whose rights have been infringed. So, if you, not holding copyright, see someone breaching the GPL, you can't sue them in copyright to enforce compliance.
The term "free software compliance" is a short form of compliance with the licence terms for the free software. In this case, the relevant person whose rights are infringed is the person who granted the licence. That is, the person who holds the copyright in the software. Therefore, to bring a court case would require the copyright holders to be parties to the case. Given that copyright holders are largely concentrated overseas this presents problems for compliance within Australia. While it is possible for foreign copyright holders to initiate and/or participate in Australian proceedings, it is not simple as the mere distance presents logistical problems. There are other practical problems that a foreign copyright holder faces. For example, they may be required to be present in Australia in order to give evidence. Even where the copyright holder is in Australia they may be reluctant to pursue proceedings. For example, they may not think it justifies the time commitment they would need to make, or they may not want to be exposed to the possibility of the award of legal costs if they are unsuccessful. I have spoken with some foreign copyright holders and generally they are happy to help, but can't commit to spend much time helping.
This is where the Trade Practices Act (TPA) is relevant. The TPA has a very wide concept of standing. Practically anyone has standing to sue for a breach of the TPA. If a competitor puts on a misleading advertisement you don't need to have been misled in order to have it corrected. You don't need to show that you (or indeed anyone) suffered a loss. The mere fact of a breach is usually enough for anyone in the community to enforce compliance with the TPA. The TPA is therefore particularly relevant for free software compliance. If a breach of the terms of a licence are also a breach of the TPA, then you don't need the copyright holders in order to take action. You can leave them out of it entirely and, instead, rely on your rights as a consumer.
Enforcement under the TPA has other benefits. First, courts have tended to interpret the Act in a way which favours consumers (not surprising as this is the point of the legislation). Second, the consumer protections set out in the TPA are pretty straight forward. You may have heard of "section 52", which provides that a person must not engage in misleading or deceptive conduct in the course of trade. In the case of section 52 intention or knowledge is not relevant. If someone is unintentionally misleading, they will still be caught by the section. Finally, the TPA comes with an administrative structure for enforcing consumers' rights in the form of the ACCC and its State and Territory equivalents. That is, you need not even go to court in order to enforce compliance. You can, instead, rely on consumer rights procedures (at least in the first instance – if all else fails you may still end up in court, and even then the consumer body may assist you with the case – as happened up to the Federal Court in the groundbreaking Stevens v Sony case). This may involve some education of the consumer protection people, but, ultimately it's their job to protect consumers so they must come around sooner or later. Essentially, vendors who do not (for example) supply source code when they are obliged to are depriving consumers of a legal entitlement. Imagine how they would react to a vendor selling a car with a wheel missing.
Last year, I was contacted about a potential compliance issue for a router product in which Busybox was embedded (the company in question has since gone into administration). As is often the case, the person contacting me did not have a lot of money to spend on legal advice or drafting. In these cases people don't tend to contact me until they have first tried to get through to the relevant vendor, so it is usually at at least the first level of escalation. It seemed that the best way to deal with these cases, at least initially, was to try to create some "self help" materials for people to pursue themselves, without having to engage a lawyer. To do this, however, would mean that the initial issue of standing needed to be overcome, so I turned to the TPA. After a short consideration I came to the view that there were profitable lines of inquiry in the TPA, but the mapping of free software to the TPA is not straight forward. How would the research be funded?
In their next meeting, (last night, 3 March), the Linux Australia committee decided to go ahead and fund the first proposal I submitted (I am making a 1:1 in kind contribution of my time). This is important research into what arguments might be raised under the TPA if someone is not complying with a free software licence (a decision on the second proposal has been deferred), so the decision is excellent news. Only yesterday I received another referral – via the SFLC. They wanted to be able to take it to the next stage and send something more formal to a vendor they'd contacted, but didn't think it worth spending much money on. Once the research phase is done, producing notices such as this will be substantially easier (because the background of what is to be said is already set out). The outputs of the research will be public.
If you know of devices sold in Australia that you think are non compliant, send them to me, because I may as well start a list.
 This is talking only about civil actions. If there is a crime involved different issues come into play.
 The minority of cases end up in court. By and large things are resolved without recourse to courts.
Another issue that the acquirer of closed source software may have to contend with is the complexity of the licensing options. In the previous post we discussed how defining the software which is being acquired can present a problem. There is an additional, related, difficulty being that the software itself is not necessarily the most important part of an acquisition. A well defined concept of software in an agreement does not settle the issue because what is being acquired is defined not only by what the software is, but also what can be done with the software as a consequence of the acquisition. It will be hardly relevant if, even though what constitutes the software has been spelled out in exquisite detail, the licence does not permit the acquirer to (eg) run the software.
Therefore understanding the licensing terms is crucially important to actually defining the acquisition. Larger vendors can provide a highly differentiated smorgasbord of licensing options, with different things being allowed for different price points and/or configurations. In some cases whole jobs can be dedicated to simply understanding and explaining the licensing of a single vendor's suite of products (one example – but job ads tend to be pulled once they expire so google might be a better bet). As the licence terms effectively define what is being acquired, this means that acquirers can either invest a lot of time and money understanding the range of licensing options – or they can buy blind. In too many cases it is the latter.
Incidentally, the fact that the same thing is licensed under different conditions depending on its use means that the vendor is effectively charging the customer for the customer's innovative uses of the vendor's product. Imagine if the cost of a pencil differed depending on whether it was being used to write a Nobel-Prize-Winning novel or for a student's homework – and if you were breaking the law for using the pencil you bought to use at school to later write a Nobel-Prize-Winning novel.
Having acquired the software you are now likely to discover that you have a number of additional problems facing you.
Regardless of the process and outcomes of a licence negotiation the vendor will have a pricing model against which you will be charged. In order to support this pricing model you will, at a minimum, need to re-engineer your processes to record any relevant data. Clearly this is not much of an issue for organisation wide one-off up front fee licences. It becomes increasingly complex as the pricing model becomes more fine grained. In addition to pricing requirements some vendors also have copy control requirements as a means of cross checking that the licensing has occurred correctly. This means that manufacturing processes may need to be changed to include, for example, the application of a sticker or other verification to a chassis, as well as processes to order, acquire and store the stock of these indicia. A vendor may include auditing or accounting requirements, so record keeping practices may also need to be added. Moreover, there is likely to be wastage of these indicia (lost, damaged etc) so in practice the licence fees for such software will be slightly higher.
Software licence terms are rarely general (eg: "you may install and use the software as is reasonably appropriate"). Rather, they are specific. They will describe in some detail the circumstances in which you can (and can't) install and use the software. Where you are a manufacturer installing the software on a device you may find the licence includes arbitrary restrictions on the characteristics of the device.
For example Microsoft recently announced a drop dead date for the shipment of Windows XP. It then extended that shipment date for devices meeting certain (maximum) specifications. It subsequently modified that date further, relaxing the limitations on what devices the software could be loaded on [article with overview also here]. So, if you had acted on the earlier indications you would have arbitrarily limited yourself. The subsequent later easing of the restrictions could end up being to the benefit of competitors (in that you may have committed yourself to a specific platform from which it takes time to extract yourself). Indeed (after this paragraph was first drafted) the Vista litigation has shown that exactly this happened. According to a number of articles (examples: 1, 2, 3, 4) HP upgraded their stock to match Vista's requirements, only to find themselves expensive and uncompetitive when the Vista requirements were weakened (at Intel's insistance).
The negotiation of a closed source licence can be straight forward, or it can be very involved. The extent to which your business is unusual has an impact on this, with variations from a standard form of operation (as envisaged by the Vendor, albeit based on its other customers) meaning greater difficulty in negotiating a suitable licence. Ironically, this means that the more innovative your business is, the harder it will be to become licensed. Equally, if you are in a sector with which the vendor does not normally deal, the licensing terms can be similarly challenging. Mitch Kapor and Pamela Samuelson, in their lectures at UC Berkeley refer to the case of the university sector. This sector has very specific requirements for their accounting and calendaring systems. However, no vendors are prepare to meet those requirements, despite it being a market of substance. Universities are therefore looking to create open source solutions.
In most cases negotiations lead inexorably to a position which is suitable to each of the parties, although this may take some time. In some cases though negotiations may break down. If you have committed time and resources into a product on the assumption that the negotiations will turn out ok, then these will be sunk. Moreover, you may now be caught with insufficient time to find a replacement and ship your product. In any case you will end up either curtailing certain aspects of your proposed implementation or paying increased licensing fees or both.
Open source licensors will likely be less flexible on certain points than will closed soruce licensors (who can usually be swayed by the liberal application of licensing fees). However, it is always clear ahead of time exactly what an open source licensor will be inflexible on, whereas, with a closed source vendor, it may not be until the very end of negotiations that you find out that the vendor really is serious about such-and-such a point. Moreover, open source licensors will permit broad rights of internal use, so innovative applications of the software are unlikely to cause any licensing issues. Examples of such problems in the closed source space include multiplexing terminals, embedding on devices and use in virtual machines.
In certain cases (particularly relating to data formats and standards) closed source vendors have an incentive to de-emphasise the licensing terms until after you have become committed to development using the relevant product. Go have a look at vendor's websites for their software development kits. Do these pages emphasise how much fun and productive it is to use the SDK and are covered in eye candy, or do they emphasise the licensing restrictions you'll be under if you ever want to ship a product using that SDK and are sombre and sober?
What can often happen is that the developers will download and start using an SDK because it solves a problem and legal only gets wind of it when the relevant products are mostly complete and nearing shipment. This puts the acquirer in a weak negotiating position for the licence terms – or may even tie their hands.
In many cases the licence you have struck with your vendor will expire after a certain time. Customers typically enter into such agreements with a poor understanding of how their use of the product will develop over time. They may believe it is something in the nature of a trial or a stopgap measure. However, it is not at all unusual for stopgap measures to balloon in scope over time. At the end of the initial licence period you are then in a position of weakness when renegotiating the licence. There are a variety of marketing tricks used by Vendors (eg discontinuing old versions or discontinuing support for old versions) to make you pay a new round of licence fees, despite not really needing the difference in functionality.
Further, while this is certainly a problem where software is acquired by way of stopgap, it is also an inherently difficult problem even for those customers with a well developed understanding of their requirements going forward.
Open source cannot assure you that you will always have a vendor to turn to when you need to solve a problem. That's because a vendor will only exist where there is a community which is sufficiently strong to support that vendor. What open source does assure you though is that, all else being equal, if there is enough interest then there will be a vendor. That is, a vendor does not have the option of shutting down a product because they want to focus on a new product. It can shut down its own support, but it can't stop others from supporting it – and others will support it if there is a market to do so.
This can happen in a variety of different ways. A vendor can realise that an existing product effectively cannibalises the market for a new product, so they can stop shipments of the old product. While you might think that if you stay with your existing copies you'd be fine – which is true to a point. If you want to exchange data with others, you may be in trouble. Vendors often introduce file formats in new versions of their products which are incompatible with the formats used in older versions. If enough people (or enough people in a specific category – government departments are a prime example of this) can be convinced to move to the new format, then, by needing to exchange documents with that category, they can drag existing users forward onto the new format.
The vendor might be acquired by another player who has a different strategic outlook (and therefore cans your product). The vendor might just lack business acumen and go under.
In the mid 90s I acted for a large government institution in a dispute over the implementation of a failed search engine development being carried out by one of the worlds' largest developers/systems integrators. As is usual in litigation both sides conducted "discovery" – where you produce to the other side any documents of yours which are relevant to the dispute. Part of the discovery related to the backups of the actual code of the software being developed. In theory each side should have had a monthly back up for 12 months – that's what they told us. When it came to recovering from the backups we discovered most could not be restored. Out of 24 copies which should have been available, only (I think) 2 could be recovered. Neither of two large organisations (each of which might fairly be regarded as a paragon of record keeping) were able to keep adequate records.
Small and medium enterprises typically have poor record keeping processes. Without records, it can be very difficult to prove any point you're trying to establish – especially if the other side has kept their own (self serving) records. A good record keeping system will permit you to understand what was happening at a particular time and this can have a lot of important consequences.
A record keeping system not only records information, it also structures and stores it in an ordered fashion. This can sometimes mean having to replicate the record in a number of different places if it happens to be relevant to a couple of different things. If you don't keep your records in a structured way you might, in theory, be able to reconstruct what was happening from the jumbled mass of disparate notes you have kept, but, in all likelihood, you won't be able to do so as a matter of practice. It is unwise to rely on an after the fact search to find relevant documents. You might choose to structure things implicitly through the file system. Alternatively you can use meta-data in a document management system. However, my experience (now somewhat dated) with document management systems has been that structure is poorly represented (my impression was that they made it easy for me to find other people's documents, but rarely my own).
A failure to properly structure your files (whether physical or electronic) can have legal implications. For example, if you fail to maintain a clear demarcation between the open and closed source work that you do, the code from one area may contaminate the other, potentially leading to untold heartache. Indeed, this applies pairwise to any two projects you are working on. Particularly important is that you maintain a strict demarcation between any of your personal coding infrastructure (eg common libraries that you may have developed and reuse for multiple clients) and the specific projects you are working on.
For example, if you were to lump your private libraries into a directory shared with a client project that might seem to a judge (who are not renowned for their understanding of coding practices) as if they formed a single work – which may be bad if you've assigned IP as part of your engagement.
In some cases records can serve as a substitute for an express contract. Equally, where a contract is ambiguous or apparently overreaching, consistent record keeping can, over time, establish some certainty within that ambiguity or can put bounds on the scope of an overbroad contract. Such records might include, for example, notes of conversations where decisions have been made about what is in or out of scope, or emails which have been sent to this effect. To the extent there is ambiguity don't be shy in recording your understanding of the events. While courts may not necessarily take your view of the world (as instantiated in your records) as gospel, it's better than having nothing. Send the notes to the other side prefaced by something along the lines of "This is what I understood we are doing going forward: …." This gives them an opportunity to correct you if you're wrong. If they don't it will look odd for them to argue it was wrong at a later date.
To the extent practicable notes the date the note is taken should be included as part of the note. This makes it easier to date the note – which can be crucial. Often cases ride on when a person knew or said something. If you have an undated note of what was said, it may not end up helping your case if you are unable to place it in relation to some critical date. For example a note that the other party said "don't worry, the contract has nothing in it that you should be concerned about" will have a completely different consequence if it can be proven to be said the day before you sign (perhaps it induced you to sign) as opposed to the day after (when it can have had no effect on your decision to sign). In addition, courts will generally pay more attention to a record which is contemporaneous with the details it records rather than one which attempts to reconstruct the situation at a later date.
Never use automatic date fields in documents if they will auto-update at some later time. Date fields may seem like a good idea at the time, but once they update, their value is lost. If you must use date fields, have some process by which they are converted to plain text on save (eg when the note is finished, or the relevant document has been sent).