The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Bliki: API_Copyright

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Martin Fowler

Posts: 1573
Nickname: mfowler
Registered: Nov, 2002

Martin Fowler is an author and loud mouth on software development
Bliki: API_Copyright Posted: May 31, 2013 8:38 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Martin Fowler.
Original Post: Bliki: API_Copyright
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Martin Fowler
Latest Posts From Martin Fowler's Bliki

Advertisement

Yesterday the Electronic Frontier Foundation released an amicus brief for a lawsuit on the topic of copyrighting APIs. The brief is a statement on behalf programmers who oppose the copyrighting of APIs. I'm one of the signatories to the amicus brief.

The software industry has long had a complicated relationship with intellectual property law. It's long been held that source code can be protected by copyright, preventing someone from just copying someone else's program without their consent. On the whole I'm in favor of using copyright in this way - as one who writes a lot of prose describing software development, the mechanism seems to fit well.

But that fit breaks down when it comes to interfaces of software components. The whole point of components, as I see it, is that they represent software elements that are independently replaceable and upgradeable [1]. Breaking down software systems into components allows competition to develop, as different groups compete with better or cheaper components. For this to work, components need to have common interfaces, which raises the question of how such interfaces can develop.

So far common interfaces mostly appear by interfaces becoming widely used and then widely copied. This can be intentionally, with component authors documenting their interfaces, or by reverse engineering of closed interfaces. Reverse engineering of closed interfaces has played a vital role in the development of software systems we use today - the amicus brief describes examples such as various elements of Unix, the BIOS of the IBM PC, and the SMB protocol for network sharing of hard drives.

This background was challenged recently by a case brought by Oracle against Google's use of Java for Android. There are a number of parts to this case, but a key question was whether the API to core java libraries was copyrightable. Last year a federal district court ruled that APIs were not copyrightable. Oracle is appealing against this, the amicus brief that we signed was organized by the EFF to uphold the district court's ruling.

I am not opposed to intellectual property in general, or the use of copyright for software. I do think it's reasonable for software developers to be able to protect their hard work through the course of an admittedly imperfect legal system. Nor do I deny that designing a good API is significant intellectual work. But like everything else in property law, it's about balancing interests. Copyrightable APIs would erect considerable barriers to innovation and competition, further limiting the ability of new entrants to disrupt markets and improve the software ecosystem. This threat is not a small one, and I'm happy to pay a small part in opposing it.

1: I took this definition from Ralph Johnson

Read: Bliki: API_Copyright

Topic: A new iOS App for software testers is born Previous Topic   Next Topic Topic: Bliki: ContinuousDelivery

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use