Conservancy Now Developing Our Corporate Policies in Public via DVCS

by Tony Sebro on June 30, 2014

Everything Conservancy does comes back to our charitable mission: to promote, improve, develop, and defend FLOSS. Our member projects are well-known — and rightly so — for developing of some of the best freely-licensed software available today. And, we have a responsibility to match our projects' standard of excellence in all other aspects of the organization. For example, we have prioritized developing a FLOSS application for non-profit accounting, with the goal of developing a first-rate solution that can benefit the entire non-profit community.

As such, when one of our volunteer software developers recommends that we publish our corporate policies in a public repository, we listen. Earlier this month, Conservancy transitioned to developing our corporate policies in public via a distributed version control system (DVCS). Conservancy's conflict of interest policy, document retention policy, travel and expense policy, and whistle-blower policy are now available for inspection in a public Git repository¹.

We believe that developing our corporate policies in public via DVCS will have several benefits. For one, we're now working in a format immediately familiar to the software developers who contribute to our member projects. We expect that our policies will get more attention from a wider pool of volunteers, which will result in greater buy-in and fewer misunderstandings about policy interpretation. We also expect to receive more suggestions — in the form of patches or merge requests — that will result in stronger, better-written corporate policies.

We also expect and welcome input from the public at large. Conservancy's policies will be maintained by Conservancy's Board, who will have final say over all changes to our policies; however, we look forward to receiving comments, suggestions, and "bug reports" from anyone interested in non-profit corporate governance — as it relates to FLOSS or in general.

As a publicly-funded charity, Conservancy also has a responsibility to our donors and to the public at large to strive for transparency whenever possible. Now, as an attorney, I've been trained to always prefer keeping my cards close. However, I believe that our donors will appreciate that our policies are available for public inspection, and that we are therefore committed to holding ourselves publicly accountable to the standards we've articulated.

Lastly, we're pleased to announced that all of Conservancy's policies in the repository are now dedicated to the public domain under the Creative Commons CC0 license. We encourage our fellow charitable organizations to review and adopt some or all of our policies as they see fit.

So, we invite you to visit our corporate policies repository and review our policies. Scrutinize them, critique them, and submit merge requests. Treat it like a FLOSS project, roll up your sleeves, and get involved. We look forward to working with any and all contributors on strengthening the policies that help us pursue our charitable mission.

¹Conservancy is the non-profit home for three DVCS projects: Darcs, Mercurial, and Git. We love all of our member projects equally, but we felt that hosting our policies on all three platforms simultaneously would be overkill. We had to pick one.

[permalink]

Tags: conservancy

Why Your Project Doesn't Need a Contributor Licensing Agreement

by Bradley M. Kuhn on June 9, 2014

For nearly a decade, a battle has raged between two distinct camps regarding something called Contributor Licensing Agreements (CLAs). In my personal capacity, I've written extensively on the issue. This article below is a summary on the basics of why CLA's aren't necessary, and on Conservancy's typical recommendations to its projects regarding the issue.

In the most general sense, a CLA is a formal legal contract between a contributor to a FLOSS project and the “project” itself⁰. Ostensibly, this agreement seeks to assure the project, and/or its governing legal entity, has the appropriate permissions to incorporate contributed patches, changes, and/or improvements to the software and then distribute the resulting larger work.

In practice, most CLAs in use today are (at best) overkill for that purpose. CLAs simply shift legal blame for any patent infringement, copyright infringement, or other bad acts from the project (or its legal entity) back onto its contributors. Meanwhile, since vetting every contribution for copyright and/or patent infringement is time-consuming and expensive, no existing organization actually does that work. Thus, no one knows (in the general case) if the contributors' assurances in the CLA are valid. Indeed, since it's so difficult to determine if a given work of software infringes a patent, it's highly likely that any contributor submitting a patent-infringing patch did so inadvertently and without any knowledge that the patent even existed — even regarding patents controlled by their own company¹.

The undeniable benefit to CLAs relates to contributions from for-profit companies who likely do hold patents that read on the software. It's useful to receive from such companies (whenever possible) a patent license for any patents exercised in making, using or selling the FLOSS containing that company's contributions. I agree that such an assurance is nice to have, and I might consider supporting CLAs if there was no other cost associated with using them. However, maintenance of CLA-assent records requires massive administrative overhead.

More importantly, CLAs require the first interaction between a FLOSS project and a new contributor to involve a complex legal negotiation and a formal legal agreement. CLAs twist the empowering, community-oriented, enjoyable experience of FLOSS contribution into an annoying exercise in pointless bureaucracy, which (if handled properly) requires a business-like, grating haggle between necessarily adverse parties. And, that's the best possible outcome. Admittedly, few contributors actually bother to negotiate about the CLA. CLAs frankly rely on our “Don't Read & Click ‘Agree’” culture — thereby tricking contributors into bearing legal risk. FLOSS project leaders shouldn't rely on “gotcha” fine print like car salespeople.

Thus, I encourage those considering a CLA to look past the “nice assurances we'd like to have — all things being equal” and focus on the “what legal assurances our FLOSS project actually needs to assure its thrives”. We at Conservancy have spent years doing that analysis; we concluded quite simply: in this regard, all a project and its legal home actually need is a clear statement and/or assent from the contributor that they offer the contribution under the project's known FLOSS license. Long ago, the now famous Open Source lawyer Richard Fontana dubbed this legal policy with the name “inbound=outbound”. It's a powerful concept that shows clearly the redundancy of CLAs.

Most importantly, “inbound=outbound” makes a strong and correct statement about the FLOSS license the project chooses. FLOSS licenses must contain all the legal terms that are necessary for a project to thrive. If the project is unwilling to accept (inbound) contribution of code under the terms of the license it chose, that's a clear indication that the project's (outbound) license has serious deficiencies that require immediate remedy. This is precisely why Conservancy advises² that our projects select a FLOSS license with a strong patent clause, such as the GPLv3 or the Apache License, Version 2.0. With a license like those, Conservancy believes that CLAs are unnecessary.

Meanwhile, the issue of requesting the contributors' assent to the projects' license is orthogonal to the issue of CLAs. Conservancy does encourage use of clear systems (either formal or informal) for that purpose. One popular option is called the Developer Certificate of Origin (DCO). Originally designed for the Linux project and published by the OSDL under the CC-By-SA license, the DCO is a mechanism to assure contributors have confirmed their right to license their contribution under the project's license. Typically, developers indicate their agreement to the DCO with a specially-formed tag in their DVCS commit log. Conservancy's Evergreen, phpMyAdmin, and Samba projects all use modified versions of the DCO.

Conservancy's Selenium project uses a license assent mechanism somewhat closer to a formal CLA. In this method, the contributors must complete a special online form wherein they formally assent to the license of the project. The project keeps careful records of all assents separately from the code repository itself. This mechanism is a bit heavy-weight, but ultimately simply formally implements the same inbound=outbound concept.

However, most Conservancy projects use the same time-honored and successful mechanism used throughout the 35 year history of the Free Software community. Simply, they publish clearly in their developer documentation and/or other key places (such as mailing list subscription notices) that submissions using the normal means to contribute to the project — such as patches to the mailing list or pull and merge requests — indicate the contributors' assent for inclusion of that software in the canonical version under the project's license.

Ultimately, CLAs are much ado about nothing. Lawyers are trained to zealously represent their clients, and as such they often seek to an outcome that maximizes leverage of clients' legal rights, but they typically ignore the other important benefits that are outside of their profession. The most ardent supporters of CLAs have yet to experience first-hand the arduous daily work required to manage a queue of incoming FLOSS contributions. Those of us who have done the latter easily see that avoiding additional barriers to entry is paramount. While a beautifully crafted CLA — jam-packed with legalese that artfully shifts all the blame off to the contributors — may make some corporate attorneys smile, but I've never seen such bring anything but a frown and a sigh from FLOSS developers.

⁰Only rarely does an unincorporated, unaffiliated project request CLAs. Typically, CLAs name a corporate entity — a non-profit charity (like Conservancy), a trade association (like OpenStack Foundation), or a for-profit company, as its ultimate beneficiary. On rare occasions, the beneficiary of a CLA is a single individual developer.

¹I've yet to meet any FLOSS developer who has read their own employer's entire patent portfolio.

²Conservancy doesn't mandate any specific Open Source and Free Software license for our projects. That's just not our style. Any license that appears as both an Open Source license on the OSI-approved list and as a Free Software license on FSF's license list is good enough for Conservancy.

[permalink]

Tags: conservancy, GPL, CLA

Considerations on a non-profit home for your project

by Bradley M. Kuhn on December 5, 2013

I came across this email thread this week, and it seems to me that Node.js is facing a standard decision that comes up in the life of most Open Source and Free Software projects. It inspired me to write some general advice to Open Source and Free Software projects who might be at a similar crossroads⁰. Specifically, at some point in the history of a project, the community is faced with the decision of whether the project should be housed at a specific for-profit company, or have a non-profit entity behind it instead. Further, project leaders must consider, if they persue the latter, whether the community should form its own non-profit or affiliate with one that already exists.

Choosing a governance structure is a tough and complex decision for a project — and there is always some status quo that (at least) seems easier. Thus, there will always be a certain amount of acrimony in this debate. I have my own biases on this, since I am the Executive Director of Conservancy, a non-profit home for Open Source and Free Software projects, and because I have studied the issue of non-profit governance for Open Source and Free Software for the last decade. I have a few comments based on that experience that might be helpful to projects who face this decision.

The obvious benefit of a project housed in a for-profit company is that they'll usually always have more resources to put toward the project — particularly if the project is of strategic importance to their business. The downside is that the company almost always controls the trademark, perhaps controls the copyright to some extent (e.g., by being the sole beneficiary of a very broad CLA or ©AA), and likely has a stronger say in the technical direction of the project. There will also always be “brand conflation” when something happens in the project (Did the project do it, or did the company?), and such is easily observable in the many for-profit-controlled Open Source and Free Software projects.

By contrast, while a for-profit entity only needs to consider the interests of its own shareholders, a non-profit entity is legally required to balance the needs of many contributors and users. Thus, non-profits are a neutral home for activities of the project, and a neutral place for the trademark to live, perhaps a neutral place to receive CLAs (if the community even wants a CLA, that is), and to do other activities for the project. (Conservancy, for its part, has a list of what services it provides.)

There's also difference among non-profit options. The primary two USA options for Open Source and Free Software are 501(c)(3)'s (public charities) and 501(c)(6)'s (trade associations). 501(c)(3) public charities must always act in the public good, while 501(c)(6) trade associations act in interest of its paying for-profit members. I'm a fan of the 501(c)(3)-style of non-profit, again, because I help run one. IMO, the choice between the two really depends on whether you want the project run and controlled by a consortium of for-profit businesses, or if you want the project to operate as a public charity focused on advancing the public good by producing better Open Source and Free Software. BTW, the big benefit, IMO, to a 501(c)(3) is that the non-profit only represents the interests of the project with respect to the public good, so IRS prohibits the charity from conflating its motives with any corporate interest (be they single or aggregate).

If you decide you want a non-profit, there's then the decision of forming your own non-profit or affiliating with an existing non-profit. Folks who say it's easy to start a new non-profit are (mostly) correct; the challenge is in keeping it running. It's a tremendous amount of work and effort to handle the day-to-day requirements of non-profit management, which is why so many Open Source and Free Software projects choose to affiliate or join with an existing non-profit rather than form their own. I'd suggest strongly that the any community look into joining an existing home, in part because many non-profit umbrellas permit the project to later “spin off” to form your own non-profit. Thus, joining an existing entity is not always a permanent decision.

Anyway, as you've guessed, thinking about these questions is a part of what I do for a living. Thus, I'd love to talk (by email, phone or IRC) with anyone in any Open Source and Free Software community about joining Conservancy specifically, or even just to talk through all the non-profit options available. There are many options and existing non-profits, all with their own tweaks, so if a given community decides it'd like a non-profit home, there's lots to chose from and a lot to consider.

I'd note finally that the different tweaks between non-profit options deserve careful attention. I often see people commenting that structures imposed by non-profits won't help with what they need. However, not all non-profits have the same type of structures, and they focus on different things. For example, Conservancy doesn't dictate anything regarding specific CLA rules, licensing, development models, and the like. Conservancy generally advises about all the known options, and help the community come to the conclusions it wants and implement them well. The only place Conservancy has strict rules is with regard to the requirements and guidelines the IRS puts forward on 501(c)(3) status. Meanwhile, other non-profits do have strict rules for development models, or CLAs, and the like, which some projects prefer for various reasons.

⁰BTW, I don't think how a community comes to that crossroads matters that much, actually. At some point in a project's history, this issue is raised, and, at that moment, a decision is before the project.

[permalink]

Tags: conservancy

Conservancy launches a new brand identity

by Tony Sebro on February 28, 2013

The Binary Tree logo and updated wordmark reflect a cleaner and more modern representation of Conservancy's commitment to promoting, supporting, and defending Free, Libre, and Open Source Software (FLOSS) projects.

The Binary Tree logo, designed by April Ricafort-Custodio using Inkscape, incorporates a binary tree diagram - representing both a fundamental principle of computer science and our various member projects - into a streamlined version of Conservancy's shade tree silhouette. The wordmark was created using Open Sans Condensed, a sans-serif typeface designed by Steve Matteson and licensed under the Apache License, Version 2.0.

A ZIP archive of the logo sheet in PDF, SVG, ODG, and PNG formats can be downloaded here. The copyrights associated with Conservancy's logo and wordmark are licensed under CC-By-SA-3.0 USA. The marks “Software Freedom Conservancy,” “Conservancy,” and the Binary Tree logo and wordmark are trademarks of Software Freedom Conservancy.

[permalink]

Tags: conservancy