Yesterday, the EFF filed an amicus brief signed by some of the big names in computer science and software engineering to support the court decision in Oracle vs. Google that APIs are not copyrightable. The brief is well worth reading because it lays out in detail many of the instances over the last decades in which the non-copyrightability of APIs has turned out to be important for innovation. I also support this view which is based on concept that functions or methods themselves are not copyrightable (their description with a specific choice of words is).

To date this is how the law has been applied: you can get a copyright to your specific code – in fact that right is automatic – but that does not extend to what that code does (its function). This is of course highly analogous to how copyright is applies in other domains such as books: the copyright protects the expression but not the idea (e.g. the words chosen in Antifragile are protected but not the idea of anti-fragility). A change here would imply a massive and unwarranted further extension of what copyright means.

Nonetheless the situation is somewhat frustrating for startups who spend time and effort defining elegant APIs. In an ideal world we would have an intellectual property regime that instead of the full powers of copyright simply provides an attribution requirement. So if someone implements the API you have designed, they need to attribute it to you (including whenever possible a link to you). That would in no way restrict the ability by third party to implement APIs but would provide some recognition and potentially customers for the originator.

Yesterday, the EFF filed an amicus brief signed by some of the big names in computer science and software engineering to support the court decision in Oracle vs. Google that APIs are not copyrightable. The brief is well worth reading because it lays out in detail many of the instances over the last decades in which the non-copyrightability of APIs has turned out to be important for innovation. I also support this view which is based on concept that functions or methods themselves are not copyrightable (their description with a specific choice of words is).

To date this is how the law has been applied: you can get a copyright to your specific code – in fact that right is automatic – but that does not extend to what that code does (its function). This is of course highly analogous to how copyright is applies in other domains such as books: the copyright protects the expression but not the idea (e.g. the words chosen in Antifragile are protected but not the idea of anti-fragility). A change here would imply a massive and unwarranted further extension of what copyright means.

Nonetheless the situation is somewhat frustrating for startups who spend time and effort defining elegant APIs. In an ideal world we would have an intellectual property regime that instead of the full powers of copyright simply provides an attribution requirement. So if someone implements the API you have designed, they need to attribute it to you (including whenever possible a link to you). That would in no way restrict the ability by third party to implement APIs but would provide some recognition and potentially customers for the originator.