Open Source Licensing in Apereo and Beyond

Many of us work in open source projects without really understanding all the details about open source licensing and how intellectual property should be managed. In this session we will talk what it means to be open source, what "copyleft" means, how a few of the major open source licenses work, how to handle copyright ownership, and what contributor agreements do. We'll also talk specifically about how Licensing and Intellectual Property are managed in the Apereo Foundation. #apereo14

Transcript

1. Open Source Licensing in Apereo and Beyond John A. Lewis Chief Software Architect Unicon Inc.
2. Abstract: Many of us work in open source projects without really understanding all the details about open source licensing and how intellectual property should be managed. In this session we will talk what it means to be open source, what "copyleft" means, how a few of the major open source licenses work, how to handle copyright ownership, and what contributor agreements do. We'll also talk specifically about how Licensing and Intellectual Property are managed in the Apereo Foundation.
3. Unicon + me Reputation based Open source Higher education IT consulting services Not a product vendor Trusted partner Customized solutions Project management Community engagement Project and team support Technical Support Active community members Engineering / Development Deployment / Hosting John A. Lewis • Active in Apereo projects and communities for over 8 years • Board member for 5+ years • Chair of Licensing & IP Committee • Software Architect / EdTech Zealot obsessed w Agile & Open
4. I Am Not A Lawyer Nothing in this presentation is legal advice...
5. Open Source
6. What Is Open Source Software? “Software for which the original source code is made freely available and may be modified and redistributed by anyone for any purpose.”
7. Other Terms for Open Source Several other terms that all essentially mean the same thing: • Free Software (beware confusion) • Open Source Software (OSS) • Free/Open Source Software (FOSS) • Free/Libre Open Source Software (FLOSS)
8. What Does “Free” Mean? • “Free” as in Freedom and Liberty • Think Free as in “Free Speech” • Not (necessarily) Free as in “Free Beer”
9. What Does “Free” Mean? • Maybe Free as in “Free Puppy”... • There might be some care and feeding involved...
10. Open Source Licensing aka “Outbound Licensing”
11. Major Organizations • Free Software Foundation − www.fsf.org − Grew out of GNU community − Promoters of GNU Public License (GPL) − Approves Licenses as “Free Software” • Open Source Initiative − www.opensource.org − Grew out of disagreements with GNU/FSF − Less dogmatic / more practical − Approves Licenses as “Open Source”
12. Free Software Definition (FSF) Essential “Freedoms” of Free Software: 0: Free to Run − Anyone for any purpose 1: Free to Study − Access to see and modify source code 2: Free to Redistribute − Share binaries and source code 3: Free to Improve − Make it better for the whole community
13. Open Source Definition (OSI) 1. Free Redistribution 2. Source Code 3. Derived Works 4. Integrity of The Author's Source Code 5. No Discrimination Against Persons or Groups 6. No Discrimination Against Fields of Endeavor 7. Distribution of License 8. License Must Not Be Specific to a Product 9. License Must Not Restrict Other Software 10. License Must Be Technology-Neutral
14. Copyright • All FOSS licenses based on Copyright • Decisions used to be extreme: − Complete enforcement = “All Rights Reserved” − Put into public domain = “No Rights Reserved” − Open Source = “Some Right Reserved” • Publisher of open source retains Copyright • Copyright holder can do whatever they want − Do not have to follow terms of their own license • Only those who receive software under the license are bound by it
15. “Copyleft” • Requiring software freedom for derivative works based on free software • There is no requirement for copyleft in “Free Software” or “Open Source” – Copyleft is a separate concern • Two key dimensions: ◦ when the copyleft requirements are triggered (usually redistribution) ◦ How far the copyleft requirements reach (e.g. source files, compiled, dynamic linking)
16. GNU Public License (GPL) • Strong copyleft license that defines “derivative work” as anything that runs in the scope of the process (including dynamic linking) • Key Variants: ◦ Lesser GPL (LGPL) has weaker copyleft that applies only to source code compiled together into binary (e. g. libraries) ◦ Affero GPL (AGPL) has stronger copyleft that includes network usage (e.g. web sites) • Two major version: GPLv2, GPLv3
17. GPL Compatibility Concerns • GPL arguably the most important FOSS license ◦ First to embody Free Software and Copyleft ◦ 70% of FOSS projects use the GPL • Key copyleft provision: Combined works that include GPL must be relicensed under GPL • If other software cannot be licensed under the GPL then they are incompatible and cannot be combined
18. Apache License • Comprehensive open source license – covers many of the same areas as the GPL • No copyleft provisions (does require preservation of copyrights and disclaimers) • Compatible with GPLv3, but not w/ GPLv2 • 2nd most popular FOSS license • Used by projects that want comprehensive license without copyleft
19. New BSD License • Very simple, permissive, non-copyleft (only 220 words long) • Basic redistribution requirements • Must preserve the copyright and disclaimer • Forbid endorsement use of copyright holder name • Similar variants: Simplified BSD License, MIT License • Easy to read and understand • Doesn't address patents or trademarks • Lacks language legal advisers prefer
20. Mozilla Public License (MPL) • Compromise between GPL and BSD licenses • Weaker copyleft than LGPL (applies to individual source code files only) • Incompatible with the GPL (due to minor but complex restrictions) • Popular derivatives: ◦ Common Development and Distribution License (CDDL): used by SunOracle, minor changes only ◦ Common Public Attribution License (CPAL): requires “attribution” of original developer, usually large logo (“Badgeware”)
21. Open Source Contributions aka “Inbound Licensing”
22. Managing Contributor Copyrights • Important to understand the copyright ownership of all source code • Project with multiple contributing people/organizations may have multiple copyright holders • Cannot tell by looking at the license • Choice for handling copyrights (Intellectual Property Policy) is separate from License
23. Copyright Assignment • Maintain complete central control over IP • Require contributors to assign copyrights to a central organization ◦ Could be legal entity created for the explicit purpose of holding project IP ◦ Can be joint assignment or sole assignment w/ broad grant-back copyright license ◦ Include a patent license to avoid interference with contributed code ◦ May seem extreme / can discourage contribution • Used by SunOracle for its FOSS projects
24. Broad Copyright License • Require contributors to give broad copyright license to central entity ◦ Include the right to sub-license and redistribute – broader than project license ◦ Can also include patent license • Project can redistribute the source code under its FOSS license without any issues • Nice compromise, less extreme • Used by Apache Software Foundation for all of its projects
25. Use Project FOSS License • Simplest policy is to accept contributions under the project license • Largely the default – used on many projects ◦ Used by the Linux kernel project • Major potential problem: Cannot distribute under a different license without explicit permission from every copyright holder • Two year effort by Mozilla project to relicense code from 450 contributors
26. Reusable Contributor Agreements • Contributors Retain Copyright ◦ Grant broad license to the project ◦ Apache Contributor License Agreement apache.org/licenses • Contributors Assign Copyright ◦ Grant broad reciprocal license back to contributor ◦ FSF-Europe: Fiduciary License Agreement (FLA) fsfe.org/projects/ftf/fla.en.html • Joint Copyright ◦ Oracle Contributor Agreement oracle.com/technetwork/oca-405177.pdf
27. Proper Implementation • Clearly list license on web page for downloads • In every binary and source distribution: ◦ “readme” file explains licensing of distribution ◦ copy of all relevant license files ◦ copy of all required notices for original works and other works being redistributed • Comment header with licensing info in every source file (some licenses provide template) • Ensure headers are maintained and audited • Document contributor policy on website and provide the CLA for download
28. Apereo Licensing and Intellectual Property Policy apereo.org/licensing
29. Outbound Licensing • Preferred outbound license: ◦ Apache License v2 • Alternate outbound license: ◦ Educational Community License (ECL) v2 ◦ Apache, but “modified to change the scope of the patent grant in section 3 to be specific to the needs of the education communities using this license” • Open to other outbound licensing, but needs board approval
30. Inbound Licensing Apereo Contributor License Agreements: • ICLA - Individual CLA • CCLA - Corporate CLA • SGLA - Software Grant LA All modeled after Apache Foundation CLAs
31. Third-Party Content If included in source code distribution or any binary distribtion: • Must be clearly distinguished • Must be compatibly licensed ◦ See Third-Party License Guidelines • Most be completely document (“Notices”)
32. Third-Party License Guidelines • Category A - Good to Go ◦ No concerns, but comply with license ◦ Examples: Apache, BSD, MIT, CC • Category B - Proceed with Caution ◦ Use in unmodified form only, and comply w license ◦ Example: MPL • Category X - You have a Problem ◦ Major concerns, unable to license properly ◦ Example: GPL, LGPL, AGL ◦ “FOSS Exceptions” move X to B ◦ Special considerations for LGPL in binary distribution only
33. Media Licensing • Projects may produce non-software materials that also need to be properly licensed ◦ Documentation, media, data sets, etc. • May be able to use open source license anyway (e.g. Apache for documentation) • May consider alternative license models such as Creative Commons • We still have work to do in this area
34. Trademarks and Servicemarks • Foundation is the legal owner of all marks ◦ Name and logo for the Foundation itself ◦ For constituent communities, products, projects • Foundation oversees use of all marks ◦ Will take appropriate action names or logos are used inappropriately • We still have work to do in this area
35. Project Responsibilities 1. All Contributors complete License Agreements 2. License properly included with the project 3. Notices properly maintained for the project 4. Source files carry a proper header 5. Third-Party Content handled properly 6. Trademarks / Servicemarks identified, researched, and registered
36. John A. Lewis jlewis@unicon.net