Displaying posts by Bradley M. Kuhn
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
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
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
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
February 1, 2012 by Bradley M. Kuhn
As most of those who know me are aware, I've been involved in GPL enforcement for more than 12 years, across three different organizations, the most recent one being here at the Software Freedom Conservancy. Since 2001, I've written dozens of articles, blog posts, and given at least fifty talks and CLE classes about how to do GPL compliance, and how enforcement actions tend to occur.
This weekend at SCALE, I gave a version of a talk I've given many times (also available as an oggcast), which I've usually entitled something like 12 Years of Copyleft Compliance: A Historical Perspective. I decided to retire this talk last weekend at SCALE (in part because it's now coming up on 13 years), but before I put that material aside, I thought I'd write a blog post summarizing the more salient points that I make in that talk.
Indeed, After all these years of speaking about, writing about, and doing GPL enforcement, I'm occasionally surprised at how much confusion still exists about how and why it's done. I've focused solely on doing GPL enforcement via 501(c)(3) not-for-profit entities, which means I do it only in the public good. I hope this blog post will give a sense of how it works and why I do it.
Copyleft Through Copyright
The primary goal of every GPL enforcement action is to gain compliance, which means getting to users complete and corresponding source code so they can copy, share, modify and install improved versions. The GPL itself is a copyright license that does a weird hack on copyright: it uses the copyright rules to turn them around, and require people to share software freely (as in freedom) in exchange for permission to copy, modify and distribute the software. A GPL violation occurs when someone fails to meet the license requirements and thereby infringes copyright. The copyright rules themselves then are the only remedy to enforce the license — requiring that the violator come into compliance with the license if they want permission to continue distribution.
Up until now, almost all the enforcement I've done has been purely under GPL version 2 (GPLv2). GPLv2§4 says that upon violation, the violator loses permission to engage in those activities governed by copyright: including copying, modifying and distributing the software. The only way to get those permissions back is for the copyright holder to grant them back.
Speaking For the Users
Copyleft's unique way of using copyright means the parties who may
enforce are copyright holders (and their designated agents). However,
the victims of the violation are typically thousands of users who have
bought a product that included the GPL'd program. The goal, therefore,
is to get source code that these users can actually use to compile and
install the software. In GPLv2-speak, the goal is to get the all
complete source code, which includes
used to control compilation and installation of the
Releases of complete and corresponding source have been instrumental in inspiring new user-driven software development communities like OpenWRT and SamyGo, both of which built upon source releases that came from prior BusyBox GPL enforcement efforts.
The Standard Requests
The goal of every enforcement action is to yield a license-compliant source release that works for the users. Every enforcement action opens as a conversation, asking the violator to meet a few simple requests so that their permission to engage in copyright-governed activity can be restored, and they can go about their new business as a fine, upstanding, compliant Free Software redistributor. The typical requests are:
- Compliance with all Open Source and Free Software licenses in
I started using this request regularly around 2002 because violators express a concern that, if they come into compliance due to my efforts, what stops others from coming to complain, in sequence, and wasting their time? I suggested that if they came into compliance all at once, on all FLOSS licenses involved, it would be easy for me to be on their side, should someone else complain. Namely, I'd come to their defense and say:
Yes, they were out of compliance, but we've checked everything and they're now in compliance throughout this product. Those who are now complaining are being unfair, since — while this violator had trouble initially — their compliance with all FLOSS licenses is now adequate.
Of course, the detailed license requirements are different for different licenses, so I've had to become an expert on the specific requirements of all FLOSS licenses over the years. For example, for permissive, BSD-like licenses, the only compliance required is typically that copyright notices be displayed appropriately on proprietarized versions. Meanwhile, the LGPL permits some types of proprietary combinations, but not others. GPLv2 and GPLv3, of course, have different requirements when it gets down to some details. The goal is to make sure that whatever each license requires is what's being done for the program under that license.
Meanwhile, particularly with embedded systems, requiring compliance on everything is basically a de-facto necessity anyway. Most embedded firmwares are built with a single build system (or, a set of steps that expect all relevant sources to be present), and as such, asking for the GPLv2-required
scripts used to control compilation and installation of the executablefor one program means asking for them for other programs too, since it's the same scripts.
- Appoint a Compliance Officer.
This is a requirement that actually predates my involvement in enforcement. I believe it was instituted at other organizations back in the 1990s. The goal is simple: have a single point of contact who can be reached regarding any future violations.
The goal, as always, is to help a violator become a productive member of the Free Software business community. Ideally, future violation matters should never be escalated very much: the company should have a person that has some expertise about GPL compliance who can work with anyone who might have concerns about any later product.
- Pay Our Cost of Bringing You Into Compliance.
This was the toughest requirement for me to institute, and I struggled for years about whether it was the right thing to do. I avoided it until someone pointed out to me:
If you're doing GPL enforcement for a non-profit, who should pay the cost of doing enforcement: the folks who send you charitable donations to support your other non-compliance work, or the violators who actually violated the license? Indeed, those who donate probably always comply with GPL themselves, so if violators aren't charged the cost of enforcement, compliant people end up subsidizing violations with their donations.
Ultimately, that was a compelling enough argument for me, but there's one other argument: there must be a deterrent. If the cost of violating the GPL is: “you must merely come into compliance when you're caught violating”, then very few companies would comply voluntarily. How many people would always violate the automobile speed limits if, when the driver is pulled over for speeding, all that ever happened was a stern warning?
A few sometimes ask:
well, where does the money go?. This question is why I think it's essential for GPL enforcement to be done by a 501(c)(3) not-for-profit entity like Conservancy. As I wrote in my previous Conservancy blog post, Conservancy's financial documents are publicly disclosed. So, you want to know the details of the enforcement money from FY 2010? Download Conservancy's FY 2010 Form 990, and take a look at Line 4(c) on page 2, Line 2(b) on page 9, and Line 11(b) on page 10. It's as simple as that.
Conservancy's Enforcement Plans
Of course, I encourage everyone to read the rest of the Form 990 too, and note in particular that GPL enforcement is only third on the list of major activities at Conservancy. I've no interest in making license enforcement the primary activity of Conservancy — indeed, it's but one item on Conservancy's extensive list of services, and Conservancy has 27 (and growing) projects to care for. Many of those projects are GPL'd and LGPL'd, and many of them want Conservancy to handle their enforcement, but that work is always balanced with all the other work going on at this thinly staffed organization.
I strongly expect that Free Software license compliance and enforcement
will always be a part of my work. I once heard Larry Wall, founder of
Perl, say (when I was still merely a
Computer Science graduate student):
You can never entirely stop being
what you once were. That's why it's important to be the right person
today, and not put it off till tomorrow. Ever since I heard him say
that, I've held it as a fundamental tenet of what I do in the Free
Software community. I believe GPL enforcement is right and necessary
for the advancement of software freedom. So, I'm glad for the
enforcement I've done, and I'm glad to continue doing GPL enforcement
for as long as projects come to me and ask me to take care of it for
them. Like everything else at Conservancy: I'm glad to do the boring
work so Free Software developers can focus on writing code. GPL
enforcement surely qualifies there.
I admit, though, that I do find litigation particularly annoying, time-consuming, and litigation also makes GPL compliance take longer than it should. That's why litigation has always been a last resort, and that 99.999% of GPL enforcement matters get resolved without a lawsuit. Lawsuits are only an option, in my view, when a violation is egregious, and multiple attempts to begin a friendly conversation with the violator are consistently ignored. Every lawsuit I've been involved with met these criteria. I hope no violation matters ever meet them again, but that depends on how well the violators respond when someone asks them for the complete and corresponding source code for the GPL'd and LGPL'd components in the product.
I hope that someday, everyone just complies voluntarily with the GPL, so I can go do other things — I used to be a software developer, once upon a time, and I'd love to do that again. But, in the meantime, I'm here to enforce the GPL, to defend software freedom.
Posted by Bradley M. Kuhn on February 1, 2012
January 16, 2012 by Bradley M. Kuhn
For the last few months, I've had the same primary action item on my agenda every single day: finish Conservancy's FY 2010 audit and Form 990. Those who exchange email with me regularly have probably noticed a slowly increasing lag because of this. Fortunately, as for this past Saturday, this work is finally done. Conservancy has publicly posted our FY 2010 Form 990, FY 2010 Independent Auditor's report and our FY 2010 NYS CHAR-500. I know these documents might seem as boring as reading your own tax filings, but I hope in this blog post to convince you that Form 990s are worth reading, by drawing attention to the interesting parts of Conservancy's filings.
What's a Fiscal Year (FY)?
When I first started working in non-profit management years ago, it took me a while to get used to the idea of a fiscal year (often abbreviated FY). The concept, however, is relatively simple. Conservancy was founded in March 2006. As such, Conservancy's first year of operation ended on 28 February 2007, and every year thereafter, Conservancy completes another year of operation on the last day of February.
Therefore, when you take a look at Conservancy's 2010 Form 990, you'll find that the period described is 1 March 2010 until 28 February 2011. So, when you analyze the documents, you have to put your mindset into that period.
What's a Form 990, and Why Is It Public?
I often point out that 501(c)(3) non-profit charities are a form of a government grant. Think of it this way: 501(c)(3)'s not only pay no taxes on any of their income, but also, donors who give to a 501(c)(3) don't (usually) have to pay taxes on the money they give. The USA government (and by extension, the public), in essence, is subsidizing these organizations in two different ways: the government collects no tax money from these organizations, and the donors don't pay any taxes on their donations.
The government permits this because organizations like Conservancy must meet a high burden: they must advance the public good through pursuit of their mission. Conservancy does this by facilitating, fostering, promoting, developing, and defending Free, Libre and Open Source Software (FLOSS) for the general public.
To make sure organizations carry out their mission for the public good, and to allow the public itself to verify this occurs, the USA Internal Revenue Service (IRS) requires that, each year, every 501(c)(3) organization file the Form 990, which outlines all the funds received and spent by the organization, and how the organization used those funds to promote its mission. My hope is that if you read the rest of this blog post alongside Conservancy's Form 990 and Auditor's Report, you might be able to better use it as a tool to figure out what Conservancy was up to between the dates of 1 March 2010 and 28 February 2011.
Quick View of Mission, Revenue and Expenses
The first page of the Form 990 has a brief statement of the mission of the organization, and presents the fiscal overview. The most interesting lines related to income are lines 8 and 9, which contain the total contributions, and total service revenue. For a 501(c)(3), “contributions” are gifts and donations given to the organization by donors. That's the type of income with which those who give to non-profits are most familiar.
Program service revenue, which is also sometimes called “related business income”, refers to income that an organization receives while pursuing its mission. Conservancy's most common program service revenue is registration fees for conferences. Those who attend the conference get something in return (e.g., getting to see the talks live), but these conferences are still within Conservancy's mission (e.g., educating the public about Open Source and Free Software). Thus, the IRS considers the income related to Conservancy's mission.
The interesting lines on expenses are probably lines 15 and 17. Line 15 is salaries, which I'll talk about later, and line 17 is all the other expenses. The best places to get more information on what goes into this line is to jump to Part IX of the Form 990 (page 10), or to look at Page 5 (PDF page 6) of the Independent Auditor's Report.
Expenses By Mission Work
On Page 2 of the Form 990, you'll find Part III. This is perhaps the most interesting part. Specifically, it matches up specific expense totals with parts of Conservancy's mission. Included are texts describing the work that was done with those funds. I think this page is particular interesting, because it provides an easy overview of specific mission work and how much the organization spent on that specific work. In other words, it's a cross-section of the expenses totaled against specific mission work, rather than types of expenses (the latter of which is the default elsewhere on the Form 99).
The Public Support Test
In Schedule A, Part II of the Form 990 (PDF page 14), you'll find the public support test. Since this is Conservancy's fifth year of operation, for the first time, Conservancy must take a public support test. There are various ways of calculating the public support test. Conservancy used the 33⅓% test, which requires that at least 33⅓% of the organization's support come from the public. Conservancy's public support percentage is 45.3%.
Earmarked Funds Summary
I've focused here mostly on the Form 990. However, it's worth noting that FY 2010 was the first year in which Conservancy was required to have an independent audit. This is a New York State Requirement (you can see the detail of this requirements on page 4 of the CHAR-500), but even when it's not mandated, it's good for non-profits to have an independent audit anyway. Despite the amazing amount of work our first audit took (it'll get easier in future years, fortunately, now that Conservancy is used to it), I'm very glad that NYS required us to do it, as there's always the temptation to avoid something that's difficult and not mandatory.
Anyway, the most interesting page of the audit's report, in my view, is page 6 (PDF page 7), which shows the exact totals of all earmarked project funds in Conservancy. Individual Conservancy member projects will probably like to be able to see a third-party confirmation on the amount that was given, spent, and remains for their projects.
Yes, You Can See How Much I'm Paid
Part of public filings include the salaries paid to officers, directors, and key employees of the organization. Part VII of the Form 990 (Page 7) has these details. As you can see, I was the only person that Conservancy paid in FY 2010. When you look at the numbers in this section, note that my role changed over the course of the fiscal year: From 2010-03-01 through 2010-09-30, I was a nights/weekends part-time volunteer. From 2010-10-01 to 2010-12-31, I was a full-time volunteer. For the last two months of the fiscal year, from 2011-01-01 until 2011-02-28, I was a full-time employee.
Feel Free to Ask Me Questions
I've started a thread on identi.ca to discuss Conservancy's Form 990. Feel free to ask me any questions that you have there.
Posted by Bradley M. Kuhn on January 16, 2012
November 28, 2011 by Bradley M. Kuhn
Much was written last week that speculated about the role of foundations and the always-changing ways that developers write Free Software. I must respectfully point out that I believe this discussion doesn't address the key purpose of doing Free Software work as part of a non-profit organization.
Conservancy always avoids making any technical recommendations. Indeed, Conservancy counts among its members Darcs, Git and Mercurial, all of whom likely disagree on the preferred distributed version control system. Conservancy, for its part, doesn't have a recommended version control system, nor a recommended hosting site, nor anything else like that. I even grit my teeth and just live with it when Conservancy's member projects choose Github over Gitorious (since the latter is Free Software itself and the former is not — an issue that concerns me deeply).
In short, Conservancy's job isn't to tell projects how to do what they do best: write and develop Free Software. Of course, our members must license their software under a license that's both FSF- and OSI-approved, and all official project activities (including development) must fit Conservancy's not-for-profit mission. But beyond oversight on that issue, Conservancy doesn't interfere with the development of our projects' software.
Instead, Conservancy handles all the aspects of running a non-profit software project that don't involve actually developing software. Conservancy's service plan includes many things, from handling donations, reimbursing developers for conference travel, to holding domain names, copyrights, and trademarks, to enforcing those copyrights and trademarks, to basic legal services. These items are the role for the non-profit organization in the life of a Free Software project. Conservancy's goal is to ensure that the software project continues to improve and benefit the public good, and to handle all the mundane aspects of non-profit activity.
Nevertheless, Conservancy's way of operating doesn't fit every project's culture. In the past, I've even recommended to Conservancy applicants that Apache Software Foundation, Free Software Foundation or Software in the Public Interest was a better home for their project, merely because the project seemed to have a culture that fit better with those organizations.
Upon finding the right cultural fit, a non-profit home can promote the
advancement of a Free Software project in ways the project can't do
merely as a band of part-time volunteer developers. By contrast to
those who are asking whether these non-profits
still make sense,
I argue that more than ever, developers need as much time as they
can spare to keep up with the rapid changes in technology and community
development methodologies. A non-profit home can take care of the
other, non-software-development tasks, leaving the projects' volunteers
to focus on what they do best.
As for adherence to the rules, while Conservancy is liberal on rules related to development methodologies, we remain somewhat conservative on the areas of the organization's expertise. Namely, Conservancy carefully oversees the financial spending and asset management of Conservancy's projects to ensure they continue to operate in a not-for-profit way to advance the public good. This is the most important standing agenda item on my daily schedule, and I believe that's the center of my job in providing services to our member projects. While I once was a software developer (and I sometimes can't resist giving my technical opinion to one of Conservancy's member projects), I constantly focus my role on the stuff that developers hate doing, so that they keep doing the work the love that helps the whole community.
Posted by Bradley M. Kuhn on November 28, 2011
January 2, 2011 by Bradley M. Kuhn
I had hoped to blog more regularly about my work at Conservancy, and hopefully I'll do better in the coming year. But now seems a good time to summarize what has happened with Conservancy since I started my full-time volunteer stint as Executive Director from 2010-10-01 until 2010-12-31.
We excitedly announced in the last few months two new Conservancy member projects, PyPy and Git. Thinking of PyPy connects me back to my roots in Computer Science: in graduate school, I focused on research about programming language infrastructure and, in particular, virtual machines and language runtimes. PyPy is a project that connects Conservancy to lots of exciting programming language research work of that nature, and I'm glad they've joined.
For its part, Git rounds out a group of three DVCS projects that are now Conservancy members; Conservancy is now the home of Darcs, Git, and Mercurial. Amusingly, when I reminded the Git developers when they applied that their “competition” were members, the Git developers told me that they were inspired to apply because these other DVCS' had been happy in Conservancy. That's a reminder that the software freedom community remains a place where projects — even that might seem on the surface as competitors — seek to get along and work together whenever possible. I'm glad Conservancy now hosts all these projects together.
Meanwhile, I remain in active discussions with five projects that have been offered membership in Conservancy. As I always tell new projects, joining Conservancy is a big step for a project, so it often takes time for communities to discuss the details of Conservancy's Fiscal Sponsorship Agreement. It may be some time before these five projects join, and perhaps they'll ultimately decide not to join. However, I'll continue to help them make the right decision for their project, even if joining a different fiscal sponsor (or not joining one at all) is the ultimately right choice.
Also, about once every two weeks, another inquiry about joining Conservancy comes in. We won't be able to accept all the projects that are interested, but hopefully many can become members of Conservancy.
In the late fall, I finished up Conservancy's 2010 filings. Annual filings for a non-profit can be an administrative rat-hole at times, but the level of transparency they create for an organization makes them worth it. Conservancy's FY 2009 Federal Form 990 and FY 2009 New York CHAR-500 are up on Conservancy's filing page. I always make the filings available on our own website; I wish other non-profits would do this. It's so annoying to have to go to a third-party source to grab these documents. (Although New York State, to its credit, makes all the NY NPO filings available on its website.)
Conservancy filed a Form 990-EZ in FY 2009. If you take a look, I'd encourage you to direct the most attention to Part III (which is on the top of page 2) to see most of Conservancy's program activities between 2008-03-01 to 2009-02-28.
In FY 2010, Conservancy will move from the New York State requirement of “limited financial review” to “full audit“ (see page 4 of the CHAR-500 for the level requirements). Conservancy had so little funds in FY 2007 that it wasn't required to file a Form 990 at all. Now, just three years later, there is enough revenue to warrant a full audit. However, I've already begun preparing myself for all the administrative work that will entail.
Project Growth and Funding
Those increases in revenue are related to growth in many of Conservancy's projects. 2010 marked the beginning of the first full-time funding of a developer by Conservancy. Specifically, since June, Matt Mackall has been funded through directed donations to Conservancy to work full-time on Mercurial. Matt blogs once a month (under topic of Mercurial Fellowship Update) about his work, but, more directly, the hundreds of changesets that Matt's committed really show the advantages of funding projects through Conservancy.
Conservancy is also collecting donations and managing funding for various part-time development initiatives by many developers. Developers of jQuery, Sugar Labs, and Twisted have all recently received regular development funding through Conservancy. An important part of my job is making sure these developers receive funding and report the work clearly and fully to the community of donors (and the general public) that fund this work.
But, as usual with Conservancy, it's handling of the “many little things” for projects that make a big difference and sometimes takes the most time. In late 2010, Conservancy handled funding for Code Sprints and conferences for the Mercurial, Darcs, and jQuery. In addition, jQuery held a conference in Boston in October, for which Conservancy handled all the financial details. I was fortunate to be able to attend the conference and meet many of the jQuery developers in person for the first time. Wine also held their annual conference in November 2010, and Conservancy handled the venue details and reimbursements to many of travelers to the conference.
Also, as always, Conservancy project contributors regularly attend other conferences related to their projects. At least a few times a month, Conservancy reimburses developers for travel to speak and attend important conferences related to their projects.
Google Summer of Code
Since its inception, Google's Summer of Code (SoC) program has been one of the most important philanthropy programs for Open Source and Free Software projects. In 2010, eight Conservancy projects (and 5% of the entire SoC program) participated in SoC. The SoC program funds college students for the summer to contribute to the projects, and an experienced contributor to project mentors each student. A $500 stipend is paid to the non-profit organization of the project for each project contributor who mentors a student.
Furthermore, there's an annual conference, in October, of all the mentors, with travel funded by Google. This is a really valuable conference, since it's one of the few places where very disparate Free Software projects that usually wouldn't interact can meet up in one place. I attended this year's Soc Mentor Summit and hope to attend again next year.
I'm really going to be urging all Conservancy's projects to take advantage of the SoC program in 2011. The level of funding given out by Google for this program is higher than any other open-application funding program for FLOSS. While Google's selfish motives are clear (the program presumably helps them recruit young programmers to hire), the benefit to Free Software community of the program can nevertheless not be ignored.
GPL Enforcement, primarily for our BusyBox member project, remains an active focus of Conservancy. Work regarding the lawsuit continues. It's been more than a year since Conservancy filed a lawsuit against fourteen defendants who manufacture embedded devices that included BusyBox without source nor an offer for source. Some of those have come into compliance with the GPL and settled, but a number remain and are out of compliance; our litigation efforts continue. Usually, our lawyers encourage us not to comment on ongoing litigation, but we did put up a news item in August when the Court granted Conservancy a default judgment against one of the defendants, Westinghouse.
Meanwhile, in the coming year, Conservancy hopes to expand efforts to enforce the GPL. New violation reports on BusyBox arrive almost daily that need attention.
More Frequent Blogging
As noted at the start of this post, my hope is to update Conservancy's blog more regularly with information about our activities.
Posted by Bradley M. Kuhn on January 2, 2011