A software developer's simple view of the importance of licensing open source software, and considerations when using or contributing to open source software.
(I am not a lawyer) ! - Fine print Disclaimer: The views expressed in this presentation are solely my own and do not represent the views of any present or former employer, or any person or organizations referenced or cited within. 2 Prelude: “Stating the obvious”
change open source software and plan to sell or distribute • You contribute to open source projects • You publish code to benefit others ! ! Chances are that we developers fit into at least one of these categories
The copyright holder retains all rights (basically forever**) - Includes proprietary and open source • There are other kinds of protection - Trademark, unfair competition laws - Trade secret or contract law • You can use only if you have a license - And then only in ways that are approved by the license 5 * Actually, all artistic and literary works. The US joined the Berne Convention in 1988. ** Between 75 and 120 years in the US, depending. For software, this is basically “forever.” See http://copyright.cornell.edu/resources/publicdomain.cfm
license that grants you rights normally held by copyrighter - to see the source code - to copy the work and distribute copies - to modify the work and distribute derivative works - to use it without paying a royalty or fee to the publisher or copyright holder • Some licenses may restrict - when you must provide the source code for the work - whether and how you are to publish the source code for any derivative work • Restrictions really maintain rights of the software 7
definition - Evolving legal norms based in community consensus, embodied in development and distribution practices - Influential organizations: FSF, Debian, OSI, Fedora, ASF • 100s of licenses customarily considered FLOSS - Newer projects standardizing around a small set of popular licenses 8
- Technical contexts not considered by courts - Territoriality not usually important - Don’t use the IP/contract legal regime to understand these licenses • Under copyright law? - Jacobsen v. Katzer, 535 F.3d 1373, 1381-2 (Fed. Cir. 2008) • established that FLOSS licenses are enforceable • removal or altering of copyright statements violate the Digital Millennium Copyright Act (DMCA) • More like customary law? - Legal understanding requires understanding culture and customary practices - Analogous to Lex mercatoria (medieval merchant private common law that filled in gaps of local laws)? 9 See http://www.oscon.com/oscon2009/public/schedule/detail/8460
Requires same rights to be preserved in derivative works - Limits freedom to distribute derivative work under more restrictive terms • Usually some source code disclosure requirement - Typically, that source code, at least, must be under the same license as upstream • Strong vs weak - Extent to which copyleft provisions imposed • Full vs partial - Which parts of work are covered under copyleft • Share-alike - All copyleft licenses are share-alike (not vice versa) 11
packaging - The “whole work” • GPLv2 by far the most widely-used FLOSS license, for established as well as new projects - Other examples: GPLv3, AGPL, Sleepycat License • Policy goal: Preserve free software commons, even as software gets improved downstream • Circumvention should be technically cumbersome - AGPL closes perceived “service provider loophole” 12
• Copyleft scope (including source code requirement) limited to something less than GPL “whole work” • Popular examples: LGPL, MPL and EPL families - LGPLv2.x second most popular FLOSS license • Can distribute proprietary executables • Wide gap between LGPL text and liberal customary interpretation 13
reaction against strong copyleft - maximize downstream adoption - protect upstream developers from legal/reputational risk • Popular examples: BSD (2- and 3-clause), MIT/X11, and Apache families • Derivative works licensable under more restrictive terms (such as proprietary or GPL if compatible) • Notice requirements, but no source code requirement - But often strong social expectation to contribute some improvements upstream 14
licenses within the same program • Copyleft licenses often are not compatible - GPLv2 and GPLv3 • Copyleft and permissive can be compatible - GPLv3 and ASL 15 License compatibility
is a misnomer - Can’t actually place something into it - After copyrights expire, the works they protect fall in public domain - Includes (in US) US Government works, names, titles, etc. • Not universally defined or accepted - In US, might be treated legally as “copyright abandonment” - Different countries have different lengths of copyright - Failure to renew is not usually a problem in software • Gets complicated • Pragmatic approach: it’s a really broad license in disguise - Lots of legacy code and pieces of FLOSS libraries with PDD - Probably little risk of using software with appropriately-worded PDD • An alternative … 16
very permissive license in jurisdictions that don’t allow abandoning copyrights • A formal license “better” than public domain disclosure ! http://creativecommons.org/publicdomain/zero/1.0/legalcode 17
not you can use it - Early software culture was share everything - Post-Berne means it is copyrighted - When in doubt, ask • Request the library add a license - Add a “Please add a license” issue - Often this starts a useful community discussion - May not end up with license acceptable to you 19
sites - can be helpful - but “plain English” often masks important legal details • Read and understand the actual license • Consider how license will affect - the license of other libraries you’re using - your code’s license - distributing your code 20
library with a better license • If none, can your requirements be adjusted? • If not, might the FLOSS project relicense? • If not, you might be out of luck 22
Werner - http://blog.makk.es/2012/12/are-githubbers-taking-open-source.html • Is this laziness? Ignorance? Pushback? 24 Licensing is (considered) hard https://twitter.com/monkchips/status/247584170967175169
modifications? Allow use in proprietary products? Build a community & encourage contributions? Concerned about patents? Incorporate or use other licensed works? License compatibility for downstream users? Where will it be hosted? Sponsored by a corporation? 27 ?
categorize - can be helpful - but “plain English” often masks important legal details • Watch out for political or business agendas - favor some types of licenses over others - alternative definitions of accepted concepts ! Attempts to simplify can introduce errors… 28
comply with the license you pick • Provide guidance on 3rd party dependencies - Which other licenses (if any) are acceptable to project - Do not use non-FOSS licensed code/libraries • Contributor License Agreement (CLA) - Typically ensures contributors assign copyrights to owner - Grants project at least the outbound rights - ASL2.0 has an inbound clause making CLAs superfluous - Do they do more harm than good? Richard Fontana - http://www.oscon.com/oscon2011/public/schedule/detail/19242 35
use • Open Source Isn’t Free • Supporting your open source communities isn’t charity, it’s good business ! ! http://www.tomitribe.com/blog/2013/11/feed-the-fish/ 38
http://www.oss-watch.ac.uk/resources/briefings - Summaries of concepts, terms, licenses • http://www.tldrlegal.com/compare - Browse and compare/combine licenses • http://vschart.com - Wiki comparison site; lots of license comparisons • http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses • http://osrc.blackducksoftware.com/data/licenses/ - Rankings of licenses used in popular FOSS projects 41