Introduction To Open Source Licenses
25 likes7,332 views
This document provides an overview of free and open source software licenses, detailing their four fundamental freedoms, advantages like better quality and lower costs, and challenges such as intellectual property concerns. It explains different types of licenses (permissive, weakly protective, and strongly protective) and stresses the importance of GPL compatibility for businesses using open source software. The final recommendation is to consult a lawyer and carefully select components that align with business needs while considering the implications of open source licensing.
More Related Content
Similar to Introduction To Open Source Licenses (20)
Introduction To Open Source Licenses
- 1. Introduction to Free Open Source Software Licenses Harley D. Pascua @leypascua http://ph.linkedin.com/in/leypascua
- 2. Disclaimer All information in this presentation are from my own research and understanding of open source license mechanics and technicalities. The Open Source Initiative and Free Software Foundation have nothing to do with this presentation. I am not an open source or free software expert. Just to be sure, hire a lawyer*.
- 3. Free, Open Source What is Software?
- 4. Free Software is like Free Beer X
- 5. It is nothing close to a freebie.
- 6. Free software has a license that ensures certain There are four freedoms in free software. freedoms *
- 7. Freedom to Run the program for any purpose
- 8. Freedom to Study how the program works, and adapt it to your needs
- 9. Freedom to Redistribute copies so you can help your peers
- 10. Freedom to Write and release improvements So the community benefits
- 11. Free, Open Source Software Promises Better Quality Software Higher Reliability Output Greater flexibility Lower Costs The end to predatory vendor lock-in.
- 12. What’s stopping Open Source? ?
- 13. You can’t use open source It may compromise intellectual property
- 14. You can’t use open source It lacks integration with existing infrastructure.
- 15. You can’t use open source It lacks certification, there are no warranties.
- 16. You can’t use open source You don’t have the culture to govern it.
- 17. You can’t use open source You love proprietary software so much that you need expensive training to learn it.
- 18. There are supporting factors that encourage Open Source adaptation.
- 19. You have modular software components You want to leverage expert peer reviews You want readily assessable and available code You can test and experiment with very low cost. You have reduced risk of lock-in Consider Open Source When you have modular software components
- 20. You have modular software components You want to leverage expert peer reviews You want readily assessable and available code You can test and experiment with very low cost. You have reduced risk of lock-in Consider Open Source When you want to leverage expert peer reviews
- 21. You have modular software components You want to leverage expert peer reviews You want readily assessable and available code You can test and experiment with very low cost. You have reduced risk of lock-in Consider Open Source When you want code that is readily assessable and available.
- 22. You have modular software components You want to leverage expert peer reviews You want readily assessable and available code You can test and experiment with very low cost. You have reduced risk of lock-in Consider Open Source If you want to test and experiment with very low cost.
- 23. Consider Open Source And use it to reduce the risk of vendor lock-in.
- 24. Make the move to open source. T he big guys are playing.
- 26. The light is GREEN for open source. Save money and provide stability. No forced upgrades. Have rights to the code. Reach a skilled community of developers.
- 27. The light is GREEN for open source. Save money and provide stability. No forced upgrades. Have rights to the code. Reach a skilled community of developers.
- 28. 80% of all commercial software will contain open source code. By 2010
- 29. Open source is defined by ten sections. Read them carefully.
- 30. Free Distribution. Free software must be distributed freely. 1
- 31. Free Source Code. Source code must be readily available. 2
- 32. Derived Works. Allow modifications and combined works to be distributed. 3
- 33. Integrity of Code. “ Unofficial" changes can be made available but readily distinguished from the base source 4
- 34. All People Have Rights. Diverse people and groups should have equal rights to the free software. 5
- 35. Rights for All Endeavors. Free software shall not restrict its use for any specific industry or effort. 6
- 36. Distribution of License. The rights attached to the program must apply to all to whom the program is redistributed 7
- 37. Not Specific to a Product. The license must not be restricted to a specific product distribution. 8
- 38. Must Not Restrict Other Software. The license must not insist that all software distributed with an open source software must be open source. 9
- 39. License Must Be Technology Neutral. No provision of the license may be predicated on any individual technology or style of interface. 10
- 40. You can distribute software in three ways. Make copies on physical media, send files through the wire or open it for subscription.
- 41. Derived works. Know what it means. Existing work is modified. Combined works contain a modified or unmodified version of existing work. Works are linked or compiled. Static Linking Dynamic Linking Modifying, combining and linking* to existing code into a new body of work is a derived work. *Be safe. Treat static and dynamic linking the same way.
- 42. Open Source licenses offer different levels of freedom. Permissive, Weakly Protective and Strongly Protective*
- 43. Permissive Licenses *a.k.a “Give Me Credit” *Derivatives can re-license *Give credit to original authors You can use, modify and redistribute the code in your product but give credit back to the original authors.
- 44. Weakly Protective Licenses *a.k.a. “Give Me Fixes” *Differentiates between Source and Binary *Allows for Commercial Product Development *Tends towards libraries or platforms Mostly File or Derivative based conditions
- 45. Strongly Protective Licenses *a.k.a. “Give Me Everything” *All direct development is contributed back *Contributors assured code remains open source *Copyright holder retains much control *Limits commercial adoption Derivative works remain under original license.
- 46. You can’t just mix and match software licenses They have to be compatible.
- 47. License Compatibility A license p is compatible with a license q (or is q-compatible ) if and only if: A work licensed under p can be distributed under the terms of q . “ ”
- 48. Watch out for GPL Compatibility! It can make or break your business strategy.
- 49. GPL Accounts for many highly active and usable open source projects. *This will dictate how you can combine works and distribute your application *You may not use GPL’ed code if you’re using something that’s GPL incompatible. It pays to be GPL compatible*.
- 50. It pays to check the label.* A license is GPL compatible if: It allows the newly combined work to be released as GPL Allows you to have private modified versions, as long as modified code is not distributed to anyone else.
- 51. Drawing the Line Between GPL Compatible and Incompatible Licenses
- 52. These are GPL Compatible Licenses GNU General Public License (GPL) version 2 and 3 GNU Library (or Lesser) General Public License (LGPL) version 2 and 3 GNU Affero General Public License (AGPL) version 3 Apache License (APL) version 2.0 Modified BSD License (BSD-new) MIT/X11 License Public Domain (not really a license)
- 53. These are NOT GPL Compatible. Mozilla Public License (MPL, prior to version 1.1) Common Development and Distribution License (CDDL) Eclipse Public License (EPL) Common Public License 1.0 (CPL) Academic Free License (AFL) Open Software License (OSL) Artistic License 1.0 Creative Commons (CC)
- 55. Can You Re-License? It depends on how the derived work was created. Use of the Software Permissive Weakly-Protective Strongly-Protective Derivative Work (modified, copied code) YES DEPENDS NO Combined Work (static/dynamic linking) YES YES NO Derivative and Combined Work YES DEPENDS NO
- 56. GPL Violation Case: Cisco Cybertan used GPL code to customize Linux for Broadcom Broadcom embedded the code into one of its chipsets Linksys adopted Broadcom technology into its WRT54G wireless broadband router Cisco bought Linksys in 2003 More violations on http://gpl-violations.org/ The Free Software Foundation accused Cisco of violating the terms of GPL. It eventually released the source code, costing the company millions of dollars.
- 57. GPL Compatibility is most important when you plan to distribute a version of a derived work.
- 58. MIT/X11 License It permits reuse within proprietary software on the condition that the license is distributed with that software. Originates from the Massachusetts Institute of Technology (MIT)
- 59. BSD License 4-Clause BSD has an advertising clause. 3-Clause BSD (BSD-new) doesn’t require it. Works based on the material may be released under a proprietary license or as closed source software Originally used for the Berkeley Software Distribution (BSD), a Unix-like operating system after which the license is named
- 60. Apache Public License (APL) Only version 2.0 is GPL compatible. Older versions require too much attribution and an advertising clause.
- 61. GNU Library (or Lesser) General Public License (LGPL) Specifically designed for code libraries. If you modify the LGPL library then you must release your modifications under the LGPL, even though your application can remain closed source
- 62. Mozilla Public License (MPL) Source code, copied or changed under MPL must remain MPL. Can be combined with proprietary code. MPL 1.1 has a provision (section 13) that allows a program (or parts of it) to offer a choice of another license as well. Was referred to create CDDL, EPL The Source Code version of Covered Code may be distributed only under the terms of this License or a future version
- 63. GNU General Public License (GPL) It is the world’s most popular open source license. Treats an operating system process as the license boundary.
- 64. Affero GNU General Public License Practically the same as GPL, except it limits your freedom on opening a derived work as a service through a computer network.
- 65. To Sum Up Talk to a lawyer specializing in open source licenses Choose and use open sourced components that will work well with your business model. Take GPL Compatibility very seriously. Carefully consider using code with an open source license that does not have a huge following. If an OSS component isn’t distributed then you’re probably okay.
- 66. References http://www.dwheeler.com/essays/gpl-compatible.html http://www.slideshare.net/jaaronfarr/making-open-source-work-presentation http://rollerweblogger.org/roller/entry/gimme_credit_gimme_fixes_gimme http://www.slideshare.net/jaaronfarr/making-sense-of-open-source-licenses http://www.pythian.com/news/4006/fosslc-debate-which-open-source-license-is-best/ http://www.slideshare.net/kinshuksunil/open-source-for-dummies-presentation http://www.slideshare.net/deusexm/open-source-in-the-enterprise-compliance-and-risk-management-presentation http://www.slideshare.net/halehmahbod/open-source-workshop