Библиотека сайта rus-linux.net
Anything that is not public domain has a copyright, possibly more than one. Under U.S. federal law, the authors of a work hold copyright even if there is no copyright notice.
Who counts as an author under copyright law can be complicated, especially for software that has been worked on by many hands. This is why licenses are important. They can authorize uses of code in ways that would be otherwise impermissible under copyright law and, drafted appropriately, can protect users from arbitrary actions by the copyright holders.
In the proprietary software world, the license terms are designed to protect the copyright. They're a way of granting a few rights to users while reserving as much legal territory as possible for the owner (the copyright holder). The copyright holder is very important, and the license logic so restrictive that the exact technicalities of the license terms are usually unimportant.
As will be seen below, the copyright holder typically uses the copyright to protect the license, which makes the code freely available under terms he intends to perpetuate indefinitely. Otherwise, only a few rights are reserved and most choices pass to the user. In particular, the copyright holder cannot change the terms on a copy you already have. Therefore, in open-source software the copyright holder is almost irrelevant — but the license terms are very important.
Normally the copyright holder of a project is the current project leader or sponsoring organization. Transfer of the project to a new leader is often signaled by changing the copyright holder. However, this is not a hard and fast rule; many open-source projects have multiple copyright holders, and there is no instance on record of this leading to legal problems. Some projects choose to assign copyright to the Free Software Foundation, on the theory that it has an interest in defending open source and lawyers available to do it.
For licensing purposes, we can distinguish several different kinds of rights that a license may convey. There are rights to copy and redistribute, rights to use, rights to modify for personal use, and rights to redistribute modified copies. A license may restrict or attach conditions to any of these rights.
The Open Source Definition is the result of a great deal of thought about what makes software “open source” or (in older terminology) “free”. It is widely accepted in the open-source community as an articulation of the social contract among open-source developers. Its constraints on licensing impose the following requirements:
- An unlimited right to copy be granted.
- An unlimited right to redistribute in unmodified form be granted.
- An unlimited right to modify for personal use be granted.
The guidelines prohibit restrictions on redistribution of modified binaries; this meets the needs of software distributors, who need to be able to ship working code without encumbrance. It allows authors to require that modified sources be redistributed as pristine sources plus patches, thus establishing the author's intentions and an “audit trail” of any changes by others.
The OSD is the legal definition of the “OSI Certified Open Source” certification mark, and as good a definition of “free software” as anyone has ever come up with. All of the standard licenses (MIT, BSD, Artistic, GPL/LGPL, and MPL) meet it (though some, like GPL, have other restrictions which you should understand before choosing it).
Note that licenses that allow only noncommercial use do not qualify as open-source licenses, even if they are based on GPL or some other standard license. Such licenses discriminate against particular occupations, persons, and groups, a practice which the OSD's Clause 5 explicitly forbids.
Clause 5 was written after years of painful experience. No-commercial-use licenses turn out to have the problem that there is no bright-line legal test for what sort of redistribution qualifies as ‘commercial’. Selling the software as a product qualifies, certainly. But what if it were distributed at a nominal price of zero in conjunction with other software or data, and a price is charged for the whole collection? Would it make a difference whether the software were essential to the function of the whole collection?
Nobody knows. The very fact that no-commercial-use licenses create uncertainty about a redistributor's legal exposure is a serious strike against them. One of the objectives of the OSD is to ensure that people in the distribution chain of OSD-conforming software do not need to consult with intellectual-property lawyers to know what their rights are. OSD forbids complicated restrictions against persons, groups, and occupations partly so that people dealing with collections of software will not face a combinatorial explosion of slightly differing (and perhaps conflicting) restrictions on what they can do with it.
This concern is not hypothetical, either. One important part of the open-source distribution chain is CD-ROM distributors who aggregate it in useful collections ranging from simple anthology CDs up to bootable operating systems. Restrictions that would make life prohibitively complicated for CD-ROM distributors, or others trying to spread open-source software commercially, have to be forbidden.
On the other hand, the OSD has nothing to say about the laws of your jurisdiction. Some countries have laws against exporting certain restricted technologies to named ‘rogue states’. The OSD cannot negate those, it only says that licensors may not add restrictions of their own.
Here are the standard open-source license terms you are likely to encounter. The abbreviations listed here are in general use.
We'll discuss these licenses in more detail, from a developer's point of view, in Chapter═19. For the purposes of this chapter, the only important distinction among them is whether they are infectious or not. A license is infectious if it requires that any derivative work of the licensed software also be placed under its terms.
Under these licenses, the only kind of open-source use you should really worry about is actual incorporation of the free-software code into a proprietary product (as opposed, say, to merely using open-source development tools to make your product). If you're prepared to include proper license acknowledgements and pointers to the source code you're using in your product documentation, even direct incorporation should be safe provided the license is not infectious.
The GPL is both the most widely used and the most controversial infectious license. And it is clause 2(b), requiring that any derivative work of a GPLed program itself be GPLed, that causes the controversy. (Clause 3(b) requiring licensors to make source available on physical media on demand used to cause some, but the Internet explosion has made publishing source code archives as required by 3(a) so cheap that nobody worries about the source-publication requirement any more.)
Nobody is quite certain what the “contains or is derived from” in clause 2(b) means, nor what kinds of use are protected by the “mere aggregation” language a few paragraphs later. Contentious issues include library linking and inclusion of GPL-licensed header files. Part of the problem is that the U.S. copyright statutes do not define what derivation is; it has been left to the courts to hammer out definitions in case law, and computer software is an area in which this process (as of mid-2003) has barely begun.
At one end, the “mere aggregation” certainly makes it safe to ship GPLed software on the same media with your proprietary code, provided they do not link to or call each other. They may even be tools operating on the same file formats or on-disk structures; that situation, under copyright law, would not make one a derivative of the other.
At the other end, splicing GPLed code into your proprietary code, or linking GPLed object code to yours, certainly does make your code a derivative work and requires it to be GPLed.
It is generally believed that one program may execute a second program as a subprocess without either program becoming thereby a derivative work of the other.
The case that causes dispute is dynamic linking of shared libraries. The Free Software Foundation's position is that if a program calls another program as a shared library, then that program is a derivative work of the library. Some programmers think this claim is overreaching. There are technical, legal, and political arguments on both sides that we won't rehash here. Since the Free Software Foundation wrote and owns the license, it would be prudent to behave as if the FSF's position is correct until a court rules otherwise.
Some people think the 2(b) language is deliberately designed to infect every part of any commercial program that uses even a snippet of GPLed code; such people refer to it as the GPV, or “General Public Virus”. Others think the “mere aggregation” language covers everything short of mixing GPL and non-GPL code in the same compilation or linkage unit.
This uncertainty has caused enough agitation in the open-source community that the FSF had to develop the special, slightly more relaxed “Library GPL” (which they have since renamed the “Lesser GPL”) to reassure people they could continue to use runtime libraries that came with the FSF's GNU compiler collection.
You'll have to choose your own interpretation of clause 2(b); most lawyers will not understand the technical issues involved, and there is no case law. As a matter of empirical fact, the FSF has never (from its founding in 1984 to mid-2003, at least) sued anyone under the GPL but it has enforced the GPL by threatening lawsuit, in all known cases successfully. And, as another empirical fact, Netscape includes the source and object of a GPLed program with the commercial distribution of its Netscape Navigator browser.
The MPL and LGPL are infectious in a more limited way than GPL. They explicitly allow linking with proprietary code without turning that code into a derivative work, provided all traffic between the GPLed and non-GPLed code goes through a library API or other well-defined interface.
This section is directed to commercial developers considering incorporating software that falls under one of these standard licenses into closed-source products.
Having gone through all this legal verbiage, the expected thing for us to do at this point is to utter a somber disclaimer to the effect that we are not lawyers, and that if you have any doubts about the legality of something you want to do with open-source software, you should immediately consult a lawyer.
With all due respect to the legal profession, this would be fearful nonsense. The language of these licenses is as clear as legalese gets — they were written to be clear — and should not be at all hard to understand if you read it carefully. The lawyers and courts are actually more confused than you are. The law of software rights is murky, and case law on open-source licenses is (as of mid-2003) nonexistent; no one has ever been sued under them.
This means a lawyer is unlikely to have a significantly better insight than a careful lay reader. But lawyers are professionally paranoid about anything they don't understand. So if you ask one, he is rather likely to tell you that you shouldn't go anywhere near open-source software, despite the fact that he probably doesn't understand the technical aspects or the author's intentions anywhere near as well as you do.
This isn't to say you should treat these licenses as jokes. That would be disrespectful of the creativity and sweat that went into the software, and you wouldn't enjoy being the first litigation target of an enraged author no matter how the lawsuit came out. But in the absence of definitive case law, a visible good-faith effort to meet the author's intentions is 99% of what you can do; the additional 1% of protection you might (or might not) get by consulting a lawyer is unlikely to make a difference.