I attended LinuxTag in Berlin last week and there was a very interesting presentation about the state of Munich's migration to Linux on the desktop. Andreas Heinrich explained that their goal is to migrate 80% of the 15000 desktops to Linux. At the moment, 6200 desktops have been migrated and they intend to have a total of 8500 Linux desktops by the end of the year.
Here are some of the key lessons they shared with the audience:
- Technical activities and requirements are easy to manage but managing social factors of change is hard since all change is associated with fear. They have specific people who are responsible for change management and for communication. For example, they organize events to share information and provide training. They also give away CDs so that employees can use the software at home.
- Make sure the new system is accepted: if users don't like the system (for whatever reason), their boss and other employees will know immediately since "bad news travels fast". Make sure that user needs are met: they talk a lot to their users to find our what their needs are and how to meet them.
- Don't make a "big bang" migration: instead of migrating everyone at the same time, they prefer gradual change. They started with some users, saw what worked and what didn't and then used that knowledge to improve their migration process.
- Don't migrate everyone: their aim is to convert 80% of desktops to Linux. There are some users who have specific needs for which only proprietary solutions exist. If Linux and open source offers no solution, it doesn't make sense to migrate those users.
- Don't go with dual-boot: if open source meets the needs of your users, there's no reason to provide an alternative. On the other hand, if open source does not meet their needs, don't attempt a migration.
- Continuous improvement: after making a new release of their software or migrating users, don't consider the migration as complete. Instead, see how you can further improve the user experience.
It seems that the city of Munich has learned a lot from their Linux migration. We can hope that other Linux migrations will make use of the lessons learned by the folks in Munich.
The first part of this article explained the purpose and scope of Contributor Agreements in open source projects. This article presents an overview of some Contributor Agreements that are used in the community.
Contributor Agreements come in all shape and forms, ranging from full-fledged Contributor License Agreements (CLA) that have to be signed to informal consent to some set of rules. This article will take a look at a number of different agreements in order to show that community norms can vary widely.
Apache's Individual Contributor License Agreement
The Apache Software Foundation (ASF) maintains two formal Contributor License Agreements (CLA), one for individual contributors and one for corporate contributions. The Individual CLA covers the following points:
- Contributors grant the ASF and recipients of software distributed by the ASF a broad copyright license.
- Contributors grant a patent license to their contributions.
- Contributors acknowledge that they are legally entitled to grant the above license.
- Contributors acknowledge that each of their contributions is their original creation.
- Contributors are not expected to provide support for their contributions, except to the extent they desire to provide support.
- How to handle submissions of work that that is not their original creation (i.e. works by a third-party).
- Contributors agree to notify the ASF when any circumstances change.
Fedora Project Contributor Agreement
Fedora is in the process of adopting the Fedora Project Contributor Agreement (FPCA), which covers the following points:
- Contributors have to ensure that they have proper permission to make a contribution. For example, they can ask their employers to put the contribution under an open source license that Fedora accepts.
- If a contribution has a license, this license is followed.
- Fedora defines some default licenses for contributions which don't explicitly state the license. For code contributions, the MIT is used; the Creative Commons Attribution ShareAlike 3.0 Unported license is used for content.
The Fedora Project Contributor Agreement does not require contributors to assign copyright to Fedora or Red Hat.
Linux kernel Developer's Certificate of Origin
The Linux kernel project has adopted the Developer's Certificate of Origin. Developers use it to assert the following points:
- The contribution was created by me and I have the right to submit it under the indicated open source license.
- The contribution is based on previous work that is also under the indicated license.
- The contribution was provided directly to me by someone who certified it and I didn't modify it. -- This clause is useful because contributions pass through subsystem maintainers without modification until they reach Linus Torvalds, the maintainer of the Linux kernel.
- I understand that the contribution and project are public and recorded. -- This has nothing to do with code origin but with privacy, as all the work on the Linux kernel is done in the public.
The way by which developers accept the Developer's Certificate of Origin for each contribution is to put a
Signed-off-by line with their name between the description of their change and the actual change.
Debian's Social Contract
While Debian has no formal Contributor Agreement per se, all contributors who become official members of the project have to accept Debian's Social Contract for their Debian related activities. Among other things, the Social Contract states that "Debian will remain 100% free" (free according to the Debian Free Software Guidelines). Therefore, it can be implied that all contributions to Debian made by members of the project are open source. The license of contributions without explicit license statements is not clear since Debian does not define a default license like Fedora. However, Debian developers are encouraged to specify the copyright and license information for their submissions in the
debian/copyright file of their software packages.
Contributor Agreements, also known as Contributor License Agreements (CLA), are increasingly being adopted by open source projects. This article explains the purpose of these Contributor Agreements.
When a contribution is made to an open source project, there is an implicit assumption (and sometimes explicit consent) that the contribution (code, translation, artwork, etc) may be incorporated into the project and distributed under the license the project is using. However, many conditions of the contribution are not explicitly called out. The purpose of Contributor Agreements is to make the terms under which contributions are made explicit, thereby protecting the project, the users of the software and often also the contributors.
Apache Software Foundation (ASF) describes the aim of their CLA in this way: "The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time." Contributor Agreements also ensure that contributions cannot be withdrawn by the contributor, as the FAQ for the Django CLA explains: "The CLA also ensures that once you have provided a contribution, you cannot try to withdraw permission for its use at a later date. People and companies can therefore use Django, confident that they will not be asked to stop using pieces of the code at a later date."
Contributor Agreements therefore provide confidence that there likely won't be any legal issues in the future regarding the individual contributions that make up the project, such as disputes over origin and ownership. A downside of Contributor Agreements is that they pose a small overhead and barrier to contribution. This can particularly be a problem for minor contributors who may feel that getting their fixes accepted is not worth the hassle of filling out a Contributor Agreement.
Which points do Contributor Agreements generally cover? There is a lot of variation among Contributor Agreements but the following areas are often covered:
- Copyright: contributors grant a broad set of permissions and they are sometimes asked to assign their copyright to the project. The Contributor Agreement also ensures that contributors are entitled to contribute their changes to the project.
- Trademarks: contributors ensure that marks (if there are any) are owned by the project rather than by individual contributors. This avoids possible disputes in the future if contributors leave a project.
- Patents: contributors grant a patent license to the project in order to ensure that a contributor cannot attack the project in the future by asserting its patents against it.
- Moral rights: contributors are asked not to assert any moral rights (where they exist) in order to stop derivative works.
- Contributions by minors: some Contributor Agreements define how contributions by minors are handled.
I'll give an overview of some Contributor Agreements in a future article.
Open source is everywhere today and there is growing awareness that companies have to meet certain obligations when distributing open source software. Here are some useful resources to learn more about open source compliance.
- The FSF Free Software Licensing and Compliance Lab handles all licensing-related issues for the Free Software Foundation (FSF), the maintainers of the GPL license. They offer a lot of information about the GPL and other open source licenses.
- The Freedom Task Force (FTF) of the Free Software Foundation Europe (FSFE) shares knowledge about open source licensing and offers training about licensing and related topics for companies.
- The GPL-Violations project is a good point of contact for resolving GPL violations, especially in Europe.
- The Open Source Initiative (OSI) maintains the Open Source Definition and approves open source licenses.
- The Software Freedom Law Center provides legal representation and other law-related services to open source projects and shares a lot of knowledge on legal topics, such as a legal issues primer for open source projects.
- FOSSBazaar is an open community about the governance of open source. It provides a platform to discuss and exchange best practices related to the governance of open source.
- The FSFE Legal Network is an invitation-only network of legal professionals and compliance folks that aims to facilitate knowledge exchange.
News and journals
- Groklaw is a web site that covers legal news of interest to the open source community.
- The International Free and Open Source Software Law Review is a collaborative legal publication aiming to increase knowledge and understanding among lawyers about open source issues.
- EOLE, the European Open Source & Free Software Law Event, is an annual conference in Europe to disseminate legal knowledge and develop best practices.
- The European Legal Network (ELN) workshop is the annual meeting of the FSFE legal network.
- The Binary Analysis Tool can be used to audit the contents of compiled software.
- FOSSology is a tool to study and analyze open source code. It can be used for license and copyright detection.
- The Open Source License Checker is a tool for the inspection and analysis of license information from open source packages.
- Proprietary tools from Black Duck Software, Palamida, etc.
One key element of open source compliance is to know your obligations. There is a lot of confusion about what open source means exactly and some people believe that open source means you can do whatever you want. While open source grants users many freedoms, open source code comes under specific license terms which often include obligations that have to be followed by companies distributing open source software.
Because of recent lawsuits by the Software Freedom Law Center on behalf of the busybox project and the activities of the GPL-Violations project, awareness is growing that copyleft licenses such as the GPL come with obligations. For example, the GPL requires source code to be offered to those who receive binaries. The AGPL goes a step further and additionally requires that the source code be made available to users who interact with the software over the network.
But what about so called permissive licenses, such as BSD and MIT? Some people say that those licenses allow you to do anything, including putting the code into proprietary applications. And while you can do that, there are still obligations that have to be met. For example, the BSD class of licenses has this condition:
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
If you want to distribute software that is under a BSD license, that's a condition you have to follow. The MIT license also has a very similar clause. That's the reason why you can often find license information in the "about" window of commercial applications or PDFs on CDs that come with hardware products.
The bottom line is simple: know your obligations!
A lot of people seem to think that open source is a magic solution to project management and that open source projects will automatically attract a large and healthy community of contributors and users who will improve the software. This, of course, is not the case. In fact, creating a successful open source project is a really major and difficult effort. You have to deliver an initial promise that people find interesting, attract other people, then facilitate and lead the community, etc. You just have to look at all the failed projects on SourceForge that never delivered any code to see that "open source" is not a guarantee for success.
Even though project management is a key element of every open source project, there are only few resources about this topic. That's why I always enjoy reading about the experience from open source project leaders. Jim Hall, the founder of the FreeDOS project, recently posted a series of four articles which I find particularly interesting.
Here are links to the articles along with a quick summary:
- Free and Open Source Software: the first article just describes what free software and open source are all about. It also looks at Raymond's model and compares the cathedral and the bazaar style of development.
- Starting Open Source Software: this article summarizes a number of key lessons learned: every project needs a clear purpose (i.e. you have to solve an actual problem); initial users of the software should be recruited as developers; releases are important; and every project needs an active coordinator or maintainer.
- Cultivating Open Source Software: you need a web site; making the source code availability in an easy way is important; documentation is often hard to write but is vital; you need a bug tracking system and responding to bug reports is important to attract good feedback.
- Transitions in an open source software project: finally, when you need to hand over the project, make sure to communicate openly, arrange for your replacement and stick around to ensure a successful hand over.
I really like these articles from Jim Hall since they contain a lot of great insights that apply to other projects, so I suggest you check them out!
(Originally published on FOSSBazaar)
Someone recently asked me a few question about corporate participation in open source communities and I thought I'd share my thoughts on this topic here.
Are there differences between an open source project done for a corporation and one done for personal reasons?
There are many different ways to run an open source project, led by a corporation or by someone else. Some projects that are run by corporations have few outside contributors. This is often the case with projects that require copyright assignment (i.e. contributors have to assign their copyright to the corporation). These projects may not gain all the benefits of a true open source community, such as outside contributions or high levels of peer review. However, they may still be very successful projects and may have high levels of quality.
Projects done by a corporation may have better planning and may have more resources than other projects. When a corporation, especially a large one, starts or becomes involves in a project it can also give credibility to the project and attract a lot of interest to the project. This means that projects done by corporations may have a bigger impact and might also be more visible in terms of publicity.
How do corporations successfully utilize an open source community?
Corporations can benefit from an open source community in many ways. For example, they can often find people who will review their code or make code contributions. If people become excited about what the corporation does, they might also spread the word and create viral marketing for the corporation. Establishing a community around one's project is often also a good way to identify people to hire since you already have experience working with them and know their capabilities.
How do open source communities successfully utilize their corporate relationships?
Corporations can make several unique contributions. For example, large corporations can use their name to attract attention to a project and give it credibility. Furthermore, corporations have some capabilities that personal contributors often don't have access. They may have special testing equipment (such as servers with thousands of CPUs or hard drives) or access to a testing lab where a professional usability test can be done. Finally, corporations can sponsor developer conferences, which are typically very effective means for the community to come together and work on activities together.
It is important for projects to remember that corporations are not charities and that they will invest in an open source project for a reason. Therefore, they have to ensure that the corporation will get tangible outcomes from their involvement or sponsorship, otherwise they may not stay involved in the long run.
What are the risks for a corporation when working with an open source community?
One risk is that the code (or other form of contribution) is not accepted. However, this is a risk any contributor to a project faces. Before making any sort of contribution, it is therefore important to become familiar with the project and its culture. Every project has their own "do's" and "don'ts" that have to be followed.
Another risk is that a corporation will invest in a community project that later on is abandoned by the community. However, in this case, the corporation could take the lead and continue to maintain the project.
What are the risks for an open source community when working with a corporation?
One potential risk is that the corporation will assert too much control over the project. It's important for projects to ensure that the community as a whole has influence over the direction of a project rather than one particular player.
Are certain certifications needed in order for someone to participate in open source projects for a corporation?
Certifications are not needed to get involved in or start a project. However, it is important to become familiar with the open source community and the project one wants to contribute to. A good first step is to read the book Producing Open Source Software by Karl Fogel which is available online. As a next step, the community in which someone wants to get involved in should be studied, for example by reading the mailing list archives. This will help to become familiar with the culture of a project as well as the mechanisms to contribute to the project.
How do open source communities communicate and collaborate with corporations?
In the best case, employees from corporations would interact in the project like any other contributor. That is, they should use the existing communication channels, such as mailing lists, IRC or developer gatherings. Many companies are good at working "with the community" but the ideal scenario is for a company to be part of the community and to work "in the community", just like other contributors. This is the most effective way for them to make changes to the code and project.
Of course, not every corporation will get involved in a project directly. That's why it makes sense for projects to collaborate with corporations in other ways. For example, projects can talk directly to companies to get samples of their hardware in order to add support for them in their software. Projects can also work directly with corporations to find out how their project can better meet the needs of enterprise users.
I visited Seoul last week to represent the Open Source Initiative (OSI) at an open source conference and to sign a Memorandum of Understanding (MOU) with the Korea Software Copyright Committee (SOCOP). SOCOP organized a conference with the title "Free Open Source Software License Insight Conference", and the international speakers included Brett Smith of the FSF, Brendan Scott of Open Source Law, Michael Coté of RedMonk and myself. From the questions we received, it seems that there is a lot of interest in legal questions related to open source. There were a number of folks from hardware companies that asked specific questions what they could do and couldn't do (e.g. related to including sources for GPL code and properly giving credit for BSD code).
I think the conference was a great success. The talks were of high value and we got good questions. The audience was quite mixed, ranging from managers to developers. Even though they had simultaneous translation of the talks, the majority of the people listened in English... this gives me hope that some of these folks will end up becoming involved in the international open source community.
SOCOP is working on a number of activities related to open source, including:
- An information portal called OLIS.
- The translation of all OSI approved licenses to Korean.
- The verification of open source code to identify which code uses which license.
- More promotional activities, including workshops and conferences.
The day after the conference, I went to the SOCOP office to sign the MOU between SOCOP and OSI with Mr Yung Bo Koo, the chairman of SOCOP. The MOU says that we'll share knowledge and expertise, help with promotional activities and support each other's activities in other ways. I was delighted to sign the MOU between SOCOP and OSI, and I look forward to a fruitful cooperation between our organizations in the future. It's great to see so much interest and so many activities around open source in the Republic of Korea.
It is often argued that companies have to work with the FOSS community and there are good reasons for doing so. I've tried to collect a number of case stories of good and bad community interaction that may help as a starting point for further exploration of this topic:
- NVidia is probably the best example of a company that is not interested in providing open source drivers for their graphics chips. There are lots of folks who won't buy hardware with NVidia chips for this reason. Intel is the number 1 choice at the moment because they work closely with the community. Related to this, the Linux Foundation and kernel community released a statement regarding open drivers.
- When Sun finally made Java available as open source, they argued that it would help inclusion and distribution of Java (e.g. inclusion into Debian). Sun also felt that the GPL provides the strongest protection "against misbehaviour by monopolists in the Java platform".
- The Novell/Microsoft deal was not perceived well by the community, which led to web sites like http://boycottnovell.com
- Nokia recently had an insightful blog posting about the problems when nobody knows about the open source contributions you make: for example, you cannot influence decisions in a project as easily.
- Sun is often criticized for dominating all open source projects they run. They can be used as a good example that you have to give up some control in order to get outside participation.
- The fact that Xen is not in the mainline kernel is a key reason why a number of companies (e.g. IBM, Red Hat) are looking at KVM (which is in the mainline kernel and actively developed in the community). In fact, "looking" is probably not the best word. IBM is actively working on KVM to make it a viable solution and Red Hat recently acquired Qumranet, the company behind KVM.
- Oracle got fairly bad press for copying the Red Hat distribution and changing Red Hat to Oracle, without engaging in the Red Hat community.
- There's a paper that looks at "empirical evidence on the incentives of firms that engage in OS activities". They look at 146 Italian companies supplying open source solutions, but unfortunately the study doesn't include any major company.
Can you think of other examples?
(Originally published on FOSSBazaar where comments are possible)
The Open Source Repository and Observatory (OSOR), a new site sponsored by the European Commission to foster the exchange of FOSS related information and software among European public administrations, recently published guidelines">guidelines on the procurement of open source software. Public administrations in Europe have to follow public tender procedures and the new guidelines give practical and legal advice on how open source software and related services can be incorporated into the procurement process.
Rishab Ghosh, who presented the guidelines at the Open Source World Conference in Malaga, argued that the procurement guidelines were needed because of two reasons. First, they studied recent tenders and found that many explicitly mentioned proprietary applications. 16% of 3615 software tenders explicitly asked for products from top 10 software vendors, such as Microsoft, SAP and Oracle. This practice may be illegal because public tenders generally have to describe functional requirements in a general way instead of specifying specific products. Second, many public administrations don't have any experience with the procurement of FOSS. In fact, they often don't know whether or under which circumstances they are allowed to adopt and ask for FOSS solutions. The guidelines are specifically designed in order to clearly and simply explain how public administrations can acquire open source and they don't assume that a country has adopted a specific policy regarding open source.
The guidelines include a long section about open standards, open source and how they relate. Both open standards and open source align very well with the needs of public administrations who have an "obligation to support interoperability, transparency and flexibility, as well as economical use of public funds". The guidelines argue that the exit cost, i.e. the cost incurred in moving to another IT system, is also an important consideration but one that is often neglected. The adoption of a proprietary solution without open standards may limit the future choice, thereby increasing the long-time costs and giving the proprietary vendor an unfair advantage in future tenders.
The procurement guidelines describe two ways of acquiring FOSS: it is possible to go the usual route of publishing a tender for the supply of software (possibly with related services). However, in the case of FOSS, it is also possible to download the software directly from the Internet. This is possible because the software is not only free of charge but comes with no contractual obligations. If there were any obligations involved with the download (such as fees, the agreement to an EULA or the requirement to purchase services in the future), software download is not an allowed method. What I like about the guidelines is that they explicitly say that downloading software has to be part of the formal procurement process. You have to think about your requirements, look at various alternatives, and so on, and not just blindly download something from the Internet.
When it comes to the procurement of FOSS, the guidelines don't suggest that tenders should explicitly ask for FOSS. Instead, they should describe the functional requirements of the software as well as certain properties. For example, a tender could specify that the public administration as well as third parties must have the right to study, distribute and modify the software. In a sense, the guidelines suggest that tenders should include the principles of the Free Software Definition along with justifications for these requirements.
Personally, I think there is a great need for these procurement guidelines. There are many public administrations that don't know how to acquire FOSS and these guidelines offer clear advice. Furthermore, I find the guidelines very balanced. They don't recommend that you should always ask for FOSS but incorporate FOSS principles into tenders where it makes sense. It remains to be seen whether the procurement guidelines will have an impact on the FOSS adoption in Europe, but I surely hope so.
(Originally published on FOSSBazaar)
You can find older blog articles in my blog archive.