Software written by software – help, no copyright!
April 12, 2010
No copyright!
As we’ve seen in my last blog, my position is that software written by other software falls outside the scope of protection of copyright.
Why?
Because no human intervention occurs in the actual generation of the code itself, which means no human creativity intervenes at that level.
There is human creativity in the instructions given to the Writing Software, but those instructions are ideas or algorithms, which are not protectable under copyright.
What does that mean?
It means that any code (or content, for that matter) originated by software, falls necessarily in the public domain in terms of copyright.
Does that mean that nobody owns it? Well, not exactly.
It would still be possible for the licensor of the original Writing Software to determine in the license to the Writing Software who would be owner of the resulting code. However, that is a very awkward position. It would be like Apple (can’t always use Microsoft as the baddies) saying: any automated part of your song generated through use of Garageband is owned by Apple.
It wouldn’t be fair, and it probably wouldn’t work.
It wouldn’t be fair, because Apple is not actually involved in the production of the music. And of course, what would be next? Microsoft owning the content of this blog, because I wrote the first draft on Word software (sorry, force of habit)?
It wouldn’t work, because since the music created by Garageband would fall outside copyright (not created by a human), Apple would have no efficient legal tools to enforce their position. The reason for that is that the legal tools given to copyright holders are much stronger than the legal tools available under contract – in short, it would most probably not be cost efficient to start suing people because they are in breach of a contract stating who owns code or content.
Does that mean that software becomes unprotectable?
Some of it, yes.
Is that a problem?
Not necessarily. The best explanation is – again – in the EU legislation on applying copyright to software. The first relevant consideration states literally:
“Whereas (…) the development of computer programs requires the investment of considerable human, technical and financial resources while computer programs can be copied at a fraction of the cost needed to develop them independently.”
Let’s think for ourselves, rather than accepting a piece of legislation as truth from above.
Is this consideration, which is absolutely essential to the underlying reasoning of applying copyright to software, still true?
Well, when software develops other software, the marginal cost of developing another application quickly drops to zero as well!
It’s like a derivative of Moore’s Law: the cost of an application or functionality drops by factor x over y time (someone ought to check it).
If developing an application costs close to nothing, why apply a legal monopoly with a duration of at least 70 years to protect anyone from copying it, as copyright does? Does legislation like this, based on a fundamentally incorrect premise, still make sense?
The best illustration that there is a whole field of software being developed that has little to no value in the market, and that typically represents basic functionality, is the enormous market of applications that has sprung to life for smartphones (Mac-, Android or Symbian based).
Most of the “simple” applications are offered at no fee, or a very small one.
Again, what’s the point of throwing the mantle of copyright, including its criminal liability and heavy penalties, on something that, although easy to copy, has very low development cost, and is generated by software?
So – a bit of a paradigm shift, and we’ve only seen the beginning, as this article in the Guardian shows
Does that mean that all software becomes unprotectable? No. As with content (and technology), high-end and high-value functionality will still be protected, and charged for. It’s simple economics really: if it has high enough value, it should be protected, and the law should provide the right tools for that protection. However, the borders will continue to shift.
Next time, we’ll look at two more interesting questions raised by all this:
- In the heel of the hunt, who is the author/owner of software or content created by software?
- What will be the position on anything created by artificial intelligence (AI)?
Joren De Wachter
Who owns software written by software (part 3)
March 31, 2010
In the two previous posts, I discussed that
- there is a new development: software that is developed automatically, by other software, based on human instructions, but without humans writing any actual code;
- if we want to know how owns that code, we need to look primarily at copyright.
In the mean time, also, my full legal article on the issue has been published in Computer law review international.
So, what is the copyright status of software written by software?
“Written Code” (code written by “Writing Software”) is, technically, like other code. It is a human readable expression of the instructions that will be compiled into machine language by a compiler.
However, the Written Code is generated by another piece of software (or artificial intelligence, if you will), on the basis of general instructions given by the human user of the Writing Software.
What does that mean? It means that the human user of the Writing Software will formulate general instructions (like defining objects, describing relationships between objects, or drawing an algorithm). Based on those instructions, the Writing Software will generate (“write”) the code.
The distinction between the instructions and the code is a very important distinction – it will be instrumental in determining whether Written Code is protected by copyright, the topic of this blog.
It is instrumental because copyright is actually a rather awkward format of Intellectual Property protection for software. That is because copyright, created way back in the 19th century as a legally imposed monopoly on reproduction and distribution, was designed to provide protection to expressions of creativity. And software code is of course an expression of technical efficiency, rather than creativity.
However, in the seventies, when the IP protection of software was discussed, it was decided to opt for the use of copyright as the IP tool for protecting software, mainly because patents were even less appropriate, rather expensive and mostly inefficient for the purpose of protecting software, and because nobody wanted to devise a new, software specific, IP right.
The creativity was deemed to be in the original creation of the code.
Created, of course, by humans – except that that assumption was never really stated as such. But, it solved the creativity threshold problem, and therefore, copyright could apply to software.
The consequence of that choice, though, is that the distinction between an idea and its expression, which is so important for copyright protection, also applies to software copyright protection.
The best way to explain the distinction between an idea and its expression is as follows: the idea “My Baby Left Me This Morning, I’m Feeling Blue” is not protected; however, the thousands of blues songs based on that idea, to the extent each of these songs is not a copy of another song (there are specific rules for that, ask Madonna) are each individually protected by copyright. So, you can always write a new song on this theme, as long as your song, the specific expression of the general idea, is sufficiently new or original.
The analogy with software goes more or less like this: functionality in software (say, an automated back-up function) is not protected, but the code in which it is expressed is. It’s not a perfect analogy, but it is sufficient for our purpose.
Because, as we have seen, the user of Writing Software only expresses generic instructions “ideas”, and the Writing Software writes the code, the “expression”. It would be as if you instructed a software program to write a song about the theme “My Baby Left Me This Morning, I’m Feeling Blue”, and it came up with a twelve-bar blues in Bb, with a nice melody line that could have been played by Eric Clapton and some awkward, unhappy lyrics…
Note however, that the dividing line between “ideas” and “expressions” is not a clear-cut transition, there’s a lot of uncertainty where one ends and the other begins, even in very specialized legal literature.
Coming back to our software: what that means is that, for Written Code, it is the Writing Software that creates the bit with originality (the “expression”), that is supposed to be covered by copyright. The human originality is limited to the instructions (the “ideas”).
The interesting conclusion is that both elements that are involved in generating Written Code would fall outside the scope of copyright protection.
The first element – the instructions – falls within the category “ideas”. Look at the European Directive on Software Protection: underlying algorithms clearly fall outside the protection for software.
The second element, the code, contains no human creativity, and fails to pass the originality threshold required for copyright protection.
Hence, no copyright protection for software written by software.
Is that a problem?
Not necessarily so – I’ll talk about that in my next blog.
Joren De Wachter
Toyota hit by software, the viral business
February 15, 2010
Do you remember the joke from the days when Microsoft was poised to take over the world? We’re talking end of 20th century here.
Bill Gates had said that if only the car industry had kept up with the technology like the computer industry has, we would all be driving $25 cars that got 1,000 miles to the gallon.
GM (indeed) replied that if it had developed technology like Microsoft, we would all be driving cars with the following characteristics:
1. For no reason whatsoever, your car would crash twice a day.
2. Every time they repainted the lines in the road, you would have to buy a new car.
3. Occasionally your car would die on the freeway for no reason. You would have to pull to the side of the road, close all of the windows, shut off the car, restart it, and reopen the windows before you could continue. For some reason you would simply accept this.
4. Occasionally, executing a maneuver such as a left turn would cause your car to shut down and refuse to restart, in which case you would have to reinstall the engine.
5. Apple would make a car that was powered by the sun, was reliable, five times as fast and twice as easy to drive – but would run on only five percent of the roads.
6. The oil, water temperature, and alternator warning lights would all be replaced by a single “This Car Has Performed an Illegal Operation” warning light.
7. The airbag system would ask “Are you sure?” before deploying.
8. Occasionally, for no reason whatsoever, your car would lock you out and refuse to let you in until you simultaneously lifted the door handle, turned the key and grabbed hold of the radio antenna.
9. Every time a new car was introduced car buyers would have to learn how to drive all over again because none of the controls would operate in the same manner as the old car.
10. You’d have to press the “Start” button to turn the engine off.
And what do we see? Toyota (indeed) is forced to a recall of its flagship Prius model, because the brakes don’t function properly, and the remedy is: a software update.
This is generally interpreted as a serious blow to Toyota’s brand value, and the reputation for quality they had been able to build over several decades.
I think one of the major causes of this PR disaster is the fact that Toyota does not realize it has become, to a much larger extent than they envisage, a software business. And it has not adapted to integrate this fact.
As I stated in an earlier blog, software is becoming more and more important in other businesses. The reason is simple: the added value of software innovation increases much faster than that of hardware.
So, once a product (from cars to mobile phones to CCTV systems) has an important software component in it, that software component is set to become the most important feature, and the hardware drifts towards commodity status. (That is not to say that innovation in hardware technology is unimportant – I’m only stating that the relative importance of information and intelligence will increase in the overall combined product value).
And Toyota, as most car manufacturers, does not yet consider its cars as computerized user interfaces with added mobility functionality (i.e., it has four wheels and will get you from A to B).
Why else would Toyota recall hundreds of thousands of cars, just to plug them in, and download and install some software? Have these people ever heard of the Internet? Wireless data traffic? Secure, on-line software updates?
Why are they not providing a monthly update of their software online? It can’t be that hard, even Microsoft manages to do it?
It is clear that car manufacturers, as other hardware-with-some-software manufacturers, have to become aware of the fact that more and more of the value they offer (including the “look-and-feel” factor that seems to be the most decisive factor in purchase decisions of a car) is in the software functionality and the user interface related to that functionality.
When can I get a car, where I just plug in my mobile phone, and tell it to “drive to work”, while calling on-screen the newspaper, or my email account?
As a result, car manufacturers need to work much harder at understanding and integrating how software works, how it is protected, which IP rights are in it, and which business model is most effective in bringing that innovation it to the market.
If they don’t tackle this issue today, chances are the iCar or OScar will be built by software people, and household names such as Toyota, GM, Renault and many others will be at serious risk.
After all, why would anyone buy a car that does indeed function as Microsoft Windows 98?
Who owns software written by software (part 2)
February 9, 2010
In my last post, I raised the question “who owns software written by software?” based on the observation that there is a new development in the software market: applications that are fully written by other software (“Writing Software”), and that it is not quite clear who would own the result (“Written Code”).
Why is it important to know who owns Written Code? Because most software business models are based, partly or completely, on the premise that a licensee needs permission, and therefore, must pay for the right to use the application.
This business model can only work if it is clear who owns the application licensed.
In order to answer our question “who owns software written by software”, we need to understand the status of Written Code. In order to do so, let’s look at which Intellectual Property Rights (IPRs) can apply to software in general.
Typically, software is protected through three possible IPRs: copyright, patents, and contract.
Copyright is by far the most important. Why? For three reasons.
First, the general rule is that any code (written by humans) is protected by copyright. This protection is automatic, and copyright vests in code written by humans without any need for registration or other instrument. Therefore, pretty much all software code is protected by copyright, without any costly registration or acceptance process.
Second, copyright gives much wider protection rights for the owner of the software to act against unauthorized use. If a user breaches copyright (rather than a simple contract to use the software), the owner/licensor has much more efficient legal actions available under the different legislations (e.g. in the US the Digital Millenium Copyright Act, in the EU, the different transpositions of the Directive on the enforcement of Intellectual Property Rights). The owner can ask an injunction, or seize counterfeit, etc…
(Incidentally, this is also the technical legal reason why open source has been successful in the courts: copyleft is really a very specific and clever use of copyright, rather than its opposite.)
Third, most software licenses are based on copyright only. This is why software licensors get to apply all those restrictions, like user-based or CPU-based pricing, which are typically essential parts of their business model.
What about patents?
Actually, patents are used a lot less to protect software, and this is perfectly logical, for three main reasons.
The first is that the legal status of patents on software is much less secure than copyright. This is illustrated by the endless discussions in Europe, where the European Parliament killed the proposal to set up an EU Patent System (to replace the current EPO system, which is not EU, but broader European, and not very efficient) because of the hefty discussions around software patents, and the uncertain outcome of ligitation in the US, where the Supreme Court will have to decide on the validity on patents on business methods through software (re Bilski).
The result, from a business perspective, is that when you file a patent on software, you’re not actually certain if it’s ever going to stand up in court.
Second, patents are much more expensive. You need to file, register, pay every year, in a great number of jurisdictions. (Copyright, on the other hand, is obtained without any cost).
Third, patents give a very narrow scope of protection. I’m shortcutting a whole technical discussion, but if someone else develops a similar functionality as your patented one, they can avoid infringement by making the right kind of small changes to it, still operate in your market and target your customers.
In general patents on software are much less cost-efficient than copyright.
Third, it is possible to protect software through contract (that’s not technically an IPR, but contracts can give protection). While it is perfectly possible to state in a contract “I own this software, and this is what you can do with it”, the reality is that if the contract is not supported by underlying copyright or patent in the software, the legal protection available to the licensor is in practice very weak.
In order for a licensor to rely on contracts to enforce protection, there are a great number of (costly) hurdles to be taken: you have to provide evidence of breach, you need to establish damage, and it’s very difficult to get an injunction or other short-cut legal enforcement tool. In reality, mere contractual protection would only work for very valuable software, in B2B relations between larger players. It is totally cost-inefficient in any market with larger numbers of software being distributed.
So, we’ve established that copyright is the most important IPR to look at, in order to understand the status of software written by software.
The obvious next question is: is software written by software protected by copyright?
I’ll address that question in a next blog, which will centre around whether Written Code is creative work.
Watch this space.
Joren De Wachter
Who owns software written by software?
February 2, 2010
About a year ago, I was at a presentation of a number of start-ups at the Brussels Enterprise Agency. One of the enterpreneurs presenting his very cool software product then said something that really amazed me.
“One of the advantages of our application is that it is built automatically, through other software. So, there are no bugs.”
It sounded wonderful. Software without bugs, because written automatically.
Then I discovered they are not alone. An increasing number of software providers don’t write their software, but have other software writing their software. And an increasing number of providers allow their clients to use their products to “write” their own applications (some examples I came across are Iceberg, at www.geticeberg.com and Altova at www.altova.com).
But the users don’t actually “write” the new applications, they just instruct the original software to write it.
This begs the question: who owns software written by software?
I have written a full legal article on this, which is due to appear next week – I’ll keep you informed on that, so that, if you’re interested, you can read the full legal reasoning.
On this blog, I’m going to take a slightly lighter approach, focusing more on the business side of things.
First, let’s see what we mean by “software written by software”.
Is this like compilers or tools? Yes and no.
The software I will be talking about (let’s call it “Writing Software”) does more than compiling. When you use a compiler, you convert source code into object code. The compiler doesn’t actually “write” code (although it “creates” code), it translates source code into object code.
Writing Software does more. It actually produces the source code, on the basis of instructions given by its user. The user does not, however, write source code. The user instructions are much more generic. They consist of, e.g., when you want to build an ERM application, identifying “objects”, or “fields”. Then, the user will define relations between these objects or fields, typically from a drop down, or other restricted list. Finally, the user can design an algorithm within the Writing Software.
Then, he pushes “write program” and hey presto, a new software application is born.
So, who owns this new software application?
Is it the user?
Is it the owner/licensor of the Writing Software?
Is it the licensee of the Writing Software?
Is it nobody?
Or is it the Writing Software itself?
Why is this question important?
Because all business models around software are, at least partly, based on ownership of the code.
Whenever you “buy” software, you buy a license to use it, based on the ownership (directly or indirectly) in that software, of the seller of the license (who may or may not be the original licensor).
So, if it is unclear who owns software applications, a whole new interesting area of debate and questions arises.
I will deal with these questions in the next couple of days.
In the mean time, I’ll just leave you with the observation that the question “who owns software written by software” is a very narrow one. I’ll talk later about much broader implications: who owns the proceeds of artificial intelligence.
Watch this space.
Joren De Wachter
