You feel slighted by a comment on a mailing list, or a forum post has failed to be moderated live. How should you react?
A recent exchange on a user forum caught my eye, one that’s typical of many user interactions with open source communities. Someone with a technical question had apparently had the answer they needed and to help others in the same situation had posted a summary of the resolution, complete with sample code. When they came back later, the summary was gone.
I’ve no idea why this happened. It may have been a system issue, or an administrative error, or the user himself may have accidentally deleted it without realising. It’s even remotely possible an intentionally malicious act took place. Without more information there is no way to know. For the self-aware mind, responding to this situation is a matter of choice.
So how did the user in question respond? Well, he decided the only possible explanation was malicious deletion. He posted an angry demand that his account be deleted and assumed more malice when this was “ignored” (after 3 days, including a weekend, having posted the demand at the end of a comment in a user forum…)
No matter how you look at it, I don’t think that was a very smart choice. Given he was posting in a busy user forum managed by volunteers, and that this was his first post, the chance any action would be intentionally directed at him is vanishingly small. He would have been far smarter to put his ego on hold and take a lesson from driving principle of Wikipedia. “Assume Good Faith“.
That’s great advice in all communities of volunteer strangers. The things that happen usually have a great explanation, and the motivations of volunteers are almost always to make things better. So when a thing happens, or something is said, that you don’t understand or can’t explain, the best assumption to make is that it has happened “in good faith”. More significantly, when you think you do understand the motivation, over-ride your instinct and choose to respond as if it was good faith!
How to assume good faith
The chain of assumptions to make if you assume good faith might go like this:
- The thing was probably your mistake.
- If it wasn’t, then it was an unintentional defect.
- If it wasn’t, then it was the act of someone with more information than you acting correctly.
- If it wasn’t, then the person was acting in the belief they were correct but with imperfect information.
- If not, then they were inexperienced.
- But whatever the explanation, in the unlikely event you ever find out, don’t assume it was an act of intentional malice!
Maybe you can’t let any of the assumptions in that chain go. Maybe the person really is an idiot; it happens. All the same, an angry response is still not helpful, either to you or to the Community. Open source communities only thrive when a critical mass of participants choose to assume good faith in every interaction. The assumption is very occasionally misplaced, but even when that’s so it’s almost always better to respond by assuming good faith anyway.
That doesn’t mean it’s wrong to apply corrections. Good intentions do not guarantee good actions. But correcting a thing done in good faith has a distinct character of good faith itself. The original choice to act is welcomed and valued. The explanation of the flaw in the act is good-natured, clear, never patronising. The correction is generous. The whole thing is warm and seeks to build the confidence of the contributor.
It’s a lesson the detail-oriented among us need to remember (I include myself in that). The overwhelming majority of community actions are intended well. Treating them as such — even when they are wrong — will grow individuals and the community with them.
Individual judgment about the presence of software freedom in a license is not the same as community consensus expressed through OSI approval.
Does it really matter if a copyright license is OSI Approved or not? Surely if it looks like it meets the benchmark that’s all that matters? I think that’s the wrong answer, and that OSI license approval is the crucial innovation that’s driven the open source revolution.
“Open Source” describes a subset of free software that is made available under a copyright license approved by the Open Source Initiative as conforming with the Open Source Definition. Having a standards body for licenses — one which ratifies the consensus of an open community of license reviewers — saves individuals from needing to each seek out a legal advisor to tell them whether a given license does in fact give them the rights they need to build or deploy the software they want. By providing easy certainty, open source gives people permission in advance to meet their own needs and innovate with technology.
The only arbiter of OSD compliance is the license review process conducted collaboratively by the open source community and summarized and ratified by the OSI Board of Directors. Others have no role outside this process and are not entitled to assert that a non-approved license satisfies the OSD. As such, licenses that have not received OSI approval don’t satisfy the process and can’t be considered open source.
The strength of OSI’s approach is that it is objective; a license is either on the approved list or it is not. Licenses on the list are known to give permission in advance and unlock software freedom; those not on the list cannot be guaranteed to do either. The FSF uses a subjective approach that encourages speculation about whether a license is “free”. Meanwhile there are many with vested interests in diluting free and open source software who want a subjective approach where every individual may act as their own arbiter. Despite these pressures, it’s the OSI’s approach that has made open source succeed.
That’s not because a legalistic tick-in-the-box is really interesting. Rather, it’s because developers can gain certainty as to whether they can use a project simply by checking its approval status. No-one has to be asked for permission or clarification. Significantly, there’s no need to retain a lawyer just to check the license is in fact safe to use.
It’s easy to get overwhelmed by all the details of the many open source licenses, losing sight of the reason they are important. They’re important because every open source license guarantees the freedom to innovate without seeking permission first. OSI approval means you have the unconditional right to use the software in question for any purpose (sometimes calls “freedom zero”). You also have an unconditional right to make new software based on that software for your own use, and a conditional right to share the software — modified or not — with other people. The final case comes with some complexities beyond the scope of this article, especially for copyleft licenses.
That freedom to innovate, unlocked by the permissions the OSI-approved license guarantee in advance, is the powerhouse of open source. Developers know they can incorporate open source components without seeking legal advice. Users know they can deploy the software with the confidence that they have a license and won’t be persecuted by rent-seeking proprietary software companies. Together, this liberty has realized the potential of free software and propelled open source to dominance over the course of the last decade.
(A variant of this article was published in the Linux Voice section of issue 199 of Linux Magazine, June 2017)
Using the term “permissive” as an antonym to “copyleft” – or “restrictive” as its synonym – are unhelpful framing. Describe license reciprocity instead.
Some open source licenses implement a clever hack invented by Richard Stallman where, as a condition of the copyright license, anyone creating derived versions has to agree they will license the new version the same way as the original. In a play on words, this concept is called “copyleft” and many open source licenses implement this hack.
In its strongest form, the “copyleft” idea can place a condition on the licensing of all the other code compiled together to make the eventual binary executable program. Complying with this requirement can prevent use of business models that deny software freedom to the end user; as a consequence, many commercial software developers avoid the strongest forms of copyleft licensing.
There are less stringent forms of copyleft. Licenses like the MPL (Mozilla Public License) only require individual files that are modified to be licensed under the same license as the original and don’t extend that requirement to other files used to build the executable. The Eclipse Public License (EPL) has a copyleft provision that’s triggered by distribution of the source code. These scope-restricted variants are all described as “weak copyleft.”
In discussing these licensing approaches with clients, I’ve often found that these terms “strong copyleft” and “weak copyleft” lead to misunderstandings. In particular, developers can incorrectly apply the compliance steps applicable to one “weak” license to code under another license, believing that all such licenses are the same. As a consequence, I prefer to use different terms.
Instead of “copyleft” use “reciprocal licensing”
First, I try to address the challenges introduced by the clever, often unfamiliar term “copyleft.” The demonisation of copyleft by certain factions in the open source movement — who may even erroneously term such licenses “restrictive” — has made it appear more problematic than it really is. Instead, I explain that the communities involved have norms based of reciprocal behaviour and expect those working with their code to share with others the same freedom to innovate as they have received.
Leading licensing lawyer Eben Moglen (key co-creator of the modern GPL) explains that open source licenses embody the norms of the communities that use them. They are in many ways the “constitution of the community,” so the embodiment of norms of reciprocity is to be expected. I refer to this aspect of the license as “reciprocal licensing” in an effort to acknowledge the use of copyleft to express the community expectation of reciprocity. I’ve found this term leads to less confusion.
Instead of “strong” or “weak” copyleft, describe the reciprocity scope.
Second, I have found that the terms “strong” and “weak” are not well understood and less well defined. What really matters to developers is the expected scope of the reciprocity by the community that’s involved. This does not always mean contributing code to a project; for example, the GPL only requires that a developer offers to make code available on the same terms as the original, for a limited time per release. But reciprocity does mean that consistent licensing must be maintained.
This concept helps my clients in the case of the LGPL. That license is often described as a “weak copyleft” license since it allows combination of the resulting binary with non-GPL-licensed works (unlike the GPL itself). But the “weak” categorization is unhelpful as it means different things in different contexts.
LGPL is not “weak” in the same way MPL is, for example. Code from an LGPL project itself is fully reciprocally licensed at a project level. Any code borrowed from it for other uses as well as any alternative uses of the project itself are expected to be fully licensed under the same LGPL. Within the project itself, LGPL is “strong copyleft” just like GPL code, but the resulting executable does not necessarily have “strong copyleft” requirements – it’s effectively non-reciprocal in many uses.
I prefer to categorize reciprocal licenses by the scope and nature of the expected reciprocity. Licenses like GPL and EUPL set the scope of the expected reciprocity to include any code needed to create the resulting project binary, so I describe these as “project-scoped reciprocal licenses.” This categorization proves helpful with LGPLv3, which is a project-scoped reciprocal license with an exception limiting the boundary of the project.
Licenses like MPL set the scope of the expected reciprocity to the individual source files within the project, not the whole project collectively. If you change a file that’s part of the project, or reuse code from a file in the project in a new codebase, the resulting file must be licensed the same way as the original file, but there are no requirements placed on other files combined together to create new executables. I refer to these as “file-scoped reciprocal licenses.”
Instead of “permissive” use “nonreciprocal”
Thirdly, licenses like the MIT, BSD, and Apache licenses are sometimes described as “permissive.” That’s a bad word to use to differentiate any open source license. All open source licenses are predominantly permissive as they permit unconditional use, unlike proprietary licenses. Just as with reciprocal licenses, the communities involved have different expectations and embody them in their licenses. While they may not include reciprocity, they may still include burdensome terms.
For example, so-called “permissive” licenses may still include specific actions regarding attribution, or grant expansive patent licenses. They may also fail to include any terms concerning patents, creating risk. These attributes may also affect the business models a client can use, just in different ways to reciprocal licenses. Consequently, I find it more helpful to describe them as “non-reciprocal licenses” so that the classification is clearly limited to just the reciprocity characteristics of the licenses.
In practice, I have found that these three terms — project-scoped reciprocal, file-scoped reciprocal, and nonreciprocal –- highlight what matters most to developers and avoid unintentionally confusing the issue. I recommend their use instead of “permissive” and “weak/strong copyleft” or “restrictive”.
(A shorter version of this article was first published in InfoWorld, November 2013)
OW2, the global community for open source infrastructure software and application platforms, and the Open Source Initiative (OSI), the global steward of the Open Source Definition, announced at OW2con’17 that OSI has extended our support to OW2 as an associate member.
While both the OSI and OW2 have been working for yeas to promote software freedom, extending the partnership between the two organizations now, signifies several recent developments in shared initiatives:
- This year's OW2con’17 central theme was “New Challenges of Mainstream Open Source Software”, focusing on open source software as a viable and a mature option for corporate and government end-users. Both OW2 and OSI are increasing their efforts to help interested and adopting organizations understand the benefits of open source software, and to support decision makers through identification, and implementation.
- Simon Phipps, Board Director of the Open Source Initiative, is providing a keynote at OW2con’17 highlighting Open Source in its the Third Decade. OSI was established in 1998, and with it the term "open source software" to describe software licensed to enable collaboration around free software. 2018 consequently sees the start of the third decade of open source. What changes will we see? What principles can guide us?
- Cedric Thomas, CEO of OW2 offered, “As OW2 is celebrating its 10th anniversary, the Open Source Initiative is about to celebrate it's 20th. I’m looking forward to see our teams, members and communities working more closely. Together, we can address more market needs while developing new synergies”.
- Patrick Masson, Director and General Manager of the Open Source Initiative, acknowledges: “If indeed, as many now say, "open source has won", then we all should thank OW2 for playing their part over the past 10 years as a visionary, innovator and leader. All the best for the next ten”.
This partnership will bring OSI and OW2 members the benefits of a greater technical alignment of the two organizations, joint workshops and community events. For the latest opportunities, please visit our websites.
About the Open Source Initiative
The Open Source Initiative (OSI) is a California public benefit corporation, with 501(c)3 tax-exempt status, founded in 1998. The OSI is the stewards of the Open Source Definition (OSD) and the community-recognized body for reviewing and approving licenses as OSD-conformant and is also actively involved in Open Source community-building, education, and public advocacy to promote awareness and the importance of non-proprietary software. OSI Board members frequently travel the world to attend Open Source conferences and events, meet with open source developers and users, and to discuss with executives from the public and private sectors about how Open Source technologies, licenses, and models of development can provide economic and strategic advantages. You can learn more about the OSI at opensource.org or by emailing, firstname.lastname@example.org
OW2 is an independent industry community dedicated to developing open source code infrastructure (middleware and generic applications) and to fostering a vibrant community and business ecosystem. The OW2 Consortium hosts some one hundred technology projects, including ASM, Bonita, Chameleon, CLIF, DocDoku, Easybeans, Emerginov, Fractal, FusionDirectory, JOnAS, JORAM, JOTM, LemonLDAP:NG, Lutece, PetalsESB, Prelude, ProActive, SAT4J, Spagic, Spago4Q, SpagoBI, Talend Studio, Telosys, WebLab, XWiki. Visit www.ow2.org
How can you grow an open source community? Two blog posts from The Document Foundation (TDF) illustrate a proven double-ended strategy to sustain an existing community.
Since it was established in 2010, the LibreOffice project has steadily grown under the guidance of The Document Foundation (TDF) where I’ve been a volunteer — most lately as a member of its Board. Starting from a complex political situation with a legacy codebase suffering extensive technical debt, TDF has been able to cultivate both individual contributors and company-sponsored contributors and move beyond the issues to stability and effectiveness.
What made the project heal and grow? I’d say the most important factor was keeping the roles of individual and company contributions and interests in balance, as these two posts illustrate.
The first priority for growth in any open source project is to grow the individual contributor base. TDF has used a variety of techniques to make this possible, many embodied in first of the two illustrative posts, announcing another Contributor Month declared for May 2017 which asked people to:
- Help to confirm bug reports
- Contribute code
- Translate the user interface
- Write documentation
- Answer questions from users at ask.libreoffice.org
- Spread the word about LibreOffice on Twitter
As part of the event the co-ordinator promised to send specially-designed stickers to all contributors, providing a positive reinforcement to encourage people to join in and stay around.
Equally importantly TDF provides introductions to many contribution types. There is a well-established getting started guide for developer contributors, including the well-established “Easy Hacks” list of newbie-friendly things that need doing. There’s also a good introductory portal for translators/localizers.
All of this has been undergirded by sound technical choices that make joining such a complex project feasible:
- Reimplementing the build system so you don’t have to be a genius to use it
- Extensive use of automated testing to virtually eliminate uncalled code, pointer errors and other mechanically-identifiable defects
- An automated build system that stores binaries to allow easy regression testing
- Translation of comments into English, the project’s language-of-choice (being the most common second language in the technical community)
- Refactoring key code to use modern UI environments
Secondly, TDF has operated in a way that encourages the emergence of a commercial ecosystem around the code. That in turn has led to the continued employment of a substantial core developer force, even in the face of corporate restructuring.
LibreOffice has a very large user base — in the double-digit millions range worldwide — and many of those visiting the download page make financial donations to help the project. That’s a wonderful thing for a project to have, but it turns out that having money is not necessarily an easy blessing. It needs spending, but that has to be in a way that does not poison the contributor community.
Rather than hiring staff to work on the software, the project identifies areas where unpaid volunteers are not likely to show up and its Engineering Steering Committee proposes a specification. The Board of Directors then creates a competitive tender so that individuals or companies can earn a living (and gain skills) making LibreOffice better while still retaining the collaborative spirit of the project. Doing this builds commercial capability and thus grows the overall community.
So the second post is a sample tender, this one to do some unglamorous refactoring work to update the SVG handling. TDF is likely to receive a number of costed proposals and the Board will make a decision how to award the work based on the greatest community benefit — a combination of optimum cost, involvement of community members, nature of the bidder and more. The result is a community contributor fairly compensated without creating a permanent TDF staff role.
Balance Yielding Benefit
As a result of this and other carefully-designed policies, the LibreOffice project now has a developer force in the hundreds, companies whose benefits from LibreOffice lead to them making significant contributions, a reworked and effective developer environment with automated testing to complement the test team, and one of the most reliable release schedules in the industry. This means new features get implemented, bugs get fixed and most importantly security issues are rapidly resolved when identified.
This is what OpenOffice.org became when it left the commercial world. The early controversies have passed and the project has a rhythm that’s mature and effective. I think it’s actually better now than it was at Sun.