Quite a while back we asked Dan Ravicher, a young attorney who is personally interested in Open Source and Free Software licensing issues, a bunch of questions on the subject. We waited and waited for his answers, and the wait turned out to be worthwhile because Dan ended up writing what amounts to a legal FAQ for Open Source and Free Software developers. This is important reading for anyone involved in any way with Open Source or Free Software development.
Attorney Interview Disclaimer:
Legal opinions posted on Slashdot are for general information purposes only and should not be taken as specific legal advice. If that's what you need, you should consult a lawyer familiar with the laws in your jurisdiction about your situation. Also, please remember that everything you read here represents Dan's personal opinion, which is not necessarily shared by his employer, Brobeck, Phleger & Harrison LLP, or any of Brobeck's nearly 1000 other attorneys.
Now the interview itself...
When will source code be considered speech?
Every programmer knows that source code is speech, and should be protected like any other speech. However, the courts just don't seem to realize that, probably because none of the judges have ever been programmers. What would it take for the court system to generally acknowledge that source code is speech, and how long will it take for that to happen? What do you think will be the biggest ramifications if/when it does happen?
Source code is speech, but not all speech receives the same amount of First Amendment protection. Due to its functionality, source code cannot receive the highest form of First Amendment Protection. But source code that is expressive in nature may receive some First Amendment protection.
I have some good news and some bad news.
The good news is that the few courts to consider the issue concluded that source code is speech. Further, in the DeCSS case, it seems as though the federal appeals court in New York will uphold the lower court judge who also concluded that source code is speech. However, the bad news is that the First Amendment's protection of speech is not absolute and not all speech gets the same amount of First Amendment protection.
The amount of protection given particular speech depends upon it's content. While some speech can easily be categorized as political, commercial, verbal acts or otherwise, First Amendment analysis often looks at the speech's expressiveness as opposed to its functionality to determine the corresponding level of protection. Purely expressive speech regarding public affairs, politics and government (think "F--- the draft!" on the back of a jacket worn by an individual with no intent to cause imminent lawlessness) gets heightened First Amendment protection, while purely functional speech (think "Do you have any drugs?" to an undercover police officer or "I accept" to a party which has offered a contract) gets little First Amendment protection. This leaves speech which is both expressive and functional, such as commercial speech (think "Eat at Joe's!"), lying somewhere in the middle. Further, indecent speech (think adult porn) gets very little protection while obscene speech (think child porn) gets no protection whatsoever.
Since source code is by its nature functional, it seems unlikely that any court would ever find that it is purely expressive. However, the courts which have addressed the issue have concluded that source code can also be expressive. In fact, in 1999 a federal court in California wrote, "While source code can be easily compiled into object code by a user, ignoring the distinction between source and object code obscures the important fact that source code is not meant solely for the computer, but is rather written in a language intended also for human analysis and understanding." Therefore, there is no universal answer to the question of how much First Amendment protection applies to source code. Rather, the issue depends in part on the particular expressive versus functional nature of the source code in question.
However, although the speech involved may be an important element, the true focus of First Amendment analysis is whether a particular law unconstitutionally abridges free speech. Courts ask whether a particular law violates the First Amendment, not whether particular speech deserves First Amendment protection. Therefore, speech can not be looked at in isolation. Rather, a particular law must be looked at to determine how it affects speech. Laws aimed at speech with a certain message are deemed "content-based" and most often receive heightened scrutiny. On the other hand, laws which are "content-neutral", such as time-place-manner restrictions, most often receive less scrutiny. For instance, in the DeCSS case, the court is looking at the Digital Millenium Copyright Act to determine what level of scrutiny it shall receive in relation to its regulation of speech.
Another issue which deserves attention is the fact that the First Amendment rights we all have are alienable. That is, we can bargain away those rights through a contract. Confidentiality agreements are a prime example of one party giving up their right to speak which are routinely enforced. This issue as it relates to license agreements and their prohibition against publishing reviews or benchmark test results is addressed in response to question 8 below.
OFF TOPIC RESPONSE TO COMMENT
Lastly, I just wanted to respond briefly to your comment about judges not being computer programmers. While this is true, so is the fact that most computer programmers are not lawyers. However, this doesn't prevent computer programmers from understanding difficult legal issues. Likewise, judges are generally capable of understanding computer programming issues.
No funds, no change of winning?
I'm a freelance programmer, and like most programmers I do it for the love of the "art", and because of that most of my creations are licensed under GPL.. However, my question is, what would happen if Big Corporation X were to take my code, integrate it into a proprietary system, and sell it for millions, ignoring all demands to release source to the modifications (and thus breaking the GPL). What could I honestly do besides writing letters threatening legal action?
I obviously don't have the funds to compete in the courtroom with Big Corporation X, and even if I were to try, the expense and time alone would set me into debt for probably the greater part of the rest of my life. What chance does the GPL or any other Open Source licensed software have, if a good part of it's development team is composed of just average guys with bills, debt and little free time?
Keep writing good code.
You are correct; without substantial resources, it is extremely difficult to successfully enforce your intellectual property rights against a major software company. However, I strongly urge you to not underestimate the power that individuals and small organizations have to cause change.
For instance, you could assign your rights to an entity who is sympathetic to the open source movement and who has the resources to vindicate your interests. Many large entities in the open source world (including the Free Software Foundation and Sun) ask developers to assign their interests back to them. This coalesces the ownership into one entity which has the resources to bring legal actions to assert the copyright interests in the code. [Note: This is discussed further in response to question 9 below.] Further, it might be possible to find a law firm willing to take a copyright infringement case on a contingent fee basis. This prevents the "little guy" from being denied "his day in court."
Also realize that the courtroom is not the only place (in fact not even the most important place) you can compete with Big Corporation X. The court of public opinion often favors the David over the Goliath. The key here is to make sure the general public knows how you are helping them, and that "hacker" is not a negative term. Small businesses are often noted for better customer service, better product and better innovation than their multi-national counterparts. Further, publicity is very inexpensive and can be extremely helpful. For example, just today (June 4, 2001) a New York Times article with the headline, "Open-Source Movement Advances," presented the free software movement and the open source concept in a very positive light.
In the meantime, it is my view that the best thing you can do is keep writing code. And not just any code, write the best damn code you can. Write code that is pioneering and revolutionary and causes the entire software development community to recognize it as singly that of the open source realm. Write code that solves problems closed source developers don't even know exist. Spend your valuable time addressing programming issues, not legal ones. After all, you chose to be a programmer, not a lawyer.
Now, this may lead to your code being more desirable in the eyes of those with bad faith intent, but it will also be more attractive to those with good faith intent. I encourage you to be receptive to all who wish to learn about and support your programming, including non-programmers such as business people, lawyers, students, etc. Once there's a gathering of individuals around your code (or a project which your code is part of), it won't be as hard to organize an effective intellectual property defense scheme. Odds are that someone in this group will have the legal, business, public relations, or other training and experience to worry about those issues while you continue to write damn good code. If you, the other developers, and the supporting folks pool resources, you may soon have sufficient capability to vindicate your combined interests.
Further, I urge you to not be overly cynical about our justice system. Yes, there are flaws which subject our legal system to manipulation and abuse and, yes, things move slowly and sometimes backward for periods, but I truly believe that our system is pretty good and eventually produces the correct results.
by Flying Headless Goku
A common justification for choosing an open source license, and putting up with all the license-compatibility issues, over simply releasing the code into the public domain is fear of litigation. Do you believe that the creator of public domain software (perfection disclaimed, use at own risk) is at any greater legal risk than the creator of open-source licensed software in the case of costly software failure? (I'm especially interested in any relevant precedent you are aware of)
Yes, one who releases code into the public domain has greater litigation exposure than one who only releases the code through valid contracts (licenses) which include limitation of liability and disclaimer of warranty terms. The default rules for relationships amongst parties (the ones that apply in the absence of a valid contract) are based in tort and include negligence, warranties and other basis of liability. However, when the parties enter a valid contract, the contract's terms supercede the default rules unless the terms violate a statute, a constitution or public policy. Limitation of liability and warranty disclaimers contained in valid contracts (which are used to limit risks to the developer) are routinely upheld by courts.
However, whether mass-market public software licenses (such as the GPL, MozPL, IBMPL, etc.) are enforceable has yet to be addressed, or even litigated. This is why I wrote my paper; the uncertainty surrounding the enforceability of such licenses causes inefficient waste by those parties who wish to use such licenses in that they will have to assume risk associated with this uncertainty.
In your detailed paper, you note:
I am interested on the implications of the fact of Microsoft's monopoly in as it applies to licensing. While it can be argued that the two issues are separate, and one is not relevant to the other, many people look at the practices of Microsoft in this regard and view it with horror and contempt. Are there instances where such licensing practices impose a non-legitimate enforcement of "rights", and in fact constitute improper maintenance of a monopoly? Or do people have these separate issues confused, when they should be treated separately?37. For instance, under the first sale doctrine, an owner of a piece of software can transfer her program to whomever and for whatever she desires. The use of a license prevents this doctrine from applying, which allows computer programming firms to price-discriminate between customer characteristics. If Microsoft wants to give Windows software to public schools at a cost blow the production cost and the transaction consummates a sale, the first sale doctrine would apply, and the school could resell the programs at a higher price to a corporation, retaining the difference. This would cause Microsoft to charge all customers one price, either by lowering its price, forcing it to run at a loss, or raising its price, thus making the program unavailable to schools and other meagerly funded organizations. This result is economically inefficient and would most assuredly be politically unpopular.
Yes, intellectual property licensing implicates antitrust law. License provisions which have a net anticompetitive effect are illegal.
Yes, since intellectual property licensing can be anticompetitive, antitrust law is implicated. Antitrust law holds that any anticompetitive effects of intellectual property licensing are permissible only if they are outweighed by their procompetitive effects. One highly important factor in this analysis is the market power of the parties involved, specifically if either party is a monopoly.
As you mention, the Department of Justice deemed Microsoft ("MS") to have a monopoly in certain markets and to have engaged in licensing with net anticompetitive effects. MS first came under scrutiny for its licenses with OEM's that were designed to achieve long term exclusivity. That time a settlement was reached by which Microsoft agreed to reduce the term of it's agreements and allow for OEM's to install other operating systems on their computers. The second round of scrutiny currently under review by a federal appeals court in Washington involves MS requiring the bundling of Internet Explorer with Windows and is still being litigated. The dispute in that case centers around whether MS has monopoly power and whether the intellectual property licensing provisions at issue have a net anticompetitive effect.
Images and Sounds
How does the GPL affect non-sourcecode files that are part of an application?
Specifically, I'm concerned about the images and sounds that are included with a game I'm working on.
Does the GPL "contaminate" these other files that are included? If so, how do "source" and "binary" distribution apply to images and sounds.
The GPL may "contaminate" sound and image files if they are part of a whole work, and that work is based on a GPL licensed program.
The relevant part of the GPL reads,
Therefore, under the GPL, if the non-source code files are "distributed as part of a whole which is a work based on the [GPL'd] program," then the whole application, including those non-source code files, must be distributed under the GPL. However, if the non-source code files are not "based on the [GPL'd] Program" and are "merely aggregated" with the GPL'd program for distribution, then those non-source code files do not have to be distributed under the GPL. This means that the issue lies in how the non-source code files are incorporated into or with the GPL'd program.If identifiable sections ... are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. ... the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
If no source code exists for parts of the work, section 3 of the GPL states that "the preferred form of the work for making modifications to it," must be distributed in order to satisfy the "source" distribution requirement. Since I have very little technical knowledge, I'm not sure exactly what is "the preferred form" for making modifications to image and sound files.
There are also two other issues which you might want to think about. First, no court has yet ruled on the validity of the GPL. Therefore, the above section may be held unenforceable. Second, if you are the complete owner of all the copyrights in either the non-source code files or the program, you have the ability to license those copyrights under both the GPL and other licenses, if you so choose. Say for instance, a GPL'd game comes your way and you wish to add graphic X. You create graphic X in a way which creates in you all its copyrights. If you then incorporate graphic X into the game, the enhanced game must be distributed under the GPL. However, you can also distribute your graphic X under other licenses, including closed source.
Helping avoid contributory and vicarious liability
Fred von Lohmann wrote a White Paper for the EEF concerning avoidance of "contributory and vicarious copyright infringement" (being liable for writing software that promotes "fair use", but can be used for copyright infringement).
In that, he states guidelines for developers. One of the guidelines is: "Be open source".
I would think Open Source would set you up for liability in such matters: anybody who modified your code, making it able to infringe on copyrights, would make you vicariously liable for opening the code in the first place.
Or, take for example, TiVo. Their systems are open source, they've posted their kernel and tool modifications on their web site (as per the GPL). Now they're worried that someone could use that to easily create code that will allow MPEG extraction from the unit (and widespread distribution of copyrighted materials).
I'm not sure how being open source can protect a software developer from such litigation.
Can you explain this?
Whether one is liable for contributory and vicarious copyright infringement is an extremely fact specific inquiry. Being open source, by itself, does nothing to absolve one of liability for contributory and vicarious liability.
For those who have not had the opportunity to read von Lohmann's paper, let me restate the underlying law regarding contributory and vicarious copyright infringement before addressing your question.
Neither contributory nor vicarious copyright infringement claim that the defendant violated any copyright; rather they claim the defendant helped or benefited from someone else's copyright infringement. First and most obvious, both forms of liability require the copyright owner to show actual copyright infringement by someone. Whether or not the source code of the program is released to the public won't make a difference on the finding of this element.
Along with the showing of actual infringement, contributory infringement requires the plaintiff copyright owner show (1) the defendant actually knew or reasonably should have known of the direct infringement at the time (2) the defendant induced, caused or materially contributed to the direct infringement. For instance, one can be liable for contributory infringement if they release a software product that is used to infringe copyrights without any substantial non-infringing uses. Vicarious infringement requires the plaintiff copyright owner to show (1) the defendant could control or oversee the direct infringement and (2) the defendant received benefit from the infringement. Since element (2) for both of these tests has been relaxed by the courts, the discussion properly focuses on the knowledge element for contributory infringement and the control element for vicarious infringement.
Being open source in and of itself most likely won't make any difference for these elements. However, being open source, as opposed to proprietary, may make it easier for the initial developer (or one way upstream from the current version) to argue lack of control or knowledge, especially if the project undergoes significant development by downstream developers without any involvement or control by the original author. This requires the open source code to be entirely released without any continuing control, monitorization or ownership at a point well before the time that the code is known to have infringement capabilities. [Note: reasons why open source developers may want to keep control and/ or ownership over their projects are discussed in the responses to Questions 2 and 9.]
Therefore, if the open source developer retains control over the program or if the version of the program used to commit copyright infringement is similar to the version of the program originally released by the open source developer, being open source does nothing to reduce potential contributory or vicarious copyright infringement. Other actions, such as providing maintenance or support, might also support a finding of contributory or vicarious copyright infringement.
Without putting words in his mouth, what I think von Lohmann was trying to say was not "be open source", but rather "be extremist" by selecting either "total control or total anarchy" as he puts it. He advocates either retaining complete and entire dominion over your code and the users of your code so that you can prevent any copyright infringement or, at the other extreme, releasing the code entirely to the public without any ability to control or determine how it develops. In order to decide which is better for a project, this benefit of a potential reduction in liability exposure should be measured against the associated consequences of loosing all ability to control or receive financial benefit from the project.
Lastly, when thinking about contributory and vicarious liability, open source developers should also consider the Digital Millenium Copyright Act (17 U.S.C. 1201). The DMCA isn't directly concerned with copyright infringement, rather it addresses the technological measures that some copyright owners use to control access to their works. For instance, a court recently held (and the issue was not appealed) that CSS is a technological measure that effectively controls access to movies. In essence, the main copyright laws protect the property, while the DMCA protects the fence which the property owner erects around her property.
Specifically, the DMCA states that as of Oct. 28, 2000, "No person shall circumvent a technological measure that effectively controls access to a work." Further, the DMCA says the following:
As the DeCSS case demonstrates, these provisions expose software developers to potential liability if they create programs which can be used to defeat technological measures.No person shall manufacture, import, offer to the public, provide or otherwise traffic in any technology, product service, device component, or part thereof, that -
(A) is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work;
(B) has only limited commercially significant purpose or use other than to circumvent a technological measure that effectively controls access to a work; or
(C) is marketed by that person or another acting in concert with that person with that person's knowledge for use in circumventing a technological measure that effectively controls access to a work.
Big ballpark hypothetical
Okay, some unknown hacker creates his/her foo application and releases the source under GPL. Something occurs that leads him/her to suspect that the foo source has been incorporated into a commercial product that isn't following the terms of the GPL with regards to rereleasing the source. Furthermore, the things that lead him/her to suspect this aren't basic paranoia -- someone with a conscience and access to the suspect source has leaked information about it or whatnot. Or maybe something else -- point is, there is a case that could be made.
From a PRACTICAL standpoint, what sort of things would this unknown hacker have to do to make their case? Would it be possible from a practical point of view under (eg) the United States legal system for this unknown hacker to take the company to court? What sorts of costs would he/she incur? What sort of time-frame would it take to achieve resolution? What sorts of potential rewards or compensation could he/she expect? Are there any precedents that are analogous to this situation?
It would be difficult, but not impossible for an individual computer programmer with little or no money to vindicate her copyright against a major corporation. Resolution could take between several months and several years. If successful, she can enjoin the infringing activity and receive money damages.
Practically speaking, the unknown hacker should seek legal counsel who is familiar with litigating copyright law in the context of software source code. And, yes, it is possible for an individual to take on a major corporation, such as by enlisting the help of others (possibly even a friendly corporation) or, in the rare instance, by a law firm taking the case on a contingency fee basis. [For more discussion of this, see the answer to question 2 above.] Such a copyright case can last anywhere from several months (if settled during or shortly after discovery) to several years if the case goes to trial and appeal.
Copyright Infringement occurs when someone other than the copyright owner exercises one or more of the exclusive rights of the copyright owner. An unauthorized use of the copyrighted material exposes the infringer to criminal and/ or civil liability under U.S. copyright law. Further, the copyright holder in a civil case does not have to prove intent to infringe by the defendant, but only that the act of infringement occurred. The defendant corporation would likely defend the case vigorously by, among other things, asserting a variety of defenses including the affirmative defense of fair use.
Once a copyright holder proves copyright infringement, she can recover actual damages and lost profits if they can be adequately proven. Otherwise, if the copyrighted work was properly registered, the copyright owner can get attorney's fees and statutory damages, which can be as high as $150,000, without any requirement of actual proof of harm. Copyright holders can also seek an injunction to prevent the alleged infringement from continuing during or after the litigation.
Also, as a side note, it would be difficult for a case to rely entirely on individuals "with a conscience and access to the suspect source." For one reason, they are probably in violation of their employee confidentiality agreement by telling anyone about what they know to be in the suspect source code, so they may not want to come forward to testify. Consequently, it would be helpful to discover other evidence (documents, sworn testimony, etc.) supporting the allegations.
As for precedent, in the case LMP v. Universal Lighting, a law firm took a technology-related case for a couple of garage inventors on a contingency fee basis and won a $92 million judgment. Although it took several years and a couple appeals, the plaintiffs eventually had their rights vindicated.
Supremacy Clause and shrinkwrap "no review" terms.
Daniel, you write,
How does this square with shrinkwrap license clauses that demand no one publish reviews or benchmarks without permission? Both Microsoft and Oracle employ such clauses, for example. It would seem to me that this conflicts with the original (1823?) Supreme Court decision that established the "fair use" doctrine -- the Court declared that Congress might not pass a copyright law so stringent as to restrain freedom of speech nor freedom of the press... and benchmarking and publishing the results certainly is a legitimate exercise of the latter! And the subject would seem to me to be precisely a Supremacy Clause argument...59. There is a huge flaw with this core of these Supremacy Clause preemption arguments. The underlying rationales given for performing a separate Supremacy Clause preemption analysis are exactly the same arguments made for finding the license procedurally or substantively unconscionable under state contract law.
The rights given to individuals by the Constitution and Congress are mere default starting positions which can be freely transferred by contract. As long as a contract is validly formed, the Supremacy Clause will not undo the bargain struck by the parties.
The Supremacy Clause of the Constitution preempts any state law which "stands as an obstacle to the accomplishment and execution of the full purposes and objectives of Congress." Some argue that state contract law which enforces software license provisions such as prohibitions against publishing benchmarks or reviews circumvents the doctrine of fair use and the first amendment and, as such, should be preempted by the Supremacy Clause. Those who advance this argument believe that parties should not be allowed to use contracts to undo the congressional fair use balance struck between the right of copyright owners to control the use of their works and the Constitutional right of individuals to the freedom of speech. However, the accepted view is that individuals have the right to contract around the fair use balance struck by Congress. Therefore, copyright law and the Constitution supply mere default rules, which only apply in the absence of an agreement between the parties.
The Constitution also gives us the right to give up our rights (think Miranda warning, "You have the right to remain silent; If you choose to waive that right and talk, we can use what you say against you."). We can also exchange the rights we are given initially for other rights (think confidentiality agreements which say "I agree to restrict my right to tell people what you show me, if you also agree to restrict your right to tell people what I show you."). Validly entered contracts are the vehicle by which rights are exchanged. And although there are some differing points of view, the widely accepted theory is that the Supremacy Clause has no application to validly entered contracts. Therefore, as long as they are part of a validly entered into license agreement, the anti-publication of benchmarks or reviews provisions are completely legal and enforceable.
RELATION TO OPEN SOURCE LICENSING
Contrary to what I sense is your feeling, it is my view that the open source community should be encouraged by this result for the simple reason that several provisions in the most common public software licenses (the GNU General Public License and the Mozilla Public License) could also be deemed to limit the fair use rights of licensees. For instance, the GPL requires the licensee to license under the GPL any future work which includes part of the licensed work. This arguably prevents someone from making a fair use of GPL'd code (for example, by taking a small line of code and incorporating it into a million line program which is part of a doctoral thesis). However, by entering into the GPL, the licensee possibly waives her right to make any such fair use. If the Supremacy Clause was to preempt this provision, the intent and strength of the GPL would be seriously thwarted. Therefore, it is good for the free software community that the Supremacy Clause does not strike provisions of validly entered software licenses.
Further, there is another reason why the open source community may be benefited by the anti-publication of benchmarks or review provisions of closed-source licenses. Assume two software products compete in a market, one is closed source and licensed under terms which include the anti-publication provisions mentioned above while the other is licensed under a public software license, such as the GPL. The open source product will presumably be or become the subject of published benchmark reports and reviews, while the closed source product will not. Educated consumers may be less likely to purchase the closed source product because they have no available information regarding its performance or quality. Further, even if there are published benchmarks and reviews for the closed source software, educated consumers may recognize that those reports and reviews were only published with the consent of the closed source company. This fact will detract from the reliability and value of the report or review to the consumer. So at least in theory, the anti-publication provisions may actually hinder the closed source product's ability to compete with open source products in the marketplace.
I'm one of the lead developers on the Open Source project Jive. Many of our contributors work on the project as part of their job duties at their place of employment. In light of that, we've been considering a mandatory Contributor Agreement for all code that is submitted to the project (excluding one-liners).
We want the agreement to accomplish three things:
1. Stipulate that the code is being released to the project under the project's license (for our project this is the Apache License).
2. Ensure that the contributor has permission to release the intellectual property to the project, including any necessary permission from their employer.
3. Make sure that the contributor does not apply for patents for the code that they're submitting.
My question is:
1. Do you see legal value in this sort of agreement?
2. Do you know of any boilerplate agreements that exist?
3. Shouldn't more Open Source projects be worried about IP issues that a contributor agreement seeks to prevent?
Yes, there is legal value in this sort of agreement. Yes, there are "boilerplate" agreements available, but I strongly advise against relying on them entirely. Yes, the managers of open source projects should consider the intellectual property issues involved with their project and consider the appropriateness of a contributor agreement.
From a purely legal standpoint, such an agreement provides several benefits to open source projects. The potential for your project to incorporate submitted code that actually belongs to someone else (namely the contributor's employer) creates a risk for your project. Requiring contributors to confirm that they have permission to release the code to your project helps to reduce your exposure to third party intellectual property infringement claims. In addition to having the agreement for legal reasons, it could also be helpful to also post a detailed FAQ about why such an agreement is needed and who a contributor can contact if they (or their employer) have issues or questions.
It should please you to know that several members of the open source community, including the Free Software Foundation and Sun, already go about protecting their open source projects by requiring contributors to complete similar type agreements. However, one difference between what I've seen and what you propose is that such agreements do not forbid the contributor from applying for patents; rather they require the contributor to grant a license to any future patents she receives to the project as well.
As for "boilerplate" agreements, at the risk of sounding self serving, I encourage you to have a lawyer review any documents before using them for your project. The time and money you invest will ensure that the agreement complies with the specific laws of your jurisdiction while also addressing and satisfying the specific needs of your project.
How Can We be More Effective?
The open source community interaction with law and politics to date has been almost completely reactive. Typically some company or government institution has or is about to do something draconian before we are able to mobilize. Sometimes we get there in time, sometimes not. Examples are: DMCA, UCITA, and hundreds of software patents, Microsoft's embrace and extend campaign of the week, ... the list goes on.
What can we do as a community to be more effective in protecting ourselves. I'm someone who has joined the EFF, written letters to the copyright office, participated heavily on Openlaw, and written letters to my Congressmen. Many of us are involved in these ways, but somehow we've got to take it up a notch. What's the next step?
I strongly believe that the free software movement has been and continues to be incredibly successful in the only arena that matters, the market place.
I think you don't give yourself enough credit. The impact free software has had in such a short period of time is simply amazing, especially when one considers the economic disadvantage open source supporters have in relation to those who oppose them. Being reactive is not necessarily a bad thing; it's much better than being alienated, indifferent or complacent. But, since you asked, I make a few suggestions below, which may help the free software movement continue to progress at its already extremely productive rate.
My first suggestion is to recognize what has been accomplished. Often it is easy to focus on what has not been done or what has gone wrong, but every once in a while, it is necessary to appreciate the achievements of the past. Although you believe the open source movement lost certain legal battles (such as DMCA, UCITA, software patents, etc), what matters is the war in the marketplace. In my opinion, open source development has been galvanized, not thwarted, by these "losses." To support this conclusion, I simply point to the amount of press open source software has received to date and to the number of major corporations, including IBM, HP and Netscape, who have made severe commitments to the ideas behind the free software movement.
My second suggestion is for open source developers to keep writing good code. After all is said and done, people care about getting the best product they can at the cheapest price. The free software community has already proven to many people that it provides a competitive and sometimes superior alternative to proprietary software development. Although legal issues are important to the success of an open source project, they should always come second to the technical development of the code. It is my opinion that law does not lead the market, rather the market leads the law. Therefore, winning in the marketplace will lead to winning in the legal system, not vice versa.
My last suggestion is to encourage the open source community to take advantage of the marketplace of ideas. Although some individuals deserve a little more credit than others for the achievements of the free software movement, the key to the success of open source software development has been the involvement of vast numbers of individuals. To this end, I would encourage those in the free software movement to welcome varying points of view. Limiting the amount and kind of ideas which are presented and discussed will serve a great disservice to the movement. Only through (sometimes heated) debate will the most merit-worthy principles reveal themselves.
But again, I reiterate that it is my sincere opinion that the accomplishments of the open source movement to date can only be described as remarkable.
"Special Guest Comment"
by Richard M. Stallman
I'm glad that people are interested in asking about the GNU GPL, but while asking, please keep in mind that the GPL was not developed by the Open Source Movement, and really has no connection with it.
The Open Source Movement was founded in 1998 by people who disagreed with the Free Software Movement's idealistic goals. Many open source developers use the GNU GPL for pragmatic reasons--to make sure that their programs won't be "embraced and extended" into proprietary versions. Anyone is welcome to use the GPL, for whatever reason. But in order to understand the GPL, you need to think of it as a free software license, not as an open source license.
I wrote the GPL in the 1980s as part of the Free Software Movement. The goal of the Free Software Movement is to give computer users the freedom to share and change the software that they use. The GPL is designed specifically to achieve that goal--to make sure every user of a GPL-covered program has the freedom to share and change it.
Mr. Stallman is indeed correct. However, since the practical, as opposed to theoretical, legal differences between free software and open source are minimal in comparison to their collective differences with proprietary software development, my responses above use the terms interchangeably. By doing so, I do not intend to imply that all public software licenses are the same; just as I do not intend to imply that all proprietary software licenses are the same by also grouping them together in my answers. Lastly, Mr. Stallman's point that the GPL differs from other open source licenses reinforces my suggestion above that individuals should seek specific legal advice for their specific circumstances.