Flexbooks – a Non-Braindead way to produce textbooks

Flexbooks – a Non-Braindead way to produce textbooks

I’ve just seen a post on Flexbooks, an initiative of CK-12 so headed over to have a look.  I believe initiatives of this kind are extremely important.  Because copyright makes the price of textbooks too high, copyright is a significant barrier to education.  A poorly educated workforce is a lower production workforce.  In short, copyright ideology substantially lowers GDP.  Well, no more.  The Flexbooks initiative aims to provide textbooks for K-12 under the CC-BY-SA licence.  The obnoxious (and anti-social) ‘-NC’ is absent.  Thank heavens these are enlightened educators!

I have downloaded their 400+ page book on calculus and, after a quick flip, it seems appropriate for a late secondary school course.  In criticism, the typesetting of equations is a bit wonky (and given the long standing availability of LaTeX this seems very mysterious), some diagrams could be improved, the book lacks a preface,  appendicies and an index, and they seem to assume that student have a particular make/model of scientific calculator.  Much of the demonstration information relating to the site is in Flash, so they’re not entirely enlightened.

Downloading and distributing for free is not even half the story.   As the licence is SA, everyone is free to make changes to them – say farewell to the days of textbooks with US-specific references or out of date pricing.  Does the example in the text book refer to buying a penny white loaf at Banbury Cross?    Why, then change it to $2:00 wholemeal loaf in Sydney, a $3.80 milkshake at Ettalong Beach (for school children in that area) or even something from the tuckshop of the specific school it’s used in.  If there is something wrong with a chapter, take it out and replace it with a better chapter.  Over time such books will reach optimal quality – perhaps even in the absence of structured review (in that bad variants will be less used by teachers).

You don’t even need to change the textbooks to see the added value.  The fact that they’re electronic means you don’t need to print them or, if you do, you can print them in a size and format which suits you. If you think the idea of kids lugging 400 pages of text book to and from school every day isn’t a good one, print them out in smaller parts, one for each term.

This kind of initiative is exactly the kind of initiative that Government should be directing stimulus money to.

Pope on IP: Repent! Repent!!!

Patently O reports that the Vatican is coming out against monopoly rights over intellectual endeavour.  Quoting from an encyclical:

“On the part of rich countries there is excessive zeal for protecting knowledge through an unduly rigid assertion of the right to intellectual property, especially in the field of health care.”

!(Openness) && Standards Australia

!(Openness) && Standards Australia

Tom Worthington reports on an arbitration between Standards Australia and SAI Global over an agreement entered into in 2003.  The results of that arbitration are apparently that “Standards Australia must not permit or knowingly allow SDOs [Standards Development Organisations] to develop Australian Standards without securing for SAI Global exclusive rights to publish, distribute, market and sell those Australian Standards.“   And, of course, if you want a standard to become an Australian Standard you need Standards Australia’s accreditation.   I’m sure you can see where this is heading…

Subject to SAI Global granting an open licence over a standard, it seems that the set of standards accredited as an Australian Standard and the set of open standards will be empty.

MS Patent Suit over use of Linux??

Patent Suit over Use of Linux <- hello PlanetLA

Todd Bishop is reporting that Microsoft is suing TomTom, and that part of the suit relates to their use of Linux (Linux is mentioned in one of the documents referred to, but on a quick review I can’t find anywhere it calls out Linux as infringing per se).

I also can’t find any press release announcing this, so it would be revealing to know how this was seeded into the media.

Resale Royalty: Unfair Inequitable

Resale Royalty: Unfair Inequitable   -

The Government recently introduced a resale royalty right.  The way it works is that people who invest in eligible works get to pay the rights holders of those works for sitting around doing nothing.   When intermediate owners improve the work (primarily by publicising it), the rights holder gets to benefit.  The most egregious aspect of this system is that it arbitrarily chooses “artistes” as the receipients of the subsidy.  Exactly why should artistes be entitled to such a payment when others in the economy are not?  Will these artistes be willing to pay a subsidy to the original builder when they buy their home?  Surely the building of a home involves at least as much skill and effort.  Will they pay a subsidy the original cabinetmaker for the antiques they buy to create the right atmosphere for their creative endeavours?  Surely clients should pay lawyers a cut if they rely on advice and make a profit? Surely school teachers should get a pecentage of the future income of the students they teach.  School teachers put a lot of skill and effort in and are a notoriously underpaid sector.

Resale rights are unfair and discriminate in favour of a small sector of the community to the detriment of the balance.  This is an ideology that is out of control.  This sector is in desparate need of an ideology revamp so that “rights holders” have an expectation to secure their income only honestly from their efforts, rather than on the basis of subsidies from the rest of society.

(Of course, the inevitable has happened.  As with all things copyright, the resale right has now gone on the extremism treadmill, with lobbyists already working to extend the scope of this egregious subsidy.  I’ve even been asked to sign a petition in support – I don’t think so. )

Taste of Vista, Sillyness of EULA Laws

A relative bought a new computer last week and I went around to set it up.  It was my first experience of Vista (in theory I have a copy of Vista on my home machine, but I haven’t (re)connected the hard drive since I had to remove it to install my Linux set up).   I spent most of my time setting up the hardware, rather than looking at Vista, but it seems nice enough.  I can understand why the user access controls are annoying people.  I was only on the machine for 5 minutes and was already getting annoyed at it.

Interesting from my point of view was that the machine booted straight into the desktop – no EULA was presented.  I also noticed that the 7 day anti-virus trial only had 2 days left to run.  Presumably the store had set up the machine?  The machine is a name brand (Medion, produced by Aldi).  It has an authorisation sticker on the side.  The machine comes with minimal documentation and no printed EULA.

The $64 question is – is my relative licensed to use the software?  If so, what are the licence terms?

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

Report on National Innovation Review Released

The Commonwealth Department of Innovation, Industry, Science and Research has released the report it commissioned by Venturous Australia on the Review of the National Innovation System.  I put together a submission for OSIA arguing that open source should be given much more prominence in national innovation priorities.   The report has recognised the importance of collaboration, with at least one recommendation specifically in relation to open source.

Some relevant extracts include:

Intellectual property is also critical to the creation and successful use of new knowledge – particularly the ‘cumulative’ use of knowledge as an input to further, better knowledge. In this regard, particularly in new areas of patenting such as software and business methods, there is strong evidence that existing intellectual property arrangements are hampering innovation. To address this, the central design aspects of all intellectual property needs to be managed as an aspect of economic policy. Arguably, the current threshold of inventiveness for existing patents is also too low. The inventive steps required to qualify for patents should be considerable, and the resulting patents must be well defined, so as to minimise litigation and maximise the scope for subsequent innovators.

at page xii, recurring in recommendation 7.2

On the other hand, there is one area in which it is clear that there will be substantial spillovers from software development.  Where firms develop open source software and donate the code from their development back to the open source project, this will generate clear spillovers for the rest of the community which will be able to access their developments. It is hard to think of a more straightforward case for government support. The Panel accordingly recommends that R&D on open source programs should qualify for the multiple sale test. Given the pervasiveness of positive spillovers, it may also be cost beneficial to relax somewhat the degree of technical risk required in relation to open source software.

(at page 109, see also recommendation 8.7)

Professional practitioners and beneficiaries of the IP system should be closely involved in IP policy making. However, IP policy is economic policy. It should make the same transition as competition policy did in the 1980s and 90s to being managed as such.

Australian governments should open publishing as far as possible.  Material released for public information by Australian governments a creative commons licence.

To the maximum extent practicable, information, research and content funded by Australian governments – including national collections – should be made freely available over the internet as part of the global public commons. This should be done whilst the Australian Government encourages other countries to reciprocate by making their own contributions to the global digital pubic commons.

(Recommendations 7.3, 7.8 and 7.14)

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…

The Invisible Closed Source Overhead – 1

Brendan Scott, June 2008

Groundwork

Many people focus on the “hard” costs of software acquisition and maintenance such as licence fees and implementation costs. However, the adoption of a closed source solution has a number of hidden costs which are rarely properly accounted for. Many of these costs arise because of the extreme lack of flexibility in closed source licences and they are likely, at least in some cases, to be far more significant than the hard costs. In this series of posts we will work our way through the closed source acquisition and maintenance path and have a look at some of the more obvious ones.

Underlying Reasons – Natural Monopoly

Software is a natural monopoly (because it has a high fixed cost and low marginal cost to produce). As such there is a tendency for the market to become increasingly concentrated, first within a particular product line (such as databases, operating systems or word processing software), then across groups of product lines (typically because of the creation of artificial cross product dependencies).

Underlying Reasons – Good Enough for Most

Professor Pamela Samuelson and Mr Mitch Kapor have run a lecture series at UC Berkeley on open source (which, by the way is worth a listen). In one of their lectures they give the example of the university sector in the United States having particular requirements for their accounting, requirements which are not met by the closed source software industry. Indeed, the gap between their requirements and the capability of close source solutions is so great that Universities have banded together to create their own (open source) accounting software – at substantial expense. Ordinarily you would expect that Universities would have enough market power to get additional functionality into closed source solutions – but they don’t. Remarkably, the US University sector is not important enough to influence the direction of closed source software vendors on features of their accounting software. This is not an isolated case.

If this sector isn’t influential enough, what hope does an ordinary organisation have? Any implementation which is designed to be sold on a per unit basis (regardless of the unit – eg copy, seat, site, user etc) means it must be designed to maximise sales of that unit. Here the 80-20 rule comes into play, with the vendor coding features to attract a large chunk of the market for the lowest cost. That is, in order to maximise profits a closed source vendor must aim for a product which is “good enough for most”.

While the market is young there may be niche players who will provide products into that tail 20% that is not properly served (or that there might be multiple different products each covering a different 80%). However, this market structure is unstable because software is a natural monopoly (as described above). As products begin to win market share they crowd out competitors starting with the competing 80%-ers and then to niche players.

If your organisation has specific feature requirements it is likely not only that closed source solutions will not meet your needs, but also that you will be unable to influence the vendor to implement features to meet your needs. Even offering to pay the development costs will not necessarily influence a vendor to implement the feature because this would burden their code with additional modules which would need to be maintained going forward and the vendor maybe unwilling to take on this maintenance burden.

In short, for those who fall into “the many” category, they will be reasonably well served by their closed source vendor. However those in “the few” (roughly 20% according to the 80-20 rule) won’t be. I will use the terms The Many and The Few for convenience in the balance of these posts.

Tragically Closed

Closed source vendors are typically reluctant to interoperate with others, especially if they vendor is well positioned in the market. Indeed, a vendor’s support for interoperability is inversely proportional to their market share – when they have small market share they need their software to be able to work with other people’s software, since by assumption most people have other people’s software. As the vendor’s market share grows interoperability transforms into intraoperability – the ability to operate with other components in the vendor’s software portfolio. Indeed, vendors with large market share will even argue that intraoperability and interoperability are the same thing, since that vendor controls the market, (they argue) intraoperatibility is all that a customer needs de facto.

As the market share grows offering interoperability is only assisting the growth of the market share of the smaller players in the market, so beyond a certain market share, vendors have a disincentive to interoperability and that disincentive grows as the market share grows. In the extreme examples, for someone with no market share to enter the market their first sale must interoperate with the existing software so they support interoperability. Equally, for someone with 100% market share, support of interoperability necessarily means that they lose some part of the market.

It follows from the fact that software is a natural monopoly that, over time, because the natural tendency of a closed source market is to market concentration, there is also a natural tendency towards lack of interoperability. So, even if you invest in a closed source product which supports or promotes interoperability today, you will likely be in trouble in five or ten years’ time. By then, either the product will have emerged as a market leader and therefore no longer supports interoperability or they will have fallen by the wayside and the actual market leader will be trying hard to lock out the product that you have in fact invested in. Moreover, there is now a move among some closed source vendors to trade interoperability against patent rents, thus increasing the cost of interoperability. Therefore long term interoperability prospects for any closed source solution are poor (I have used the heading “tragically” closed here in Hardin’s sense – that the long run closure of the system follows almost inexorably from the nature of the industry ).

The lack of interoperability is an enormous problem because interoperability is a precondition to competition. When software lacks interoperability it is a symptom that there is no competition in the market. As competition in a market decreases not only do the costs of products in the market become artificially inflated, but the quality and diversity of the products simultaneously decreases. Lack of interoperability means that a customer cannot avail themselves of self help to implement features that they want in a product or remove dis-features (1) (2) from a product. As we mentioned above, unless your requirements are shared by a substantial proportion of the target market, you will be unlikely to be able to have specific features implemented – even if you are willing to pay the cost of implementation.

A result of this Tragic Closure is that closed source software tends to be monolithic rather than modular.

In part 2 we look at some costs of acquisition.