Discussion:
Are register names and locations under copyright?
(too old to reply)
Philipp Klaus Krause
2018-01-10 13:11:11 UTC
Permalink
SDCC, a free C compiler targeting microcontrollers wants to provide
header files that contain I/O register names and locations for their
targets. The header files are automatically generated from some files
from the hardware vendor (e.g. tables in datasheets or some database).

For some targets, SDCC already has such files (e.g.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/include/pic16/pic18f1320.h).

Problem: Hardware vendors want to impose non-free terms on the header
files (via a copyright claim on the files that the headers were
generated from).

Are the register names and locations under copyright? Is the generated
header file under copyright? If yes, who are the owners of the
copyright? Does the situation vary across jurisdictions?

SDCC developers are currently unsure about this. To err on the safe
side, all such headers live in a separate directory called "non-free"
since many years ago. The headers still live in the SDCC repository, are
distributed with tarballs, etc. The Debian package does not currently
include those headers.

Naturally, it would be good for SDCC users, if they could be confident
that they can use those headers in free software and if Debian could
include the headers in the package.

Philipp
Milan Kupcevic
2018-01-10 17:13:11 UTC
Permalink
Hi Philipp,


On 01/10/2018 08:11 AM, Philipp Klaus Krause wrote:
[...]
Post by Philipp Klaus Krause
Problem: Hardware vendors want to impose non-free terms on the header
files (via a copyright claim on the files that the headers were
generated from).
I'm not a lawyer and this is not a legal advice. My position on this
question is based on my personal experience. Your mileage may vary.

It is widely held in the IT industry, and in technical industries in
general, that interface descriptions and definitions can not be legally
protected as that would stop development and production of compatible
replacement parts by third parties. This widely held belief could be
changed by a court decision or a new law in any given jurisdiction at
any time.
Post by Philipp Klaus Krause
Are the register names and locations under copyright? Is the generated
header file under copyright? If yes, who are the owners of the
copyright? Does the situation vary across jurisdictions?
As it currently stands it is widely regarded that copyright on a header
file that just contains interface definitions is not enforceable. As
Debian packaging is concerned, our FTP masters have the last word on the
question if a particular file could or could not be included in a Debian
package.

Take a look at this example[0]:

Files: src/stab.h
Copyright: 1990 by Sun Microsystems, Inc
Comment: Contains interface definitions.
Copyright on interface definitions is widely regarded as not
enforceable.
License: unknown


In hope that this helps,

Milan


[0] https://sources.debian.org/src/avra/1.3.0-3/debian/copyright/
Paul Wise
2018-01-11 02:47:07 UTC
Permalink
Post by Milan Kupcevic
It is widely held in the IT industry, and in technical industries in
general, that interface descriptions and definitions can not be legally
protected as that would stop development and production of compatible
replacement parts by third parties. This widely held belief could be
changed by a court decision or a new law in any given jurisdiction at
any time.
As we saw in the Oracle v Google case over the Java APIs, this widely
held belief is not necessarily correct.

https://en.wikipedia.org/wiki/Oracle_America%2C_Inc._v._Google%2C_Inc.

The result of the case was that the Java APIs are copyrightable, but
that Google's use of them was fair use. Unfortunately fair use is not
internationally widespread and not the same everywhere it is
implemented.

https://en.wikipedia.org/wiki/Fair_use#Influence_internationally
--
bye,
pabs

https://wiki.debian.org/PaulWise
Milan Kupcevic
2018-01-11 06:09:11 UTC
Permalink
Post by Paul Wise
Post by Milan Kupcevic
It is widely held in the IT industry, and in technical industries in
general, that interface descriptions and definitions can not be legally
protected as that would stop development and production of compatible
replacement parts by third parties. This widely held belief could be
changed by a court decision or a new law in any given jurisdiction at
any time.
As we saw in the Oracle v Google case over the Java APIs, this widely
held belief is not necessarily correct.
https://en.wikipedia.org/wiki/Oracle_America%2C_Inc._v._Google%2C_Inc.
The result of the case was that the Java APIs are copyrightable, but
that Google's use of them was fair use. Unfortunately fair use is not
internationally widespread and not the same everywhere it is
implemented.
This case just confirms that the legal protection, so far, has not been
successfully enforced. Thus, the widely held belief still stands strong.
I'm not a lawyer, and this is not a legal advice.

Milan
Paul Wise
2018-01-11 02:57:27 UTC
Permalink
Post by Philipp Klaus Krause
Problem: Hardware vendors want to impose non-free terms on the header
files (via a copyright claim on the files that the headers were
generated from).
I think we need more details. Are the files the headers were generated
from publicly available? Do they list any copyright/license
information?
Post by Philipp Klaus Krause
Are the register names and locations under copyright? Is the generated
header file under copyright? If yes, who are the owners of the
copyright? Does the situation vary across jurisdictions?
SDCC developers are currently unsure about this.
I would strongly suggest SDCC developers obtain legal advice on this
topic, especially in light of Oracle v Google.

Software Freedom Conservancy may be able to help with this:

https://sfconservancy.org/
Post by Philipp Klaus Krause
For some targets, SDCC already has such files (e.g.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/include/pic16/pic18f1320.h).
I note this in the file you mention:

* This file is generated automatically by the cinc2h.pl, 2016-04-13
17:23:42 UTC.

In addition to the hardware vendors copyright issue, clearly this
header is not the source form under the GPL's "preferred form for
modification" requirements, nor under DFSG item 2 and therefore Debian
cannot distribute it without the source.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Philipp Klaus Krause
2018-01-11 09:13:27 UTC
Permalink
Post by Paul Wise
Post by Philipp Klaus Krause
Problem: Hardware vendors want to impose non-free terms on the header
files (via a copyright claim on the files that the headers were
generated from).
I think we need more details. Are the files the headers were generated
from publicly available? Do they list any copyright/license
information?
[…]
Post by Philipp Klaus Krause
For some targets, SDCC already has such files (e.g.
https://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/include/pic16/pic18f1320.h).
* This file is generated automatically by the cinc2h.pl, 2016-04-13
17:23:42 UTC.
In addition to the hardware vendors copyright issue, clearly this
header is not the source form under the GPL's "preferred form for
modification" requirements, nor under DFSG item 2 and therefore Debian
cannot distribute it without the source.
The source file would be pic16f1320.inc, which is part of gputils (which
is packaged in Debian, the .inc file gets installed to
/usr/share/gputils/header/pic16f1320.inc).

For the future (i.e. post 3.7.0 release), SDCC plans to no longer ship
the .h files for PIC in the tarball. Instead they would be generated at
build-time from the .inc source files in the installed gputils.

This however, is just the situation for the pic14 and pic16 backends. In
the future, SDCC might want to also have headers for the stm8 backend.
These could e.g. be generated by some script from the datasheets.

Philipp
Paul Wise
2018-01-11 09:49:58 UTC
Permalink
Post by Philipp Klaus Krause
The source file would be pic16f1320.inc, which is part of gputils (which
is packaged in Debian, the .inc file gets installed to
/usr/share/gputils/header/pic16f1320.inc).
Hmm, I'm not sure these files should be in Debian main, a lot of them
say "Copyright 1999-2014 Microchip Technology, All rights reserved"
without specifying any license.
Post by Philipp Klaus Krause
For the future (i.e. post 3.7.0 release), SDCC plans to no longer ship
the .h files for PIC in the tarball. Instead they would be generated at
build-time from the .inc source files in the installed gputils.
That sounds like a reasonable plan, except it runs into the above
problem. The current situation also runs into that problem though.
--
bye,
pabs

https://wiki.debian.org/PaulWise
Philipp Klaus Krause
2018-01-11 09:59:14 UTC
Permalink
Post by Paul Wise
Post by Philipp Klaus Krause
The source file would be pic16f1320.inc, which is part of gputils (which
is packaged in Debian, the .inc file gets installed to
/usr/share/gputils/header/pic16f1320.inc).
Hmm, I'm not sure these files should be in Debian main, a lot of them
say "Copyright 1999-2014 Microchip Technology, All rights reserved"
without specifying any license.
However, the files are just lists of register names and locations. So if
the files are not under copyright, I guess that copyright note could be
ignored?
Post by Paul Wise
Post by Philipp Klaus Krause
For the future (i.e. post 3.7.0 release), SDCC plans to no longer ship
the .h files for PIC in the tarball. Instead they would be generated at
build-time from the .inc source files in the installed gputils.
That sounds like a reasonable plan, except it runs into the above
problem. The current situation also runs into that problem though.
Well, SDCC came up with that plan for technical, not legal reasons. SDCC
pic14 and pic16 backends have a build-dependency on gputils anyway, so
not having the .h files in the SDCC tarball is no disadvantange to the user.

Philipp
Ian Jackson
2018-01-16 12:53:57 UTC
Permalink
Post by Philipp Klaus Krause
However, the files are just lists of register names and locations. So if
the files are not under copyright, I guess that copyright note could be
ignored?
Yes.

The ftpmasters seem to have agreed in the past, on this point,
according to the example supplied by Milan.

I suggest copying the "Comment".

Make sure that the source .inc really is just the list of register
names and locations, and doesn't contain (eg) discursive text, or
substantial assembler macros, or whatever.

Ian.

Continue reading on narkive:
Loading...