[dbtx]

> This is just plainly not true.

This is DH3. [0] I need some more red meat. :)

> Nobody on this thread has given a reasonable argument as to why APIs are not more or less like code.

I think they did, though. An API is designed and written, and then it is "a design". (OK "an interface" but that's jargon, the design and formal requirements and patterns are what matters) Code is designed and written, then it is "an implementation". If there's anything special about your design so that you want to control how and whether people are legally allowed to implement it, you get a patent, not a copyright. Then (IINM which seems probable because IANAL) the separate (perhaps royalty-paying) patent licensee can still copyright their own implementation. Don't get me wrong-- I don't want even more patents around software, I just hope people will call things what they are. I have to admit that I could merely be mincing words, if only because that's what I want to accuse someone else of doing. I don't envy the court.

[0] http://www.paulgraham.com/disagree.html

[jariel]

Yes, that's actually a good attempt at making the case, along the lines of some some of the amicus brief filings. (Most of the arguments on this thread are missing the point).

So here is where people are crossing streams I think:

'The interface' to something is not copyrightable as the law says today - fair enough.

But the description of said interfaces may in fact be.

In many cases, probably most, the API is literally part of the code - which is copyrighted already.

So it might be possible that the articulation of an interface is a creative work like anything else, but the implementation is not.

So you can release an implementation of some copyrighted platform - that does the exact same thing with the exact same interface, but the description of said interface in some descriptive language is copyrighted.

The paradox of the fact that the API is often part of the copyrighted code ... is hard to get past.

[int_19h]

This part is pretty settled, I think - an .h file is copyrightable, for example, because it is code (that happens to define an API). That's fine, well-established, and people have worked around it for a long time now - e.g. MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

The question at stake is whether the API itself is copyrightable, and that workaround is therefore not sufficient.

It has been conflated in this particular case, because IIRC there were some infringement claims around the literal contents of the .java files, and others over the "structure, sequence, and organization" (i.e. the API proper). But then for that first part, Google pointed out that in Java, there is usually only one way to describe one particular API; and if you use the standard coding style, then even independent definitions will end up looking the same verbatim.

[colejohnson66]

> MinGW uses their own <windows.h> for this exact reason, even though it describes the same API as the one that comes with MSVC.

I thought they provide their own because they don’t want to assume that MSVC is installed too.

[int_19h]

If it weren't copyrighted, they could have just copied it as is, instead of rewriting it from scratch.

[colejohnson66]

The file may be copyrighted, but the discussion here is whether the API is or not.

[int_19h]

In this subthread, we were discussing "the interface something is not copyrightable as the law says today, but the description of said interfaces may in fact be". The header file was an example of how this is already generally assumed to be the status quo - the API is not copyrighted, but the particular description of that API, in form of <windows.h> that ships with MSVC, is copyrighted. So MinGW could do this for Win32 API, so long as they rolled their own header.

[jariel]

Yes, thanks. As I see it, that 'conflation' to me is a not just some odd mangling of issues, it's a material to the nature of what's being created.