Jump to content
How to Get a Grasp on Bare Essentials of Legal Issues for Developers (OSCON presentation)
Submitted by mayhem
Posted Jul 22 2010 03:54 PM
(Note: This answer is actually covering the OSCON session with a similar title)
In the afternoon I attended Bradley Kuhn and Karen Sandler's Bare Essentials of Legal Issues for Developers session. Over the last ten years I've been attending various sessions that covered legal topics here at OSCON and at ETech, I've managed to get a rudimentary grasp of copyright law, patents and trademark, concepts which every open source hacker should grasp. This excellent session was a great crash course for open source developers who may not really have thought about the legal implications of their work.
Brad and Karen started off with the most relevant topic to open source hackers: Copyright. Brad defined copyright as protecting and giving a limited monopoly to works of authorship that have been fixed in a tangible medium. This means that anytime you put pen to paper or create a document/file/image/photo you "fix" a work into a tangible medium (paper or bits on a drive). Interestingly enough, the way copyright works in the US, anytime you create any work of authorship, its automatically copyrighted. Every scribble on a napkin is automatically covered by US copyrights laws! This applies to all forms of authorship, wether you create software, photos or fine art. Source code, object code and executables are all copyrightable.
Copyright owners can control copying, modifying and distributing of their content. Often times permission for these actions is granted via a license like the GPL. Many open source licenses require an underlying copyright, meaning that they depend on the copyright to exist and be enforceable. Licenses will give details on what actions can and cannot be performed with the given work. Should the user of the content violate any portion of the license, the license becomes invalid and standard copyright comes into play. Now that the user does not have a valid license, the user is in copyright violation and the author has the right to sue the user for copyright violation. Licenses give the public the right to most activities and some licenses add a few reasonable restrictions.
Brad continued on to discuss the two types of FLOSS licenses: Copyleft and permissive. Wikipedia defines copyleft as: "Copyleft is a play on the word copyright to describe the practice of using copyright law to offer the right to distribute copies and modified versions of a work and requiring that the same rights be preserved in modified versions of the work." Permissive licenses like the BSD license do not require that modified works carry the same rights. Brad also pointed out that there are licenses like the LGPL that fall in between Copyleft and permissive licenses.
But the FLOSS world has a serious problem in license proliferation. Today, too many licenses exist that are in one way or another a custom tweak for a specific situation of open sourcing a piece of software. Many of these licenses are similar to FLOSS licenses, but they have clauses that may cause them to no longer qualify as FLOSS licenses. Also, many of these licenses may not be compatible with other licenses, which makes it difficult to share code between projects with conflicting licenses. Brad encouraged people to not write any more licenses, but instead to take a long look at the list of available licenses at the FSF or the OSI. The final point on licenses that Brad offered pertained to choosing a FLOSS license: If you're part of a community that uses one license and your code needs to play well in that community, its probably wise to choose the license favored by that community to avoid compatibility issues.
Next, Karen and Brad talked about patents and Karen started out telling us that patents apply to underlying ideas, as opposed to copyright which applies to creative expression. If you write code from scratch you are clear of any copyright issues, but you may still violate patents in your code. The idea behind a patent is that in exchange for making your idea public, the Patent Office will grant you a limited monopoly on your idea. Anyone who wishes to use your idea in their own product/service must then get permission from you before they use the idea. In general, patents focus on invention, not on expression.
Fortunately, most open source developers do not need to worry about patents and most open source projects do not proceed with filing patents in their open source work. Karen suggested that open source developers should not be paralyzed about infringing on patents. There are so many broad software patents out there, that you're almost surely infringing on some patents. For the most part it doesn't matter, go forth and write code! Should you receive a Cease and Desist letter from a lawyer informing you that a patent owner thinks you've violated their patent, you need to start paying attention to patents. In this case you must find a lawyer to help you address the letter -- the Software Freedom Law Center is there exactly for this purpose.
Karen went on to discuss trademarks and explain how trademarks pertain to brand management, identity and marketing. Trademarks protect words, names and logos and can apply to words and pictures; trademarks focus on recognition of a brand. Trademarks, unlike patents and copyright, are earned through use, meaning that the person or company using a brand builds the right to the trademark by using the brand. One strong example for establishing use of a trademark is registering a domain that is clearly associated with the trademark. Also, unlike copyright or patents, trademarks have no end -- they are good as long as you continue to use your trademark.
Karen also recommended that open source projects should choose clear and distinctive names. Naming a project Chair (which is a common object) may make it harder for you to claim a trademark for your project. Projects should also be careful who holds the trademark for a project -- it would be most desirable for an organization to hold the trademark, as opposed to an individual contributor on a project. Finally, Karen recommended that projects create a policy with respect to using the trademark. When can users use the trademarked name of a project? What conditions have to be met to use the trademark? Your policy should spell out if, when and how a trademark can be used.
To close the topic of trademarks, Karen talked about the value of trademarks and how overly strong enforcement of your trademark can actually hurt you. The Pigeon instant messenger application used to be called GAIM, for Gnome AOL Instant Messenger. AOL took offense and forced GAIM to change its name since it clearly conflicted with their AIM trademark. But in the end AOL lost out since most Pigeon users don't associate sending instant messages on Pigeon with AIM, now that the AIM word has been removed from the name of the project.
Finally, Karen and Brad briefly touched on contracts and mentioned that FLOSS license are usually not contracts. Developers mostly come into contact with contracts when signing employment contracts. Brad pointed out that if you don't like a clause in your contract you should bring up the issue with your potential future employer since a lot of employment contracts are negotiable. Finally, he suggested that developers should avoid signing non-disclosure agreements and non-compete contracts since they could bind your hands to freely develop open source software.
As a closing thought Brad mentioned wills, trusts and estates and how developers should consider their open source work when creating a will or a trust. He pointed out that most spouses of open source developers may not be versed in the nuances of open source licenses and that they should not have to think about that in the case of the loss of a loved one. Developers should assign another developer as a proxy to handle open source issues in case they pass away.
Even though this session ended on a somber topic, I personally have to admit that I have never considered my open source dealings in the context of a will. I certainly would not want to have my spouse or my mother have to deal with my open source issues should I pass away untimely. I'll start thinking about who should handle my open source affairs after I pass away. Thanks for that sober thought and and overall excellent presentation Karen and Brad!