[Fedora-legal-list] SDCC: Is non-free tree actually non-free?

[Tom Callaway]

On 10/01/2014 06:09 PM, Lubomir Rintel wrote:
> Hi,
> 
> SDCC ("sdcc" RPM) source package ships with a "device/non-free"
> hierarchy. Its header indicate that it's generated from files with usage
> restriction and thus can not be distributed under the terms of GPL.
> 
> The files are (mainly?) hardware descriptions -- addresses of memory
> locations, their symbolic names and eventually bit field definitions
> with symbolic names of the bits. I believe they're absolutely essential
> for interoperability with other (proprietary) tools.
> 
> Here's an example, for a single supported device:
> http://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/lib/pic14/libdev/pic12f675.c
> http://sourceforge.net/p/sdcc/code/HEAD/tree/trunk/sdcc/device/non-free/include/pic14/pic12f675.h
> 
> I am not actually sure whether the notice in the header is correct,
> whether the definitions in question are copyrightable and would like a
> lawyer opinion on that. (I'm also not sure whether the court decision on
> Oracle v. Google case about Java API is relevant in this context.)
> 
> If the code in question is in fact non-free what would be the proper way
> of creating free equivalents? Reading the existing code and datasheets
> and writing down the symbols? Would processing them automatically do?
> Also, maybe we ought to remove it from the source package as well in
> that case.

A) We have to assume the header notices are correct, in the absence of
evidence. These files need to be removed from the sdcc source tarball
(at least Fedora's copy, if not upstream).

B) As to free equivalents, you generally have to take a clean-room
design approach to these efforts.
(http://en.wikipedia.org/wiki/Clean_room_design)

hth,

~tom

==
Fedora Legal (IANAL, this is not legal advice)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcallawa.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/legal/attachments/20141007/afd930c5/attachment.vcf>