The new 501(c)(3) and the future of free software in the United States

yorba_logo_big.pngNote: I’m a software developer, not a lawyer.  I suspect I’m not the only coder whose eyes roll to the back of their head when legal or tax matters are discussed.

However, if you’re involved in the free software movement—especially in the United States—you may want to read through this, as long as it may seem.  It appears that the United States’ Internal Revenue Service has strongly shifted its views of free and open-source software, and to the detriment of the movement, in my opinion.

What follows should not be construed as legal or tax advice or professional interpretation of those laws.  If you have questions, please consult a professional.

Earlier this month the Yorba Foundation received a formal notice from the Internal Revenue Service (IRS) denying Yorba 501(c)(3) tax-exempt status.  It’s possible this is nothing to be concerned with (at least, not unless you’re a part of Yorba).  Reading their response, I believe this denial is actually a cause for concern for free software groups within the United States, and perhaps abroad.

A quick primer

501(c) is the section of the United States’ tax code dealing with tax-exempt organizations.  The third type (i.e. 501(c)(3)) are for organizations that are “organized and operated exclusively for one or more of the following purposes: religious, charitable, scientific, testing for public safety, literary, educational, fostering national or international amateur sports competition, or the prevention of cruelty to children or animals”.  IRS publication 557 gives the full run-down.  Wikipedia has a good explanation of 501(c) and 501(c)(3) as well.

Free/libre/open software organizations such as the GNOME Foundation, Mozilla Foundation, Apache Software Foundation, Linux Kernel Organization, WordPress Foundation, Django Software Foundation and more operate under a 501(c)(3) status.

One misconception is that 501(c)(3)’s don’t pay any taxes.  501(c) only provides exemption from Federal income tax.  Most states honor Federal exemption and will exempt those organization from state income taxes as well.  The organization must still fulfill other tax obligations (such as payroll, unemployment, and sales taxes).

The advantages of 501(c)(3) go beyond income tax exemption.  The status also allows donations to the organization to be treated as a tax exemption by the donor.  For those of you giving $25 or $50 that’s not much of an advantage (although those donations are most certainly appreciated!).  However, Yorba has seen donors offering potentially thousands of dollars back away because of our lack of 501(c)(3) status.  Many large charitable foundations and grants will only consider donating to groups with a 501(c)(3) status.

Last year there was a bit of a dust-up—a scandal to some, a distraction to others, depending on their politics—when many right-wing nonprofit organizations in the United States began complaining they were being unfairly targeted by the IRS.  Media inquiries determined IRS examiners were given “BOLOs” (Be On The Lookout) for certain keywords in 501(c) applications, including “Open Source Software”.  Last year I spoke with Wired about the issue.

The question of the IRS targeting certain groups has not died off, although the connection to free software has fallen off the radar screen.

Yorba’s application

The Yorba Foundation applied for 501(c)(3) in December 2009.  We applied as a charitable, scientific, and educational organization.  Remember that we only needed to meet the criteria for one of those to receive 501(c)(3) status.

We received two requests for clarification, one on June 23, 2010, and another on September 14, 2010, which we responded to in full.  We received a notice on October 5, 2011 that our application was still being processed.

The requests for clarification contained mostly non-surprising questions.  For example, “Describe whether your organization provides any goods or services for a fee.”  (We don’t.)  Some were odd: “Will any of your directors or employees reside at your facility [i.e. our office]?”  (Ah…no.)

Other than those three notices and a couple of phone calls with our representatives at the Software Freedom Law Center, that was it.

The final determination letter, the denial of exemption, is dated May 22, 2014, almost four and a half years after we first applied.  That strikes me as excessive, particularly since, as the above list of open-source foundations suggests, ample positive precedent existed.

The new 501(c)(3)

What I find alarming are some of the statements made by the IRS in their denial letter.  This is what could have a direct impact on the free software movement, at least here in the United States.  What follows are the most hair-raising statements in their denial letter and my interpretation and response (IRS’ statements are in italics):

You have a substantial nonexempt purpose because you develop software published under open source compatible licenses that authorize use by any person for any purpose, including nonexempt purposes such as commercial, recreational, or personal purposes, including campaign intervention and lobbying.

(To help with the legalese, remember that Yorba is applying as a tax-exempt entity, and so nonexempt purposes are those that are not charitable, scientific, etc.)

The IRS reasons that since Yorba’s open source software may be used for any purpose, Yorba is not a charity.  Consider all the for-profit and non-charitable ways the Apache server is used; I’d still argue Apache is a charitable organization.  (What else could it be?)

There’s a charitable organization here in San Francisco that plants trees throughout the city for the benefit of all.  If one of their tree’s shade falls on a cafe table and cools the cafe’s patrons as they enjoy their espressos, does that mean the tree-planting organization is no longer a charity?

Mere publishing under open source licenses for all to use does not show that the poor and underprivileged actually use the Tools. … You do not limit your distribution and do not know who uses the Tools much less if they use them for artistic purposes. … you do not know who uses the Tools much less what kind of content they create with the Tools.

(Here and elsewhere, “Tools” is IRS shorthand for Yorba’s software.)

The IRS is correct that Yorba does not know who is using our software or for what purposes, nor does Yorba limit the distribution of our software to a particular charitable segment of society.  But when I spend three milliseconds imagining how that would work, I shudder.

What’s more, these objections clash with three of the Four Software Freedoms and copyleft in general:

  • The freedom to run the program as you wish, for any purpose (freedom 0).
  • The freedom to redistribute copies so you can help your neighbor (freedom 2).
  • The freedom to distribute copies of your modified versions to others (freedom 3).

In other words, we (and, presumably, everyone else) cannot license our software with a GNU license and meet the IRS’ requirements of a charitable organization.

Freedom 1 (“The freedom to study how the program works”) isn’t attacked as non-charitable by the IRS, but it is defined as non-educational:

The purpose of source code is so that people can modify the code and compile it into object code that controls a computer to perform tasks.  Anything learned by people studying the source code is incidental.

Which is like saying the only point of an algorithm is its final answer, and so Einstein publishing E=mc2 offered nothing more to the world than a way to accurately measure the amount of energy in, say, a cube of sugar or a block of cheese.  Any deeper learning is incidental.

I can directly trace the start of my year career in software development to the first BASIC programs I encountered as a 9 year-old.  I pressed the Break key, typed LIST, and learned.  I didn’t receive any formal education in programming until my junior year in high school.  I know for a fact I’m not the only one.

How many coders learned from studying and modifying existing code?  Think about UNIX, BASIC, HyperCard, and just about every scripting language devised.  The availability of source code and its relation to learning how to program is so fundamentally correlated, it’s zen.

The development and distribution of software is not a public work even if published under open source or creative commons compatible licenses because software is not a facility ordinarily provided to the community at public expense. … In the face of such consistency of the key characteristics over four centuries we are constrained from extending the term public works to encompass intangibles such as software.

The “four centuries” of terminology being referenced here is that software is not a lake, dam, bridge, highway, etc.  In other words, because 17th century English Common Law doesn’t mention IMAP email clients or JPEG decoding, software is not a public work.

Sarcasm aside, these statements are annoying because they create a kind of Möbius strip Catch-22 with the earlier statements I quoted.  Since Yorba makes our software widely available to the public at large, we’re not truly charitable; but since software doesn’t meet the IRS’ definition of “public works”, making our software widely available is not charitably serving the public at large.

And then there’s this humdinger, which sounds like it came from a Douglas Adams novel:

…public works must serve a community.  Open source licensing ensures the Tools are accessible to the world.  We have not found any authority for the proposition that the world is a community within the meaning of § 501(c)(3).

There’s something delicious about the phrase “We have not found any  authority for the proposition that the world is a community.”  Mahatma Gandhi, Jesus Christ, and Martin Luther King Jr. are three I can name off the top of my head.

You are the copyright holder of some Tools code.  Private persons are the copyright holders of the portion of Tools code you do not own. … Even though you are the copyright holder to a portion of Tools code, the portion of Tools code owned by private persons cannot be a public work within the meaning of § 501(c)(3).

I believe what the IRS is inadvertently requiring here is copyright assignment.  Since Yorba does not require copyright assignment from our contributors, the IRS appears to think our software cannot be a public work.

Copyright assignment is controversial in the free software community.  (A nice overview can be found here; the controversy up-close and in-person can be found here and here.)

I hope I’m wrong about this.  I doubt they’re going to start enforcing this in the future for organizations that already enjoy exemption.  If they do, it will be a royal mess for those projects having to contact every author of every non-trivial contribution and get them to sign over their rights.  This is all a big if, of course.

Where Yorba stands

This does not spell disaster for Yorba.  The Foundation’s existence does not hinge on 501(c)(3) status.  It certainly would’ve been advantageous if the IRS had granted it.  It certainly would’ve been a better world if the IRS hadn’t waited four and a half years to inform us of their decision.

We have no plans to appeal their decision.  It looks to be an arduous legal battle we cannot afford.

I hope other open source projects will take note of this decision, especially projects considering applying for 501(c) status.

For those who think I’m being alarmist, I encourage them to consider the above statements by the IRS and ask themselves how the good projects already granted 501(c)(3) would’ve stacked up under the IRS’ new parameters.

I also recognize that I’m cherry-picking statements from the IRS for my commentary.  I selected the ones I thought would be of most interest to the community.

The full PDF of the IRS’ decision can be found here.

Inline composer comes to Geary

And you think you get difficult email.
And you think you get difficult email.

A year in the making, I’m pleased to announce that we’ve landed a major new feature in Geary: an inline email composer.  What’s that mean?  In short, when you go to reply to a conversation, instead of a new window popping up on the screen, the composer is embedded in the window right below the message you’re replying to.  Want a separate window?  Just press the Detach button and you’re writing emails just like Geary used to work.  Old School, as the kids say.

This great addition to Geary is thanks to the hard and tireless work of Robert Schroll who put this together on a private branch and has been maintaining it for some time now.  Serendipity led Robert to San Francisco last week, and he generously spent a good chunk of his time here working with me to finalize snapping the pieces of the puzzle together and polishing the chrome.  It’s pretty sweet, I must say.

The inline composer is only available in git master at the moment.  It’ll be available for general release in our next stable version, Geary 0.8.  In the meantime, if you’re so bold and want to give it a test drive, you can build Geary from master.  Or, if you’re running Ubuntu, install it from Yorba’s Daily Build PPA (but be sure to read the warnings on that page!)  The more eyeballs the better.  If you find a bug, please let us know.

Geary bounties galore

A number of Geary bounties have popped up in recent weeks that our users may want to know about.  Bounties represent reward money for coder(s) who successfully land their improvements in the program.  (Yorba created a bounty a few months back for Geary, you can read about it here.)  Some of the new Geary bounties include:

“Add option to sort folder into read and unread” – There’s a number of ways to approach this; I would be happy to simply have a switch or toggle button that filtered read conversations from the list, leaving only unread to peruse.

“Notify of new messages at startup” – This is a long-standing feature request and it would be great to get this landed in Geary.  There’s a number of fancy ways this could be achieved, but I think the easiest way to approach this would be for Geary to be launched at login time with a magic command-line option that hides the main window.  As new messages come in, notifications are displayed.  If the user clicks on the Geary icon or the notification bubble, the hidden window is displayed.  The added complication here is that closing the window should merely hide it, while the Quit option would, in fact, cause Geary to exit.

“Ubuntu online accounts integration” – The basic thrust of this problem is to fetch account information from UOA and start pulling down mail with no user interaction (other than starting Geary, of course).

With all bounties, please be sure to read over the linked Bugzilla ticket and understand all the in’s and out’s of the task.  Tickets are also the best place to ask questions for the Geary team.  We’re here to help!

Some of these bounties are courtesy our good friends at elementary while some have been initiated by independent users who simply would like to see Geary improved.  Follow the above links to see how much money is up for grabs on each.

If you see a feature you really, really want to see added to Geary, consider how much it’s worth to you and pledge that amount.  High dollar values encourage attention from developers and gets traction and movement.  And if one of the above doesn’t tickle your fancy, there’s a whole host of other outstanding bugs that are listed but have no money behind them; pledge and get them started!

As always, Yorba developers will not collect bounties, but we certainly encourage everyone out there to think about (and act upon!) how they can contribute toward improvements.

Introducing California, a new GNOME 3 calendar

Eureka!

When Yorba announced Geary some time back, one question we were often asked was, Where’s the calendar?  When we replied that Geary was not going to have a calendar — that it was an email client, nothing more — the question often turned into a request: Will you make a calendar app then?

We saw it coming.  When we were planning Geary, we talked internally about calendaring and its close relationship to email.  We agreed that, like our approach to Geary, that was best handled by a dedicated application rather than bolted-on as yet another feature.

So it’s not terribly surprising for me to announce that Yorba has begun work on a new calendar application for GNOME 3: California.  The philosophy that guided our development of Geary is present in California as well: simple to set up, quick and easy to use, focused on its particular task but flexible for each person’s workflow.  The first commit was in January and work has progressed far enough that we’re ready to start talking about it.

Eureka!
Eureka!

The current implementation relies on Evolution Data Server (EDS) for all backend calendar operations, but the code is architected so other backends (such as GData) can be added later, perhaps even broken out as plugins.  The design is to use most of the modern GTK widgets and design goals, including GtkHeaderBar.  A lot of features are still unimplemented, of course, but development is continuing.

For more information and links, visit California’s home page.  Our ticket list is a good way to see what’s on the immediate horizon and report bugs and feature requests.  You can also subscribe to the California mailing list to discuss the application’s current state and future.

Be aware that in its current implementation you’ll need another EDS client (i.e. Evolution) to add and configure the calendars visible to California, but we hope to soon have that implemented as well.  And, no, Geary and California don’t talk yet, but that’s in the works.

What about GNOME Calendar?

One question we’ve already been asked is, why not work on GNOME Calendar?  We have a few reasons.

First, GNOME Calendar is written in C.  I know it sounds like language-chauvinism, but that’s not the language we at Yorba feel should be the future of GNOME application development.  (That is, the language for developing full-blown applications; I’m fine with C for the underlying libraries, although I would still suggest library developers consider Vala.)  It’s not fear of C itself, it’s the boilerplate and bookkeeping that GObject C development requires that becomes more and more onerous as a project grows.   It’s also the ramp-up required for new contributors to make productive patches.  We have coded two mature applications, Shotwell and Geary, in Vala.  We have good reasons for coding a third in the same.

Second, I have particular opinions about the underlying design (not merely the user interface) for a network calendar application that I felt were not being approached in GNOME Calendar, or indeed in other calendar applications we looked at.  With California I’ve put a bit of work into a flexible date and time model that treats date spans as iterable collections; makes various units of time (weeks, months, years, etc.) iterable date spans as well as concrete units; knows the difference between calendar time and wall clock time; can deal with iCal‘s timezone model; and so forth.  The date/time model is cleanly separated from the backend network connectors and from the UI itself.  It also makes full use of GObject’s properties and signals so they can be directly bound to GTK widgets.  This is a GObject application; let’s live and breathe GObject then.

Third, the knee-jerk reaction that everyone in the GNOME community should be working on a single set of applications is not realistic nor a vision for growth.  There’s nothing wrong with GNOME users having choices for their applications.  Parallel development of applications even fosters growth as one team takes ideas from another, and vice-versa.  Some people like Thunderbird, some people like Evolution, some people like Mutt, some people like Geary; what’s wrong with that?  I suspect the idea is that it’s better to pool all available resources behind one code base, but that assumes a flawed one-size-fits-all vision of software that is less true in 2014 than it ever was before.

JIm Nelson's blog and archives from Yorba Foundation's original blog