Archive for the 'contract' Category

Backup Copy (Bad Eula, Bad Eula! Down! Down!)

Backup Copy

From Adobe reader (for Android)’s end user license agreement:

3.3 Backup Copy.  You may make one backup copy of the Software, provided your backup copy is not installed or used other than for archival purposes.

Which leads one to inquire what, if any, point is served by a “backup” copy which can only be “installed… for archival purposes“.

7.2 Updating.  If your Device is connected to the Internet, the Software may, without additional notice, check for Updates, … that are available for automatic download and installation to your Device and let Adobe know the Software is successfully installed. [my emph]

You’re kidding, right?  Perhaps this is just bad grammar?

9.5 Indemnity.  You agree to hold Adobe and any applicable Certification Authority (except as expressly provided in its terms and conditions) harmless from any and all liabilities [etc] arising out of or relating to any use of, or any reliance on, any service of such authority…

Which leads one to wonder what, if any, point is served by using a service of a Certification Authority – which presumably is supposed to certify something – if you indemnify them when they stuff up.

I think I will click “Disagree”.  It hasn’t got good ratings anyway.

Advertisements

The Invisible Closed Source Overhead – 3

The Invisible Closed Source Overhead – 3
Brendan Scott January 2009

More on Acquisition –
and About the Day After

Earlier Articles in this Series

The Invisible Closed Source Overhead – 1

The Invisible Closed Source Overhead – 2

How Do You Know What You’re Buying II

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.

Short Aside

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.

Post Acquisition

Having acquired the software you are now likely to discover that you have a number of additional problems facing you.

Re-engineering Your Processes

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.

Straight Jacketed

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).

Negotiation

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.

Lack of a Crystal Ball

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.

Long Term Uncertainty

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.

Developers: Legal Tips for Young Players – Record Keeping

Brendan Scott, October 2008

Records Records Records

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.

Structure Your Records

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).

Maintain Separation of Projects

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.

Make Notes

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.

Date it

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).

Developers: Legal Tips for Young Players – Contracts

Brendan Scott – September 2008

In this series of posts we look at a number of generic legal issues which are relevant to developers, and especially to open source developers working for themselves or in small or medium enterprises.

What are contracts for?

People think of contracts as setting out rights and obligations of the parties to the contract.  In one sense, this is their point.  However, it ignores the process – negotiation – by which one arrives at a finished contract.  During negotiation, each side seeks to clarify what it is obliged to do, and what it wants the other party to do.  This process can often reveal unstated assumptions of one, or both parties.  Typically each party has agreed on a certain outcome but has not necessarily gone into the details of how that outcome will be achieved.  In some cases the outcome presupposes that one or the other of the parties must do certain things during the course of the contract – which they hadn’t realised they’d have to do (or perhaps that the contract is dependent upon some third party doing something).  The process of negotiation fleshes out the details surrounding the deal and identifies dependencies.

Engaging a lawyer will help to identify these details.  While this is part of the lawyer’s training, the mere process of having to explain the commercial deal to the lawyer makes you think about what these details are or should be.   A lawyer can also assist in identifying strategic issues that you may not have thought of.  For example, often there can be substantial issues in transitioning into or out of a relationship.  If these are not covered in the agreement you take you luck at the time.  If you happen to be on less than amicable terms with the counter party, you may rue an inadequate disengagement process.

Contracts and Timing

Rule 1 – Get advice before you sign, not after

This may seem like simple advice, but it happens from time to time that someone asks for an explanation of an agreement that they’ve just entered into.   When getting advice on a contract, the earlier the better.  Once you have signed a contract, there is usually little that a lawyer can do to help you (if it’s a rubbish contract).  They may be able to tell you how bad a mistake you’ve made, but you may not want to engage (and pay) them for that privilege. This is particularly bad in contracts which determine ownership of something (because when you sign the ownership changes).

Getting advice immediately before you sign is better than after – but not much.  It is usually difficult (although not necessarily impossible) to retrieve a position which has been negotiated away earlier.   This is because certain avenues of approach to strategic issues which are raised by the contract can be closed off in the course of negotiation.

Rule 2 – Sign the contract before you perform it, not after.

A practice sometimes honoured in the breach, is to sign the contract before you start performing it (or, worse, after you’ve completed it).  Often there is much goodwill between the parties, so they may be willing to begin performing the contract before they have signed – or even finished negotiating it.  As you get further into performance, one of the parties will be increasingly at risk if the negotiations break down – and therefore will lose leverage to negotiate an appropriate outcome.  For example, imagine you engage a builder to renovate your home, but have them start before the contract is finalised.  If you find some aspect of the contract which you cannot resolve you may discover that the builder abandons the job just after they’ve removed your roof and you will be with no quick means of engaging a third party (or if you have tendered for the work the other tenderers may want to raise their prices).

Rule 3 – Have a contract

In addition to being somewhat self serving, this advice is actually in your interests too.  Having a contract doesn’t necessarily mean that you have something in writing nicely formatted and prettily presented.  Rather, it means that, to the best you are able given the circumstances both you and the other party have a clear understanding of what is involved.  It is, of course, better if this is in writing and better still if you both sign and date it.  The reason writing is a good idea is that people’s memories are fundamentally flawed and you can be guaranteed that, as time goes on, your understanding of the deal and the other party’s will gradually drift away from each other until they are unrecognisable.  Having a written contract avoids the risks from a poor memory by having something that doesn’t change all that much over time.

If you do have a contract write it working from generics to specifics (“You must buy me a coffee.<generic obligation>  You must ensure it is a regular cappuccino from the cafe on the corner.  You must deliver it to me, still warm, at 9am on Friday.  You must ensure that, at the time you deliver it to me at least 25% of the contents of the cup are milk froth” <specific details>).  That way if, for whatever reason, you don’t get down to details, then at least your headline concerns are covered to some extent (“You must buy me a coffee.”) and the other obligations might be able to be filled in by context.

Rule 4 – If you don’t have a contract keep a record

Keeping a record of (eg making a written note of) your own understanding of what you’re required to do is still better than nothing, especially if it is dated.  A court will pay more attention to a contemporaneous document, than to the recollections of either party after the fact.  In addition, making a note may also help you to identify some of the details that you would have uncovered during the negotiation process as described above.

More on records in my next post…

FOSS Software and SAAS

Summary [updated 25 March 2008]

This is something of a theoretical argument, and one which is unlikely to see the light of day in court (if only because the court rooms in the Sydney registry of the Federal Court have no windows). The thrust of the argument is that the manner in which a SAAS model is implemented using FOSS might determine whether or not the implementation is legal/licensed. Conversely it may provide a means for businesses to “monetize” open source applications if they control sufficient copyrights (although probably not possible with software under GPL v3). In short, it may be that recent “innovations” in copyright law have indirectly harmed open source models by shifting the ground underneath them.

Note on Application to Closed Source

This argument will probably also apply more or less unchanged to closed source programs, although in that case the licensor has flexibility to expressly customise the licence to cover end users. This may not be a practical option for FOSS licensors.

Note on Commercial Application [Added 25 March 2008]

If this argument is correct, then another consequence is that those projects which control the copyright of the software will be able to exclude or charge others (ie competitors) from providing SAAS for the software. Indeed, it may be the case that anyone who has copyright in part of the software can prevent its use under a SAAS model. Assuming the community thought this was inappropriate, a business doing this would then run the risk of being blackballed.

Argument

The legislative background is (section references to the Copyright Act (Cth) 1968):

  1. it’s illegal to make a reproduction in a material form (s 31(a)(i)) of a substantial part (s 14(1)) of a literary work (which includes a computer program (s 10));
  2. subject to an exception, a reproduction in a material form can include reproductions made (including made in memory) in the course of running the program. While ultimately a question of fact in each case, historically judges have refused to say that a reproduction in memory of a computer program while it is running is an infringement by reason that, because the copy could not ordinarily be reproduced from the memory, if it was a reproduction it was nevertheless not in a material form, thus not an infringement under s 31(a)(i); However, (as part of the AUSFTA – s 186 of the US Free Trade Agreement Implementation Act No 120 of 2004) the definition of material form has been changed so the capability of reproduction no longer counts and a copy of the program in RAM is now fair game for an infringement argument; and
  3. the exception (s 47B(1)) says that the normal running of a program is not an infringement if certain conditions are met. Those are – the reproduction is “incidentally and automatically made” as “part of the technical process of” running the copy (s 47B(1)(a)); and “the running of the copy is done by, or on behalf of, the owner or licensee of the copy” (s 47B(1)(b).

So the relevant questions are:

  1. when a customer fires up their browser and logs on to an instance of a piece of SAAS are they running a copy of the program (or do they otherwise run such a copy); and, if so,
  2. are they doing so “by, or on behalf of, the owner or licensee of the copy.”

They key words are “licensee of the copy“. That is, of the copy which is being run, not of any old copy. Typically the end user of the program will not have received a copy of it. Most FOSS licences trigger the commencement of the licence from the time that the person receives a copy – so while the service provider may be assumed to be properly licensed, the end user is by assumption not a licensee (in any event the particular copy which is being run is probably licensed to the service provider rather than the end user). Therefore, if the end user is not a licensee, then unless they are running the software on behalf of the service provider (or some other licensee of the copy) they’re not within 47B.

To be on the safe side therefore a service provider who is using FOSS ought to consider having program instances which run independent of its customers. That is, the customer ought not to be the person who initiates or perpetuates the running of a copy of the program. Rather, it should be the service provider (since they are the licensee of the copy in question) who runs the copy (it will then be run “by… the… licensee of the copy.”

If the end user is in fact the person running the copy of the software, and it is not running it “on behalf of” the relevant service provider (presumed to be the licensee) then they won’t get the benefit of section 47B and will therefore run the risk of infringement of section 31(a)(i). If there is in fact an infringement by the end user, the service provider is also likely to be liable for authorizing the infringement (s 13(2) and a number of cases).

Counter arguments

As I mentioned, it’s not a glory (ie “a nice knock down argument”). You might argue that:

  1. the end user has received a copy of the software (constructively) when the service provider loads it up ready for them to run. If so, this may cause other problems in licences which have provision of a copy as a trigger event for other consequences (such as the supply of the source code);
  2. when the end user runs the program “it’s really” the licensed service provider who is running the copy or it is run on their behalf;
  3. that when the programs are run there is not in fact a substantial reproduction occurring (this would be a question of fact);
  4. the relevant licence does in fact extend to cover the particular end user. Licences which are structured as a grant from the original licensor to the recipient of a copy are unlikely to meet this exception;
  5. when a licensee is licensed in respect of one copy, they are automatically licensed in respect of all other copies (including those they haven’t received) (nb: question of fact);
  6. honestly, who’s going to sue anyway?

Conclusion

If it does turn out to be a problem, it would not be appropriate to lay the blame at the feet of the licenses (or their drafters). Rather, it is a consequence of inadequate thought being given to the expansion of copyright law, creating problems which were not foreseen when the relevant licences were created. Since judges were doing something comparatively sensible by requiring that a copy must be able to be reproduced for it to be in material form this would not previously have been an issue. However, the AUSFTA has changed that. While there is a provision which attempts to preserve the sanity of the system, it has not anticipated the constantly evolving models in the technology sector.

Note on GPL v3 [Added 25 March 2008]

GPL v3 is different from most FOSS licences in that it defines its permissions implicitly by reference to the copyright law (through the terms “conveying” and “propagating”). As the copyright law changes, GPL v3 is automatically updated to track those changes. Other FOSS licences which are restricted to permitting specific actions (eg “reproduction” or “use”) will be adversely affected by changes in the copyright law. For example, the addition of a rental right for computer software in the late 90s probably has the practical effect of limiting the scope of those licences – when they were drafted there was no rental right, no one bothered to anticipate it in the licence. However, since it hasn’t been anticipated in the licence, the commercial rental of such programs is probably in doubt.

In general therefore this nature of the GPL v3 would recommend itself to those licensors looking for resilience against legislative or judicial changes to the copyright law. Unfortunately, in this case the implicit referencing may not get the licence all the way there. The lynchpin of the argument is when and how does a person become licensed. GPL v3 has a similar structure to that mentioned above. That is, that the licence is effective upon receipt by the prospective licensee of a copy of the software.

That said, the right to “propagate” expressly permits licensees to authorise third parties to run the program. In practical terms GPL v3 probably does preserve the right to run the GPLed software in an SAAS model. Under the law the end user will probably not have a licence (since they will not have received a copy). However, the service provider will have a licence and that licence permits what would otherwise be a secondary infringement (eg authorisation). Thus the copyright owner might sue end users, but the service provider would not be unlikely to be able to be sued (and who’s going to be silly enough to sue end users?).

Should all Termination Clauses have a Cure Period?

Some termination clauses in contracts draw a distinction between breaches which are irremediable and breaches which can be remedied. The purpose of drawing this distinction is that irremediable breaches are said to permit immediate termination while remediable breaches are subject to a specific cure period.

In theory this is fine. In practice it presents a problem. The reason being that it is not easy to tell as a matter of practice whether a specific breach can be remedied or not. A good example is an obligation to pay on a certain date. If the payment is not made on the given date, can it be made later? This problem is compounded by the fact that if you get it wrong, then you will not have complied with the termination clause and will therefore yourself have repudiated (and will be exposed to suit for wrongful termination). This is particularly problematic because such termination clauses typically tend to draw a clear distinction between termination for remediable breach and termination for irremediable breach, so you can’t use the remediable breach clause if the breach is in fact irremediable (and vice versa).

As a practical matter it may be preferable to structure a termination right with a cure period in each case. The trade off is a period of time for a possible remedy against certainty in the right to terminate.


Blog Stats

  • 239,430 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