Header file legal issues (was Re: process.h patch)
dfe at infinite-internet.net
Thu Feb 15 01:36:39 CST 2001
Gavriel State wrote:
> David Elliott wrote:
> > Part of the reason for rewriting the include files was also for licensing. If we
> > rewrite the header files ourselves then it's pretty much guaranteed that they can
> > be licensed exactly the same as Wine. If we "borrow" them then who knows. Most
> > Windows compilers I have seen have some sort of license on what you can do with
> > their header files that might not make them fit for inclusion into Wine.
> > An idea that just popped into my head is maybe seeing if we can get a windows
> > compiler maker (e.g. Borland) to donate a full set of headers under the Wine
> > license. However they may have licensed them with certain terms and be unable to
> > do that.
> While Jon has addressed this issue in regards to the MSVCRT headers, this might
> be a good time to point out that the legality of enforcing copyright on header
> files through licensing restrictions is questionable.
> I'll preface this with the usual mention of the fact that I am not a lawyer, nor
> do I play one on TV. Please consult a qualified professional before taking action
> on anything I've written.
> Copyright law does not protect idea, just the expression of them. Several court
> decisions have been rendered which suggest that the 'purely functional' elements
> of a computer program are not copyrightable. There are several cases that
> explicitly deal with the issue of copyright and header files. The most relevant
> one for Wine development is probably the 1992 decision in Sega v. Accolade, where
> Accolade reverse engineered the headers for Sega's ROM libraries in order to
> develop games compatible with Sega's hardware without paying Sega's royalties.
> The court in that case said:
> Computer programs pose unique problems for the application of the
> "idea/expression distinction" that determines the extent of copyright
> protection. To the extent that there are many possible ways of
> accomplishing a given task or fulfilling a particular market demand,
> the programmer's choice of program structure and design may be highly
> creative and idiosyncratic. However, computer programs are, in essence,
> utilitarian articles -- articles that accomplish tasks. As such, they
> contain many logical, structural, and visual display elements that are
> dictated by external factors such as compatibility requirements
> and industry demands... In some circumstances, even the exact set of
> commands used by the programmer is deemed functional rather than
> creative for the purposes of copyright. When specific instructions,
> even though previously copyrighted, are the only and essential means
> of accomplishing a given task, their later use by another will not
> amount to infringement.
Hmm, I am not so sure I like all of that. Program code serves two purposes. For one
thing it is functional, and for another (and actually for the most part) it has a
human readable structure.
I think it is actually very similar in nature to sheet music. The specific
typesetting of a piece of sheet music can be copyrighted, so photocopying it is
illegal. However, if the copyright has expired on the music itself then you can copy
it by hand (or hell, even by machine) and as long as it is not an exact duplicate then
you can make as many copies of that as you want.
> Since Wine absolutely requires the specific header file layout, strucutre
> and function names, etc to be the way the Windows headers express them,
> there is good cause to believe that the header files are unprotected by
I would say the specific byte for byte header files are, especially the comments in
the code which are most certainly copyrightable just like any text. However, you
could easily make the point that you can define the same interface and do so "in your
own words" and then it would be perfectly fine. The headers would of course look
almost exactly the same as the originals given the nature of having to provide the
same interface, but it is a new implementation of the same functionality.
> In fact, development tool licenses that attempt to restrict usage of
> these headers may even constitute anti-trust copyright misuse. Early
> versions of MS Visual C++ contained a shrinkwrap license that forbade
> the use of the product to create software for platforms other than
> Windows. Later revisions (ie: SP3) removed that restriction, so perhaps
> MS realized that this was not protectable.
You'd think that would be a "Well, DUH!" But they always want to protect as many
rights as they have, or don't have but could possibly have.
> One fly in the legal ointment is that while the headers may not be
> copyrighable, the shrinkwrap license may still be legal as a contract.
> There's a case where a court suggested that someone who buys a copy
> of a product that contains a shrinkwrap license agreement and unwraps
> it is legally bound to follow it, while the person who later finds the
> unwrapped CD 'on the street' with no such license is allowed to copy
> the portions that are unprotected by copyright. It's unclear where
> the anti-trust issue fits in there.
Shrink-wrap licenses are shit. I can just see a team of hungry lawyers having a field
day with these pretty soon. Eventually someone with lots 'o cash is gonna say that
the shrink-wrap license is bull, get a lawyer to defend the argument and it'll be over
and done with. Hell, businesses have gotten out of signed contracts because if one
party says one thing, but contradicts it in the contract it really doesn't matter
since the other party can then say they signed it based on the first parties word.
Normally you want to let the lawyers handle reading and signing, that is their job
> Food for thought, anyhow...
Yeah, it's interesting. We are entering into some somewhat troubling times where
everyone is trying to defend rights they don't even have and shouldn't have. And yet
we are passing stupid laws taking away fundamental rights that we do have and should
have. Just saw the appeal verdict from B&N vs. Amazon. That is a step in the right
direction, but there are still many more steps to take.
More information about the wine-devel