Free and Open Source Software (FOSS) Part II presented by Wolfgang Leister INF 5780 Høstsemester 2009 Ifi Universitetet i Oslo Some thoughts about FOSS
Open Source Software (1) 1. Free Redistribution The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale. 2. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed. 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Open Source Software (2) 4. Integrity of The Author's Source Code The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software. 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. 7. Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.
Open Source Software (3) 8. License Must Not Be Specific to a Product The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. 9. License Must Not Restrict Other Software The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. 10. License Must Be Technology-Neutral No provision of the license may be predicated on any individual technology or style of interface. FOSS licenses Any developer/licensor can draft an agreement that conforms to the OSD. Most licensors use existing agreements, such as: GNU Public License (GPL) Lesser/Library GNU Public License (LGPL) Mozilla Public License Berkeley Software Distribution license (BSD) Apache Software License See list at www.opensource.org/licenses
Licensing Models Proprietary Model Licensor distributes object code only; source code is kept trade secret Open Source Model Licensor distributes source code (+ possibly object code) Modifications are prohibited Modifications are permitted check licensing of modifications All upgrades, support and development are done by licensor Fees are for the software license, maintenance, and upgrades Sub-licensing prohibited, or is a very limited right Licensee may do its own development and support or hire any third party to do it Fees, if any, are for integration, packaging, support, and consulting Sub-licensing permitted; licensee may have to distribute the source code to program and modifications Other licenses Proprietary / Commercial licenses Shareware (trial period, no source code) Software as service (e.g., google) Shared source Codeplex Foundation www.codeplex.org Software rental (time-limits) cooperative organisation...
Yochai Benkler Yochai Benkler: «Coase's Penguin, or Linux and the Nature of the Firm», 2002 Three development models (two by Coase): Command Model Markets Peer Production Development models Can FOSS use conventional development model? Such as waterfall model,?? agile method / extreme programming Challenges How to involve the project community? How to manage the project?... Usually, just releasing some code to FOSS (e.g., changing the license) will not work! Unless there is a specific need for this
Open Source Development Model Project-Based Development by Informal Networks Maintainers Corporations (IBM, HP, Sun) Non-Profit Foundations (Apache Software Foundation) Individuals (Linus Torvalds) Contributors Users Repository, fora, bug-database,... Distributions, Updates and Upgrades Third Party Vendors Consultants Rules (Cathedral/Bazaar) 1. Every good work of software starts by scratching a developer's personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 3. Plan to throw one away; you will, anyhow. 4. If you have the right attitude, interesting problems will find you. 5. If you lose interest in a program, your last duty is to hand it off to a competent successor.
Rules (Cathedral/Bazaar) 6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. 7. Release early. Release often. And listen to your customers! 8. Given a large enough beta-tester and codeveloper base, almost every problem will be characterized quickly and the fix obvious to someone. 9. Smart data structures and dumb code works a lot better than the other way around. Rules (Cathedral/Bazaar) 10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. 11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. 12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
Rules (Cathedral/Bazaar) 13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible and NEVER throw away information unless the recipient forces to! Rules (Cathedral/Bazaar) 16. When your language is nowhere near touringcomplete, syntactic sugar can be your friend. 17. A security system is only as secure as its secret. Beware of pseudo-secrets. 18. To solve an interesting problem, start by finding a problem that is interesting to you. 19. Provided the development coordinator has a medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
How to organize FOSS? Users should be treated as co-developers Early releases Frequent integration Several versions (e.g., stable unstable testing experimental) High modularization Dynamic decision making structure There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors. Cf. Extreme programming. How to organize FOSS? Community site Software development management system Support for blogs, mailing lists, messaging, Bug-database, feature database, source database, Version control system, e.g., CVS, svn, git, Sourceforge (site) / Gforge (software) / GNU Savannah / Bountysource / Google source /... Common development tools e.g., GNU autotools, GNU, development language,... Distributions Package management system...
FOSS development methods Automatic testing Click to add an outline Nightly build /... Release Management Refactoring / rewrites /... Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). «A framework for creating hybrid-open source software communities.» Information Systems Journal 12 (1), 7-25 How to organize FOSS? Roles Responsible developer Contributer Integrator User Maintainer (of packages) Bug report
Quality of FOSS Compare quality of different products Free software vs conventional software OpenBRR Business Readiness Rating www.openbrr.org Spread-sheet for assessment Metrics weights rating Creative Commons License Nothing new in project... QualOSS - www.qualoss.org EU Project OpenBRR Metrics Compare with conventional software... Functionality Support Usability # messages in fora? Security Quality Performance Scalability Deployment? Architecture It is open source... Documentation Community Adoption How many fora? Is it used? Community? Professionalism Enter community?
Licenses / GPL / LGPL /... opensource.org/licenses www.gnu.org J.D. Marple: «What You Should Know About Open Source Software» Latham&Watkins (Law firm) http://www.lw.com/upload/pubcontent/_pdf/pub1062_1.pdf Open Source Compliance FSF Compliance Lab Ibrahim Haddad: «Open Source Compliance», Linux Journal, September 2009, pp.72-76 Source code scanning tools Open Source Compliance Insurance