Happy New Year from Conservancy and Video from Mike Linksvayer
byon December 31, 2014
As we wrap up 2014 we are grateful for all of the fantastic participation from our hundreds of volunteers across our many member projects.
The best thing about launching our Supporter program is the all of the positive feedback we've gotten. We are realizing that we need to draw attention to all of the work we and our projects are doing and invite you to help us do that!
Along these lines, we're pleased to publish this video from Mike Linksvayer. Mike is on Conservancy's board of directors and is a member of our evaluation committee. You can watch the video to hear why he volunteers his time with Conservancy and why he has also chosen to become a Conservancy Supporter.
Many thanks to Bastian Ilsø for helping us to put this together and to Javier Suarez (jahzzar) for freely licensing his song, "I need", under Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0), which we used in the video.
We're getting excited about all of the things we have in the works for 2015! Please become a Conservancy Supporter to help us continue our mission. Have a great holiday and all the best in 2015.
Thinking about the Importance of a Membership Program
byon December 24, 2014
As anyone who's been following Conservancy's news knows, we've been working with the rest of Conservancy's staff on launching and promoting a Supporter Program, a way for individuals to support Conservancy though membership fees (we're avoiding the term "member" because Conservancy's members are our member projects).
We launched this program for a number of reasons. Part of this, of course, is financial. While we do receive a portion of the revenue donated to our projects, we keep that number low enough that it doesn't even pay for a single staff member. We need to raise money in order to be able to keep the full support of our projects that we have in place now. I sometimes refer to our model as "fiscal sponsorship plus" because we do a lot more for our projects than many of the other organizations in free and open source software (by design - it's useful to have different orgs doing different things!). But that level of support requires significant resources and we don't want to pass that burden onto our member projects if we can possibly help it.
We do fundraise from companies (and if you think your company can sponsor Conservancy please get in touch!) but there can be trade offs with this as an overall model. Bradley wrote an excellent blogpost about this already. Because we are focused on what's good for the community and not necessarily what's good for companies (though our interests are often aligned), we need a strong membership base to help balance things out. Trade associations have a much easier time fundraising from companies for these reasons but we as a community get so much more out of a public facing org.
We also realized that we've really been focused on promoting our projects and not necessarily Conservancy as a whole. While everyone has heard of Git, Samba, Wine, and Inkscape (the list goes on, it's very hard to chose projects to single out when they're all so great) I think a lot of people don't even know that we exist or what we do. By launching this program, we have a lot more excuses to tell people about our activities and why we matter. I had a great time writing our fundraising page, and distilling this into a short explanation.
That said a lot of people *do* already know about Conservancy and why it's an important organization. I've been so excited at the sign ups we've had for Conservancy's Supporter program so far and I realized something today that floored me - the list of Supporters to date is in large part comprised of experts in the field. I was looking at the list of Supporter names and it read like something of a "who's who". We could make a killer conference if we gathered those people to speak! It gave me confidence in our program and in our organization generally. If these people who I deeply respect think that Conservancy is worth contributing to, then we must be on to something good. I expect it will take us years to build up the membership base we want but it's fitting to have so many leaders signing up and publicly acknowledging us. I'm hoping we will be able to grow the program a lot in the near future and we've got a lot of exciting stuff we're working on that I can't wait to talk about.
I hope you have a great holiday season! Please consider joining the ranks of Conservancy Supporters and generally supporting the charitable organizations in free software (specific props to GNOME and the FSF)!
Understanding Conservancy Through the GSoC Lens
byon September 11, 2014
[ 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.
Why Conservancy's Kallithea Project Exists
byon July 15, 2014
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.