Open Source Your Project (With Jasig)


Published on

So you've got an interesting project that you think should be open source. But what does that mean exactly and how do you go about doing it the right way? In this session we'll answer those questions and cover areas like licensing, intellectual property management, governance, developer/community infrastructure, and try to put you on the right track for a successful open source project. We'll also talk about the Jasig incubation program and how Jasig can help you deal with all these concerns.

Full screencast from the conference available at:

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Open Source Your Project (With Jasig)

  1. 1. Open Source Your Project (With Jasig) John A. Lewis Chief Software Architect Unicon, Inc. Jasig 2010 Conference 9 March 2010 © Copyright Unicon, Inc., 2010. Some rights reserved. This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. To view a copy of this license, visit
  2. 2. Agenda <ul><li>What Is Open Source?
  3. 3. Open Source Licensing
  4. 4. Intellectual Property Management
  5. 5. Building Community
  6. 6. What Does Jasig Offer? </li></ul>
  7. 7. What Is Open Source?
  8. 8. What Is Open Source? <ul><li>Lots of Different Terms: </li><ul><li>Free Software
  9. 9. Open Source Software (OSS)
  10. 10. Free/Open Source Software (FOSS)
  11. 11. Free/Libre Open Source Software (FLOSS) </li></ul><li>They all mean essentially the same thing </li></ul>
  12. 12. Free Or Free? <ul><li>“Free” as if Freedom and Liberty
  13. 13. Think Free as in “Free Speech”
  14. 14. Not (necessarily) Free as in “Free Beer” </li></ul>
  15. 15. Major Organizations <ul><li>Free Software Foundation </li><ul><li>
  16. 16. Grew out of GNU community
  17. 17. Promoters of GNU Public License (GPL)
  18. 18. Approves Licenses as “Free Software” </li></ul><li>Open Source Initiative </li><ul><li>
  19. 19. Grew out of disagreements with GNU/FSF
  20. 20. Less dogmatic / more practical
  21. 21. Approves Licenses as “Open Source” </li></ul></ul>
  22. 22. Free Software Definition (FSF) Essential “Freedoms” of Free Software: <ul><li>0: Free to Run </li><ul><li>Anyone for any purpose </li></ul><li>1: Free to Study </li><ul><li>Access to see and modify source code </li></ul><li>2: Free to Redistribute </li><ul><li>Share binaries and source code </li></ul><li>3: Free to Improve </li><ul><li>Make it better for the whole community </li></ul></ul>
  23. 23. 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
  24. 24. Open Source Licensing
  25. 25. Copyright <ul><li>FOSS licenses based in Copyright law
  26. 26. Decisions used to focus on extremes: </li><ul><li>Complete enforcement (“all rights reserved”)
  27. 27. Contribute to public domain (“no rights reserved”)
  28. 28. Open Source is “some right reserved” </li></ul><li>Publisher of open source retains copyright
  29. 29. Copyright holder can do whatever they want </li><ul><li>Do not have to follow terms of their own license </li></ul><li>Only those who receive software under the license are bound by it </li></ul>
  30. 30. “Copyleft” <ul><li>Requiring software freedom for derivative works based on free software
  31. 31. There is no requirement for copyleft in “Free Software” or “Open Source” – Copyleft is a separate concern
  32. 32. Two key dimensions: </li><ul><li>when the copyleft requirements are triggered (usually redistribution)
  33. 33. How far the copyleft requirements reach (e.g. source files, compiled together, dynamic linking) </li></ul></ul>
  34. 34. GPL Compatibility <ul><li>GPL is most important FOSS license </li><ul><li>First to embody Free Software and Copyleft
  35. 35. 70% of FOSS projects use the GPL </li></ul><li>Key copyleft provision: Combined works that include GPL must be relicensed under GPL
  36. 36. If other software cannot be licensed under the GPL then they are incompatible and cannot be combined </li></ul>
  37. 37. GNU Public License (GPL) <ul><li>Best starting point – clearly FOSS leader and obviously GPL compatible
  38. 38. Strong copyleft that defines “derivative work” as anything that runs in the scope of the process (including dynamic linking)
  39. 39. Lesser GNU Public License (LGPL) has weaker copyleft that applies only to source code compiled together into binary (e.g. libraries)
  40. 40. Affero GNU Public License (AGPL) has extended definition to trigger copyleft on network usage (e.g. web sites) </li></ul>
  41. 41. Apache License <ul><li>Comprehensive open source license – covers many of the same areas as the GPL
  42. 42. No copyleft provisions (does require preservation of copyrights and disclaimers)
  43. 43. Compatible with GPLv3, but not w/ GPLv2
  44. 44. 2nd most popular FOSS license
  45. 45. Used by projects that want comprehensive license without copyleft </li></ul>
  46. 46. New BSD License <ul><li>Very simple, permissive, non-copyleft (only 220 words long)
  47. 47. Basic redistribution requirements </li><ul><li>Must preserve the copyright and disclaimer
  48. 48. Forbid endorsement use of copyright holder name </li></ul><li>Similar variants: Simplified BSD License, MIT License
  49. 49. Easy to read and understand
  50. 50. Doesn't address patents or trademarks
  51. 51. Lacks language legal advisers prefer </li></ul>
  52. 52. Mozilla Public License (MPL) <ul><li>Compromise between GPL and BSD licenses
  53. 53. Weaker copyleft than LGPL (applies to individual source code files only)
  54. 54. Incompatible with the GPL (due to minor but complex restrictions)
  55. 55. Popular derivatives: </li><ul><li>Common Development and Distribution License (CDDL) : used by Sun, minor changes only
  56. 56. Common Public Attribution License (CPAL) : requires “attribution” of original developer – usually large logo / splash screen (“Badgeware”) </li></ul></ul>
  57. 57. Recommendation: Licensing <ul><li>Use an existing, major license </li><ul><li>Choose the one that best fits your needs
  58. 58. Avoid “License Proliferation” </li></ul><li>Unless you have a really compelling reason to go another way, choose one of these: </li><ul><li>Apache: no Copyleft
  59. 59. LGPL: weak Copyleft
  60. 60. GPL: strong Copyleft
  61. 61. AGPL: strong Copyleft that covers SaaS </li></ul></ul>
  62. 62. Intellectual Property Management
  63. 63. Managing Contributors <ul><li>Important to understand the copyright ownership of all source code
  64. 64. Project with multiple contributing people/organizations may have multiple copyright holders
  65. 65. Cannot tell by looking at the license
  66. 66. Choice for handling copyrights (Intellectual Property Policy) is separate from License </li></ul>
  67. 67. Copyright Assignment <ul><li>Maintain complete central control over IP
  68. 68. Require contributors to assign copyrights to a central organization </li><ul><li>Could be legal entity created for the explicit purpose of holding project IP
  69. 69. Can be joint assignment or sole assignment w/ broad grant-back copyright license
  70. 70. Include a patent license to avoid interference with contributed code
  71. 71. May seem extreme / can discourage contribution </li></ul><li>Used by Sun for its open source projects </li></ul>
  72. 72. Broad Copyright License <ul><li>Require contributors to give broad copyright license to central entity </li><ul><li>Include the right to sub-license and redistribute – broader than project license
  73. 73. Also has patent license </li></ul><li>Project can redistribute the source code under its FOSS license without any issues
  74. 74. Nice compromise, less extreme
  75. 75. Used by Apache Software Foundation for all of its projects </li></ul>
  76. 76. Use Project FOSS License <ul><li>Simplest policy is to accept contributions under the project license
  77. 77. Largely the default – used on many projects </li><ul><li>Used by the Linux kernel project </li></ul><li>Major potential problem: Cannot distribute under a different license without explicit permission from every copyright holder
  78. 78. Two year effort by Mozilla project to relicense code from 450 contributors </li></ul>
  79. 79. Reusable Contributor Agreements <ul><li>Contributors Retain Copyright </li><ul><li>Grant broad license to the project
  80. 80. Apache Contributor License Agreement </li></ul><li>Contributors Assign Copyright </li><ul><li>Grant broad reciprocal license back to contributor
  81. 81. FSF-Europe: Fiduciary License Agreement (FLA) </li></ul><li>Joint Copyright </li><ul><li>Sun Contributor Agreement </li></ul></ul>
  82. 82. Recommendation: Contributions <ul><li>Establish intellectual property policy for handling outside contributions
  83. 83. Include Contributor License Agreement </li><ul><li>Preserve right to relicense </li></ul><li>Use an existing CLA </li><ul><li>Apache CLA for broad licensing
  84. 84. FSFE FLA for copyright assignment
  85. 85. Sun CLA for joint copyright assignment </li></ul></ul>
  86. 86. Recommendation: Implementation <ul><li>Clearly list license on web page for downloads
  87. 87. In every binary and source distribution: </li><ul><li>“ readme” file explains licensing of distribution
  88. 88. copy of all relevant license files
  89. 89. copy of all required notices for original works and other works being redistributed </li></ul><li>Comment header with copyright, license, and/or disclaimer in every source code file (licenses usually provide templates)
  90. 90. Ensure headers are maintained and audited
  91. 91. Document contributor policy on website and provide the CLA for download </li></ul>
  92. 92. Building Community
  93. 93. Developer Collaboration <ul><li>Source Control
  94. 94. Issue Tracking
  95. 95. Wiki
  96. 96. Continuous Integration
  97. 97. Code Review </li></ul>
  98. 98. Community Collaboration <ul><li>Mailing Lists / Forums
  99. 99. Wikis / Blogs
  100. 100. IRC Channel
  101. 101. Conference Calls
  102. 102. Project Coordination
  103. 103. Meetups / User Groups
  104. 104. Conference </li></ul>
  105. 105. Promotion <ul><li>Get listed! </li><ul><li>Freshmeat, Ohloh, Wikipedia, etc. </li></ul><li>Get noticed! </li><ul><li>Related mailing lists, bloggers & articles, related conferences, community webinars </li></ul><li>Get Social! </li><ul><li>Twitter account, Facebook fan page </li></ul></ul>
  106. 106. Drive Adoption <ul><li>Good Website
  107. 107. Screenshots
  108. 108. Demo Video
  109. 109. Demo Site
  110. 110. Easy Download
  111. 111. Easy Install
  112. 112. Easy Pilot </li></ul><ul><li>Good Documentation
  113. 113. Responsive Forums
  114. 114. Case Studies
  115. 115. Regular News
  116. 116. Press Releases
  117. 117. Sustainability Plan </li></ul>
  118. 118. What Does Jasig Offer?
  119. 119. Organization <ul><li>Established 501(c)(3) nonprofit corporation
  120. 120. Duly elected Board Of Directors
  121. 121. Full-time Executive Director
  122. 122. Project Steering Committees
  123. 123. Large Existing Institutional Membership
  124. 124. Solid Financial Performance
  125. 125. General Administration & Logistics
  126. 126. A Cool Logo! </li></ul>
  127. 127. Licensing & IP Management <ul><li>Full implementation of Apache Model
  128. 128. License under Apache License, version 2.0
  129. 129. Specific Guidelines Implementing Licensing
  130. 130. Jasig Contributor Agreements
  131. 131. Logistics for Records Management </li></ul>
  132. 132. Incubation Process <ul><li>Incubation Working Group
  133. 133. Full Incubation Process Flow
  134. 134. Facilitate Integration of Project </li><ul><li>Use of Jasig Infrastructure
  135. 135. Community & Project Governance
  136. 136. Licensing & IP Management </li></ul><li>Mentoring of initial Steering Committee </li></ul>
  137. 137. Infrastructure <ul><li>Drupal for Web Site & Blogs
  138. 138. Subversion for Source Control
  139. 139. JIRA for Issue Tracking
  140. 140. Confluence for Wiki
  141. 141. Lyris for Mailing Lists
  142. 142. Moving to JIRA Studio (sometime soon) </li></ul>
  143. 143. Existing Community <ul><li>Board, Committees, Working Groups
  144. 144. Annual Conference and “Unconference”
  145. 145. Network Effect, Cross Pollination
  146. 146. Related Projects
  147. 147. Extended Relationship to other Communities (Kuali, Apache, Sakai, Fluid, Duraspace, etc.) </li></ul>
  148. 148. Learn More About Jasig <ul><li>
  149. 149.
  150. 150.
  151. 151. </li></ul>
  152. 152. Questions & Answers John A. Lewis Chief Software Architect Unicon, Inc. [email_address]