September 11, 2014 by Bradley M. Kuhn
[ A version of this post originally appeared on the Google Open Source Blog. ]
Software Freedom Conservancy, Inc. is a 501(c)(3) non-profit charity that serves as a home to Open Source and Free Software projects. Such is easily said, but in this post I'd like to discuss what that means in practice for an Open Source and Free Software project and why such projects need a non-profit home. In short, a non-profit home makes the lives of Free Software developers easier, because they have less work to do outside of their area of focus (i.e., software development and documentation).
As the summer of 2014 ends, Google Summer of Code (GSoC) coordination work exemplifies the value a non-profit home brings its Free Software projects. GSoC is likely the largest philanthropic program in the Open Source and Free Software community today. However, one of the most difficult things for organizations that seek to take advantage of such programs is the administrative overhead necessary to take full advantage of the program. Google invests heavily in making it easy for organizations to participate in the program — such as by handling the details of stipend payments to students directly. However, to take full advantage of any philanthropic program, the benefiting organization has some work to do. For its member projects, Conservancy is the organization that gets that logistical work done.
For example, Google kindly donates $500 to the mentoring organization for every student it mentors. However, these funds need to go “somewhere”. If the funds go to an individual, there are two inherent problems. First, that individual is responsible for taxes on that income. Second, funds that belong to an organization as a whole are now in the bank account of a single project leader. Conservancy solves both those problems: as a tax-exempt charity, the mentor payments are available for organizational use under its tax exemption. Furthermore, Conservancy maintains earmarked funds for each of its projects. Thus, Conservancy keeps the mentor funds for the Free Software project, and the project leaders can later vote to make use of the funds in a manner that helps the project and Conservancy's charitable mission. Often, projects in Conservancy use their mentor funds to send developers to important conferences to speak about the project and recruit new developers and users.
Meanwhile, Google also offers to pay travel expenses for two mentors from each mentoring organization to attend the annual GSoC Mentor Summit (and, this year, it's an even bigger Reunion conference!). Conservancy handles this work on behalf of its member projects in two directions. First, for developers who don't have a credit card or otherwise are unable to pay for their own flight and receive reimbursement later, Conservancy staff book the flights on Conservancy's credit card. For the other travelers, Conservancy handles the reimbursement details. On the back end of all of this, Conservancy handles all the overhead annoyances and issues in requesting the POs from Google, invoicing for the funds, and tracking to ensure payment is made. While the Google staff is incredibly responsive and helpful on these issues, the Googlers need someone on the project's side to take care of the details. That's what Conservancy does.
GSoC coordination is just one of the many things that Conservancy does every day for its member projects. If there's anything other than software development and documentation that you can imagine a project needs, Conservancy does that job for its member projects. This includes not only mundane items such as travel coordination, but also issues as complex as trademark filings and defense, copyright licensing advice and enforcement, governance coordination and mentoring, and fundraising for the projects. Some of Conservancy's member projects have been so successful in Conservancy that they've been able to fund developer salaries — often part-time but occasionally full-time — for years on end to allow them to focus on improving the project's software for the public benefit.
Finally, if your project seeks help with regard to handling its GSoC funds and travel, or anything else mentioned on Conservancy's list of services to member projects, Conservancy is welcoming new applications for membership. Your project could join Conservancy's more than thirty other member projects and receive these wonderful services to help your community grow and focus on its core mission of building software for the public good.
Posted by Bradley M. Kuhn on September 11, 2014
July 15, 2014 by Bradley M. Kuhn
Eleven days ago, Conservancy announced Kallithea. Kallithea is a GPLv3'd system for hosting and managing Mercurial and Git repositories on one's own servers. As Conservancy mentioned in its announcement, Kallithea is indeed based on code released under GPLv3 by RhodeCode GmbH. Below, I describe why Conservancy chose to serve as non-profit home to an obvious fork (as this is the first time Conservancy ever welcomed a fork as a member project).
The primary impetus for Kallithea is that more recent versions of RhodeCode GmbH's codebase contain a very unorthodox and ambiguous license statement, which states:
(1) The Python code and integrated HTML are licensed under the GPLv3 license as is RhodeCode itself.
(2) All other parts of the RhodeCode including, but not limited to the CSS code, images, and design are licensed according to the license purchased.
Simply put, this licensing scheme is — either (a) a GPL violation, (b) an unclear license permission statement under the GPL which leaves the redistributor feeling unclear about their rights, or (c) both.
When members of the Mercurial community first brought this license to Conservancy's attention about ten months ago, the first focus was to form a formal opinion regarding (a). Of course, Conservancy did form such an opinion, and you can probably guess what that is. However, I realized a few weeks later that this analysis really didn't matter in this case; the situation called for a more innovative solution.
Indeed, I recalled at that time the disputes between AT&T and University of California at Berkeley over BSD. In that case, while nearly all of the BSD code was adjudicated as freely licensed, the dispute itself was painful for the BSD community. BSD's development slowed nearly to a standstill for years while the legal disagreement was resolved. Court action — even if you're in the right — isn't always the fastest nor best way to push forward an important Free Software project.
In the case of RhodeCode's releases, there was an obvious and more productive solution. Namely, the 1.7.2 release of RhodeCode's codebase, written primarily by Marcin Kuzminski was fully released under GPLv3-only, and provided an excellent starting point to begin a GPLv3'd fork. Furthermore, some of the improved code in the 2.2.5 era of RhodeCode's codebase were explicitly licensed under GPLv3 by RhodeCode GmbH itself. Finally, many volunteers produced patches for all versions of RhodeCode's codebase and released those patches under GPLv3, too. Thus, there was already a burgeoning GPLv3-friendly community yearning to begin.
Like with any Free Software codebase fork, acrimony and disagreement led to Kallithea's creation. However, as the person who made most of the early changesets for Kallithea, I want to thank RhodeCode GmbH for explicitly releasing some of their work under GPLv3. Even as I hereby reiterate publicly my previously private request that RhodeCode GmbH correct the parts of their licensing scheme that are (at best) problematic, and (at worst) GPL-violating, I also point out this simple fact to those who have been heavily criticizing and admonishing RhodeCode GmbH: the situation could be much worse! RhodeCode could have simply never released any of their code under the GPLv3 in the first place. After all, there are many well-known code hosting sites that refuse to release any of their code (or release only a pittance of small components). By contrast, the GPLv3'd RhodeCode software was nearly a working system that helped bootstrap the Kallithea community. We're grateful for that, and we welcome RhodeCode developers to contribute to Kallithea under GPLv3. We do note, of course, that RhodeCode developers sadly can't incorporate any of our improvements in their codebase, due to their problematic license. However, Conservancy extends again our offer (also made privately last year) to work with RhodeCode GmbH to correct its licensing problems.
Posted by Bradley M. Kuhn on July 15, 2014
July 2, 2014 by Karen Sandler
At the Texas Linux Fest three weeks ago I gave a keynote called “Identity Crisis: Are we who we say we are?”. I talked about the different ways people contribute to free and open source software. I discussed how confusing it can be to understand where the for-profit interests in the software and the nonprofit ideological movement begin and end. The details of my talk were covered on LWN last week. Most importantly, we in this community all face conflicts that can impact the decisions we make and how we are perceived by others. In my talk, I specifically mentioned the IRS, because I sympathize with the difficulty the IRS faces in comprehending what makes a legitimate 501(c)(3) free software public charity. They are new to our complex field. When I was a lawyer at the Software Freedom Law Center I regularly applied for tax exemption for organizations and answered the IRS's questions. I was one of the lawyers who initially worked on Yorba's responses, though I left the work to my capable colleagues when I left to become Executive Director of the GNOME Foundation. Yorba was recently denied tax exempt status, and you can read Jim Nelson's well written post with his reaction to the news.
One point that the IRS examiners all made very clear to me on multiple occasions was that these determinations had no bearing on any existing organizations. This was a question I asked frequently as I was quite troubled by the strange questions they asked and the delays that they were introducing. As a lawyer, I can't give legal advice in a blogpost. I won't opine on what Yorba's letter means for other organizations. But I can take a step back from the rejection and worry less about existing exempt organizations knowing that the rejection does not directly impact us. While the IRS may change its rules with respect to existing nonprofits, the rejection of another organization does not impact them. And a different IRS examiner may have come to a different decision when looking at those facts.
When joining Conservancy a few months back, I looked at our tax exemption application again (the Form 1023 — which I was the primary author of all of those years ago!) and, in particular, the part that described what we intend to do. I was relieved to be reminded that we really described what we do and how we do it accurately. And that the way that we conduct our activities is true to our charitable mission.
I think it can be hard to sort out the corporate interests from the passionate work to make the work better through software freedom. A lot of for-profit companies and trade associations talk a great game about social good. Of course, for-profit companies are committed to shareholder value, and trade associations are required to prioritize a common business interest. Which is why Conservancy as a public charity has an Evaluation Committee that reviews in detail all applications we receive and a staff that oversees the way resources are used, monitoring for corporate control. We have a Conflict of Interest Policy that not only applies to our directors but also to all of our Project Leadership Committees.
must be exclusively devoted to the development of Open Source and Free Software, and that the project must operate in accordance with the with the Conservancy's tax exempt purposes. When projects request admission to the Conservancy, an extensive diligence review is conducted by a committee devoted to this purpose.
Conservancy was founded to be a home for nonprofit free software projects so that they don't have to have lengthy discussion with the IRS, file a lot of paperwork, or take care of a lot of nonprofit corporate minutia, at least not alone. We designed our structure and oversight processes to address many of the worries articulated by the IRS about free software organizations.
It's been nerve racking to watch IRS applications stack up — some have made it through recently and some have not. But I think that if we as a broad community understand our conflicts better (not to mention how a trade association is different from a charity) we'll do a much better job at explaining ourselves to others. If you missed my Texas Linux Fest keynote, please attend my talk at OSCON 2014 later this month, on a similar topic. I'll be sure to leave extra time in the Q&A so we can discuss some of these issues.
Posted by Karen Sandler on July 2, 2014
June 30, 2014 by Tony Sebro
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 repository1.
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.
1Conservancy 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.
Posted by Tony Sebro on June 30, 2014
June 9, 2014 by Bradley M. Kuhn
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” itself0. 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 company1.
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 advises2 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.
0Only 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.
1I've yet to meet any FLOSS developer who has read their own employer's entire patent portfolio.
2Conservancy 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.
Posted by Bradley M. Kuhn on June 9, 2014
March 31, 2014 by Bradley M. Kuhn
Today, Conservancy announced the addition of Karen Sandler to our management team. This addition to Conservancy's staff will greatly improve Conservancy's ability to help Conservancy's many member projects.
This outcome is one I've been working towards for a long time. I've focused for at least a year on fundraising for Conservancy in hopes that we could hire a third full-time staffer. For the last few years, I've been doing basically two full-time jobs, since I've needed to give my personal attention to virtually everything Conservancy does. This obviously doesn't scale, so my focus has been on increasing capacity at Conservancy to serve more projects better.
I (and the entire Board of Directors of Conservancy) have often worried if I were to disappear, leave Conservancy (or otherwise just drop dead), Conservancy might not survive without me. Such heavy reliance on one person is a bug, not a feature, in an organization. That's why I worked so hard to recruit Karen Sandler as Conservancy's new Executive Director. Admittedly, she helped create Conservancy and has been involved since its inception. But, having her full-time on staff is a great step forward: there's no single point of failure anymore.
It's somewhat difficult for me to relinquish some of my personal control over Conservancy. I have been mostly responsible for building Conservancy from a small unstaffed “thin” fiscal sponsor into a “full-service” fiscal sponsor that provides virtually any work that a Free Software project requests. Much of that has been thanks to my work, and it's tough to let someone else take that over.
However, handing off the Executive Director position to Karen specifically made this transition easy. Put simply, I trust Karen, and I recruited her personally to take over (one of) my job(s). She really believes in software freedom in the way that I do, and she's taught me at least half the things I know about non-profit organizational management. We've collaborated on so many projects and have been friends and colleagues — through both rough and easy times — for nearly a decade. While I think I'm justified in saying I did a pretty good job as Conservancy's Executive Director, Karen will do an even better job than I did.
I'm not stepping aside completely from Conservancy management, though. I'm continuing in the role of President and I remain on the Board of Directors. I'll be involved with all strategic decisions for the organization, and I'll be the primary manager for a few of Conservancy's program activities: including at least the non-profit accounting project and Conservancy's license enforcement activities. My primary staff role, however, will now be under the title “Distinguished Technologist” — a title we borrowed from HP. The basic idea behind this job at Conservancy is that my day-to-day work helps the organization understand the technology of Free Software and how it relates to Conservancy's work. As an initial matter, I suspect that my focus for the next few years is going to be the non-profit accounting project, since that's the most urgent place where Free Software is inadequately providing technological solutions for Conservancy's work. (Now, more than ever, I urge you to donate to that campaign, since it will become a major component of funding my day-to-day work. :)
I'm somewhat surprised that, even in the six hours since this announcement, I've already received emails from Conservancy member project representatives worded as if they expect they won't hear from me anymore. While, indeed, I'll cease to be the front-line contact person for issues related to Conservancy's work, Conservancy and its operations will remain my focus. Karen and I plan a collaborative management style for the organization, so I suspect for many things, Karen will brief me about what's going on and will seek my input. That said, I'm looking forward to a time very soon when most Conservancy management decisions won't primarily be mine anymore. I'm grateful for Karen, as I know that the two of us running Conservancy together will make a great working environment for both of us, and I really believe that she and I as a management team are greater than the sum of our parts.
Posted by Bradley M. Kuhn on March 31, 2014
March 31, 2014 by Karen Sandler
Working as the GNOME Foundation Executive Director has been one of the highlights of my career. It has been a pleasure to work with many wonderful people, and we have made fantastic progress over the past three years. GNOME is such an important, vibrant project, and I feel lucky to have been able to play a part in it.
I think I have made some important contributions to the project while I have been Executive Director. I've helped to recruit two new advisory board members, and we recently received a one time donation of considerable size (the donor did not want to be identified). Financially the Foundation is in good shape, and we have run the last three years in the black. We've held some successful funding campaigns, particularly around privacy and accessibility. We have a mind-blowingly fantastic Board of Directors, and the Engagement team is doing amazing work. The GNOME.Asia team is strong, and we've got an influx of people, more so than I've seen in some time.
I hope that I have helped us to get in touch with our values during my time as ED, and I think that GNOME is more aware of its guiding mission than ever before. The ongoing success of the Outreach Program for Women and positive relations with other organizations fighting for software freedom have all helped us to tell a powerful story about who we are and why we matter.
With all these achievements, I think it's time for me to hand the reins over to someone new, who can bring their own personal strengths to the role. It is time for a new challenge for me also, so today I am announcing my new position as the Software Freedom Conservancy Executive Director. As many of you know, I have been volunteering with Conservancy for some time, since I helped found it when I was a lawyer at SFLC. I also can't wait to work closer with Bradley, who has done a bang up job in the role of ED thus far (he’ll be taking on the title of Distinguished Technologist while remaining as President and on the board). It is an important organization where I think I can make a difference, and GNOME is in good hands.
Don't worry though: I'm not leaving GNOME. I will be announcing my candidacy for the board when the call comes out (this is a real exception for me as I've generally declined serving on boards). I will stay on as pro bono counsel, and of course I'll continue volunteering in other ways. The Conservancy has also agreed to partner with GNOME, so that I can help to run the Outreach Program for Women with Marina.
I'm excited for the future. GNOME is already in great hands and I look forward to what the next Foundation Executive can bring to the table. If you know of someone who would be fantastic in this position please let the GNOME board know! I am incredibly proud of what we have achieved in the past three years, and can't wait to see where we go next.
Posted by Karen Sandler on March 31, 2014
December 5, 2013 by Bradley M. Kuhn
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 crossroads0. 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 (
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.
0BTW, 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.
Posted by Bradley M. Kuhn on December 5, 2013
February 28, 2013 by Tony Sebro
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.
Posted by Tony Sebro on February 28, 2013
May 29, 2012 by Bradley M. Kuhn
Conservancy announced today its new coordinated Free Software license compliance effort. As you might guess, in between getting things together for Conservancy conferences, making sure developers get reimbursed on time, and all the other primary work of Conservancy that I'm up to each day, I've been spending what hours that I can coordinating this new effort.
This new program is an outgrowth of the debate that happened over the last few months regarding Conservancy's GPL compliance efforts. Specifically, I noticed that, buried in the FUD over the last four months regarding GPL compliance, there was one key criticism that was valid and couldn't be ignored: Linux copyright holders should be involved in compliance actions on embedded systems. Linux is a central component of such work, and the BusyBox developers agreed wholeheartedly that having some Linux developers involved with compliance would be very helpful. Conservancy has addressed this issue by building a broad coalition of copyright holders in many different projects who seek to work on compliance with Conservancy, including not just Linux and BusyBox, but other projects as well.
I'm looking forward to working collaboratively with copyright holders of many different projects to uphold the rights guaranteed by GPL. I'm also elated at the broad showing of support by other Conservancy projects. In addition to the primary group in the announcement (i.e., copyright holders in BusyBox, Samba and Linux), a total of seven other GPL'd and/or LGPL'd projects have chosen Conservancy to handle compliance efforts. It's clear that Conservancy's compliance efforts are widely supported by many projects.
The funniest part about all this, though, is that while there has been
no end of discussion of Conservancy's and other's compliance efforts
this year, most Free Software users never actually have to deal with
the details of compliance. Requirements of most copyleft licenses like
GPL generally trigger on distribution of the software —
particularly distribution of binaries. Since most users simply receive
distribution of binaries, and run them locally on their own computer,
rarely do they face complex issues of compliance. As the GPLv2
The act of running the Program is not restricted.
Posted by Bradley M. Kuhn on May 29, 2012