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