| |||||||||||||
OSBC: Life at the edge of the GPLOSBC: Life at the edge of the GPLPosted Mar 30, 2009 4:11 UTC (Mon) by jeffnorman (guest, #57684)In reply to: OSBC: Life at the edge of the GPL by JoeBuck Parent article: OSBC: Life at the edge of the GPL Alas, what I said in context was that the sequence and arrangement of otherwise non-copyrightable elements of sufficiently large header file would likely be copyrightable. In other words, even if you could strip the entire set of header files used in a particular API of any copyrightable elements (a task that is a lot more difficult than it would otherwise appear in a modern API that consists of multiple header files, object oriented programming that combines code with "mere" data structures, etc.), the sequence and arrangement of the non-copyrightable information in such header files is likely independently copyrightable. That is why in clean rooms we usually require the creation of a new API.
(Log in to post comments)
OSBC: Life at the edge of the GPL Posted Mar 30, 2009 11:11 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
So in other words, if you created your own set of header files and your own stub shared libraries for compiling and linking against, with only the most basic knowledge of the implementation required for this task, that the applications linking against them could still count as derivative works? I suppose that this is perfect for people putting their work under the GPL.
OSBC: Life at the edge of the GPL Posted Mar 30, 2009 14:56 UTC (Mon) by jeffnorman (guest, #57684) [Link]
in a clean room, the "dirty" team will prep a new API spec that will be limited to the specific functionality required, and reviewed by legal to make sure its all non-copyrightable. The "clean" team will then write a new set of headers and stubs from the new spec. This will provide maximum protection (though never perfect) from a derivative works claim. Cumbersome, no doubt.
|
|||||||||||||