Guinness to Weissbier, and back! Simone's Blog: few thoughts, little pieces of knowledge and my run in Dublin, München and elsewhere

Nella mia uscita podistica di Siviglia riuscirò a inserire una presenza alla Free Software World Conference, a Badajoz (200km da Siviglia, capitato per caso avendo prenotato Siviglia da mesi). Dovrebbe essere interessante, e negli ultimi mesi essendo stato coinvolto in un progetto relativo all’Open Source, Tossad ho avuto modo di riaggiornarmi e ampliare la conoscenza nel campo. Fortunatamente è oramai entrato nel tessuto del Computer Science in modo irreversibile ma ci sono certamente molti questioni aperte, dai Software Patent, alla miriade di approcci di Licensing, i problemi con i Copyright dei contenuti e per condire il tutto tutte le implicazioni Legali che spaziano da interpretazioni di licenze, legislazioni a livelli assolutamente diversi e intenzioni più o meno business oriented di chi usa l’Open Source o di chi detiene ogni tipo di Copyright. Starò solo una gionata e mezzo circa ma spero di raccogliere informazioni interessanti. Anzi avrò anche l’onore/onere di fare una presentazione parte delle conclusioni del progetto Tossad (ne sono contento, peccato solo che l’ho saputo ieri pomeriggio, ergo la slides le finirò 6 secondi prima di staccare la chiavetta USB ed inserirla nel computer collegato al proiettore). Vedrò di non dire cavolate, magari anche il modesto parere di un romagnolo che ha provato a sviluppare Open Source per “antiche” aziende del Cesenate (in certi contesti far capire che il codice che una azienda ti sta commissionando sarà “Aperto” a tutti, e che nonostante questo loro comunque ne avranno un vantaggio, è sempre stata una cosa difficile) potrà avere una qualche utilità! Comunque allego il mio contributo diretto al progetto, è un inglese imperfetto che necessita diverse correzioni, ma comunque comprensibile. La ricerca di documentazione su Web mi è stat di grande aiuto per riaggiornarmi, ritestare le idee e le convinzioni e rivedere punti di vista diversi. Aggiungo infatti la bibliografia che certamente è la parte su cui più vale la pena perdere tempo per chi fosse interessato.

Licensing and Legal
The panorama of Open Source licenses is wide and with many difference in how the “freedom” is approached and regulated. The GLP [31] approach is called protective or copyleft. One of the aim is to maintain open, the code it protects, some relevant licenses with the same style are LGPL [32], Mozilla Public License [34], Sun Public License [33] and Open Software License [20]. A relevant, and different approach, called non-copyleft, is used by the BSD License [30], that allows, starting from Open Source code, to release a closed source, commercial solution. Some relevant licenses with this approach are FreeBSD [29], NetBSD [27] , OpenBSD [26], Academic Free License [25], Apache Software License [24] , W3C Software Notice and License [17]. Is important to explore the difference between code freedom and developers freedom, to let developers and companies be aware of the proper license to use before to release any software. Another issue is the compatibility between licenses, and a proper evaluation of license issue is not a simple task. Some tools exists [21] to help in this process, but even if they can be used as a first analysis, they cannot cover the full procedure to decide what is the proper licensing schema to use. It’s obvious that F/OSS does not exclude business, but using F/OSS to create a Commercial solution involves the proper consideration of some important aspects. Care is needed in the choice of the license to use and the knowledge of the license that covers F/OSS eventually utilized. An example is how easy is to create a commercial solution starting from a non-copyleft license like FreeBSD, and what are the commercial limitation basing the solution on a GPL license. BSD style allow to change any software covered and close it creating a commercial non open solution, on the other side the use of GPL has the effect to be propagated to derivative work. Not casually LGPL is used to relax this strict propagation property of the GPL license. Is also important to outline how the legal aspects of F/OSS licensing is not well defined and some restriction, due to a license, may become an issue depending on the intention of the subject that own the copyright on the software that has been used or modified. GLP derivative work are required to be GLP’d, but the definition is not clear. A noticeable example is the addition of modules to the Linux Kernel. They may be considered derivative work, and some companies tried to solve the problem loading them after the Kernel is loaded, as external modules. The FSF would consider them derivative, and in that case they must be covered by GPL, but the owner of the Linux Kernel Copyright, Linus Torvald leaves a bit more freedom. He consider derivative any module, despite when is loaded, but not if it is just a merely rewrite of a module, originally written for another operating system. This make the situation not only under the variability of interpretation of the license itself, but also on how the owner of the copyright intend to use the license to protect the software.

Legislation and licensing
An important role in the issue of evaluating a license is the interaction between the license itself with different legislations and the interaction between legislation and legislation. As a representative example is the use of the word “derivative” in GPL license. This word come from the US legislation definition, but can be interpreted in different ways, allowing a wide range of uncertainty in how in a legal act this term would apply. The discussion is really open and is enough to consider the difference in executed software on one side and interpreted software on the other, that introduce other level of difficulties in applying license rules.
Consideration has to be put on commercial solution based on a F/OSS, both in case of a service or a further development of an original Open Source solution. Care must be put in covering responsibilities about the software not developed by the company itself, but coming from the F/OSS solution. The Open Source licenses usually don’t cover any malfunctioning including losing data, the responsibility relies on who use the F/OSS. To protect the company from legal act a detailed contract has to be done, protecting from unknown bugs from the original F/OSS. An example are commercial solution based on a Linux distribution or the Linux Kernel itself, that don’t directly cover the malfunctioning due to unknown kernel bugs, but include the configuration and maintenance to obtain the patch or updates as soon as they are available.
Working on this kind of contract it’s a complex task and they usually need to be prepared by lawyer in touch with more technical persons. Another factor introducing complexity is the interaction between different legislation in different countries and the level of understanding the single legislation have of the most known Open Source licenses.
A proper planning of license scheme have to deal with the possibility to change the politic of the release, there are examples of closed solution that moved to an Open Source license and successful F/OSS solution that as seen the developments partially closed to create commercial services and software solution based on them. Many scenario are possible an example is the change of licensing strategy because of the size of the software project or commercial strategy. A flexible and modular project may allow a licensing scheme able to be adapted to a growing project, to enable business solution to be added as plug-in in a common open core. On the other side, an inflexible software project based on a big, atomic core, may find difficult to be used as a base for a commercial solution, specially if it is covered with more protective F/OSS licenses.
As outlined above, different legislation cover and understand licenses in different way, so the evolution of EU, national legislations and international agreement can have a crucial role in the evolution of licenses and how business solution create, adopt or support Open Source. The situation is evolving and is important to have the capability to evaluate both the pure legal and licensing side, but in relation to the business model and the development methodologies in use.

Information privacy and security
Information privacy and security is another issue to evaluate, in principle is an issue for any software with any license, but the current legislations care about protecting sensible and personal data, in the aim to obtain privacy and the possibility to notify the subject in case of any thief of information. The development life cycle and licensing schema of an F/OSS or a commercial, not open solution based on an original F/OSS solution, may encounter limitation or misinterpretation about who has the responsibility in case of weak protection of sensible data, thief and related issue. A good understanding of the legal consequences has to be evaluated when selecting the media and the contract when an Open Source is provided, or on how to react in case of unknown bugs in case of a commercial solution that is in some way based on an original F/OSS.

Intellectual Property, Copyrights and Patents
As for privacy and security issues the intellectual property regards any software, independently from being Open or Close source or the used licensing scheme. Again F/OSS and the controversy of some Copyright Acts, and agreements, makes the F/OSS prone to misinterpretation and legal issues. An example is the Digital Millenium Copyright Act (DMCA), that restricts the creation, distribution and use of technologies that can circumvent systems intended to protect copyrighted material. Unfortunately, from the legal point of view, an F/OSS not originally developed for those purposed can be used or easily changed to do so. The controversy of interpretation of the rule has to be considered and evaluated when creating contracts and licensing scheme [22]. A sector to explore to have a real scenario example is the music distribution and the use of peer-to-peer (p2p) architectures.
Speaking about intellectual property of the software itself, have to be mentioned the controversy from SCO against Linux. SCO was claiming that some code with proprietary right was included in the Linux Kernel, and was asking to have a reimbursement from the Linux developers and users [22]. Independently from the fact that such a kind of claim is successful or not, it can anyway be a reason for companies with business based on Linux, or being Linux users, to be worried about that.
There is an important and open discussion about the adequate use of software patent, recognized in the US, with an attempt to introduce them in the EU. From one side the supporters indicated the patent scheme as a method to support investments but we are more likely to agree with the other part, and specially from the F/OSS world, that obviously sees the software patent as a limitation, making not possible to create a software based on a patented methods.
As a final statement it is important for developers and professional developers of F/OSS solution to be aware of the outlined issues, being them involved in producing themselves intellectual property, tools to manage copyrighted content and eventually under the coverage of software patents. On the other side is the professional developer, that have now a new role, to provide consultancy and the knowledge to properly evaluate the interactions between the software, licensing, copyrights and the involved legislations.

Development Methodologies
The developers life is affected in different way if is involved in a F/OSS development instead of a classic commercial solution. Even if a lot of technologies are commonly used in both the situation there are some aspects that are approached in a different way. Even if more and more heterogeneous situation are happening, due to the evolution of F/OSS in companies and the increased size of open communities, basically a F/OSS project involves people distributed in the territory, with a loosely coordinated activity, while a commercial environment is more likely to have a centralized control, with more pressure to obtain prefixed results due to company commitments. Some F/OSS projects started as a small community, if not a single author, with no initial interaction with other developers, and only when the software did reach enough visibility a real community born and the number of developers involved at different levels become quiet large. Obviously some of the developers maybe full-time, paid by companies with interest in developing any part of the project or extensions, but most, are usually part-time with unpredictable response time, because they are working for them personal interest in the project, for self-learning and motivated by the philosophical approach to the Open Source.
Both the cathedral style or the bazaar style is used in Open Source projects. The first usually is started by a single individual or a small community, that creates a main core of developers with a small interaction with other developers via suggestions and contributions. The second style is based on a open environment, where a dynamic interaction allow to continuously collect comments and contributions. Usually it is based on tools, like mailing lists, to manage open discussions. This approach allows to have more contributions, but introduce the drawback of having less control.
In any case an issue of F/OSS is to creation of new projects as branches of the original project. An open community may help in hosting all the issues and covering more request, so going in the direction to avoid the need to create another project. On the other side a project that becomes too wide may be more difficult to control and further develop. The creation of branches project can be a possibility to go in a direction not needed by the original group controlling the main development, but sometimes is a waste of resources, and simple split a community in groups instead of maintaining a common effort. The management of the project, and the architecture and organization of the code is important and F/OSS shows the capability to have a modular structure, while commercial solutions usually shows a relation with the structure of the company itself that can introduce limitations. As an example modularization is not only a concept of F/OSS, but a general software engineering concept, but within F/OSS is a great solution to overtake license limitation, project’s branches pollution, and to enable hybrid commercial-open solutions.
A different strategy in F/OSS development methodologies is also on how to manage new releases and backward compatibility. An interest of the community itself is to maintain users, that increase the group of potential contributors. Not having a cost of licensing and distribution for new releases, the project need to deal with the issue of the maintenance effort in upgrading or having new releases working with old data and/or environments. In different important projects different teams manages different main releases, an example is the Linux kernel, with development versions, collecting proposal and main improvements (and giving the possibility to test the functionalities under development by users), and stable releases, representing the last step for production versions.

The Apache project
As a valuable example we give some details about the Apache project, born in 1995 to coordinate the effort in improving the NCSA httpd program. A planning was done on how to coordinate distributed people contributing to the project on a volunteer part-time basis. A set of tools to help in the coordination of people distributed on the territory has been used to maintain the code and to make decisions. The developers is made by a core group, made by not more than 15-25 persons. A survey [19] shows that about 80% of the changes in the code is done by core developers, but at the same time problem reports and defect repair are more distributed in the community. More than 400 are the people that contributed to the code while more than 3000 contributed sending a problem report. Currently the Apache Server is used for 60% of the Web Sites with about double of the quote than the first commercial solution.

Business Models
Business with Open Source is currently done using different approaches, communities that became a company, companies that moved proprietary solution to F/OSS evaluating to have a benefit and obtaining revenue. A few examples shows that is likely to happen when a company is lagging behind the leader in the sector or when the company is nearly to disappear (Netscape is an example, releasing the Mozilla engine, that has been boosted opening the source code). Different big firms adopted F/OSS solutions, or created services relative to F/OSS, an example is IBM, working with Linux and Apache. A business created around a F/OSS consists of providing commercial complementary services and products not provided with F/OSS. Two example of companies doing that are Red Hat and VA Linux. F/OSS shows the capability to challenge proprietary solutions and to have an important role in the Business environment. The original approach itself, of having a free circulation of knowledge in the form of F/OSS is not against the business itself, but was indeed confusing making the adoption of F/OSS much slower in business environment. Is now understood by companies that F/OSS can be, on the opposite, a great resource. Some interesting studies explain why F/OSS is not anti-capitalist but indeed is an evolutionary step in the so called late capitalism [18].

Services or Software
Before 2001 the choice between selling software or services was more oriented in selling software, or better in selling a product. After 2001 it became more clear that a rapid change in the market situation would give problem to product oriented companies. Customers may be unwilling to invest in software or upgrades during recession phases stage, while services oriented companies are more protected having long term contract with customers. This may be interpreted as a positive news for F/OSS that enables the creation of commercial services (e-services) independently if the used software is F/OSS or not.
We consider Linux an important example in the F/OSS panorama, to speak about independent software vendors and value added resellers. The first approach, sees companies releasing solutions based on Linux or F/OSS libraries to build commercial solutions. On the opposite, value added resellers, adds a value providing ready solutions based on F/OSS, like some companies do with Linux distributions. An interesting example on how the flexibility of F/OSS effects markets, it’s again Linux, for the embedded systems market, where Linux enabled a bigger group of companies to create advanced solutions.
The use of F/OSS promoted and pushed the business connected with the need of qualified consultants and consultancy services. For example in system administration including F/OSS set-up and maintenance. Connected to those aspects there are the need of training, due to the request of qualified professional and also training for final users. The F/OSS philosophical approach touch this issue, allowing to have Open documentation, sometimes very complete and detailed. Examples comes from the know main F/OSS projects and to related material, covering some aspects of the IT, not describing a single F/OSS solution, but collecting F/OSS oriented knowledge, [23] is a valuable example for the Networking field.
Has also to be mentioned the importance given by the opportunity of introducing and using F/OSS in developing countries. This is not only important in trying to reduce the digital divide, but also a way to apply and create business models in completely new markets, with the possibility to fully enjoy the benefits of F/OSS.

[17] W3C Software and Notice License, http://www.opensource.org/licenses/W3C.php
[18] Samir Chopra, Scott Dexter, “The Political Economy of Open Source Software”
[19] Audris Mockus, Roy T. Fielding, James D. Herbsleb, “Two Case Studies of Open Source Software Development: Apache and Mozilla”
[20] OSI Certified Open Source Licenses, http://www.opensource.org/licenses/index.php
[21] Nordquist, P., Petersen, A., and Todorova, A. 2003. License tracing in free, open, and proprietary software. J. Comput. Small Coll. 19, 2 (Dec. 2003), 101-112.
[22] Jeffrey H. Matsuura, “An Overview of Leading Current Legal Issues Affecting Info rmation Technology Professionals”
[23] “How To Accelerate Your Internet”, Editor: Flickenger R.Associate Editors: Belcher M., Canessa E., Zennaro M.Publishers: INASP/ICTP, © 2006, BMO Book Sprint TeamFirst edition: October 2006, ISBN: 0-9778093-1-5 (PDF Available to http://bwmo.net/)
[24] Apache Software License, http://www.opensource.org/licenses/apachepl.php
[25] Academic Free License, http://www.opensource.org/licenses/afl-3.0.php
[26] OpenBSD License, http://www.openbsd.org/policy.html
[27] NetBSD License, http://www.netbsd.org/Goals/redistribution.html
[28] http://www.sourceforge.net
[29] Free BSD License, http://www.freebsd.org/copyright/freebsd-license.html
[30] BSD License, http://www.opensource.org/licenses/bsd-license.php
[31] GNU General Public License, http://www.gnu.org/copyleft/gpl.html
[32] GNU Lesser General Public License, http://www.gnu.org/copyleft/lesser.html
[33] Sun Public Licence, http://java.sun.com/spl.html
[34] Mozilla Public Licence, http://www.mozilla.org/MPL/MPL-1.1.html