NPO Accounting Software for Currency Conversions

by Brett Smith on November 22, 2017

Conservancy helps project participants from all over the world travel to all kinds of conferences and hackfests (around 150 people in 2017!). Because of that, our day-to-day accounting work can involve a lot of currency conversions. Someone on a single trip might have expenses in multiple currencies, and want to be reimbursed in another currency different from all of those.

We previously used rates published by the Bank of Canada to do these conversions. It was a trustworthy source of data, but it wasn’t very user-friendly: we had to go through a multipart web form to get rates, save those in our records, and then convert amounts by hand. When they stopped publishing rates earlier this year, one thing we hoped to find in a replacement was an API that we could use to build some higher-level accounting tooling.

We evaluated several alternatives and found what we wanted in Open Exchange Rates. In particular, it has a historical rates API that meets our needs very well: give it a date, and it returns all the rates for that date in a JSON object. It’s easy to save those results in our books, and use the data for higher-level conversions.

I wrote oxrlib as the tooling we needed on top of that API. It starts as a simple command-line wrapper over the API: give it a date, and it shows you all the rates for that date. From there, you can pass more arguments to answer more specific questions. Name a currency or two, and it will show you the rates between just those currencies. Add an amount, and it will convert that amount from one currency to the other. It can even output all this information in the same format our Ledger books use, so it’s easy to insert directly into an entry we’re working on. All this functionality has already reduced the amount of time we spend processing reimbursement requests. A process that used to require several tools, copying data by hand between them, is now handled by a single command.

My bigger hope is that it will save us even more time developing more NPO Accounting tools. I put “lib” in the name “oxrlib” for a reason: it’s a fully-fledged Python module that I’ve developed with an eye toward reusing in the future. All the functionality we have today in the command-line wrapper should be easy to incorporate into other tools in the future. oxrlib gives us a starting point to automate bookkeeping in multiple currencies. I’m hopeful this pattern will let us make useful incremental progress on NPO Accounting. Today we build small, practical, reusable pieces that solve an immediate problem. Tomorrow we can use those to build more fully-featured programs that solve bigger problems.

You can find oxrlib on our Kallithea Git server, and even use it today with an account and API key from Open Exchange Rates. Expect to hear from me again soon about more NPO Accounting tools like this.

[permalink]

Tags: conservancy, Accounting

SFLC Files Bizarre Legal Action Against Its Former Client, Software Freedom Conservancy

by Conservancy's Staff on November 3, 2017

About a month ago, the Software Freedom Law Center (SFLC), the not-for-profit law firm which launched Conservancy in 2006 and served as Conservancy's law firm until July 2011, took the bizarre and frivolous step of filing a legal action in the United States Patent and Trademark Office seeking cancellation of Conservancy's trademark for our name, “Software Freedom Conservancy”. We were surprised by this spurious action. In our eleven years of coexistence, SFLC has raised no concerns nor complaints about our name, nor ever asked us to change it. We filed our formal answer to SFLC's action yesterday. In the interest of transparency for our thousands of volunteers, donors, Supporters, and friends, we at Conservancy today decided to talk publicly about the matter.

SFLC's action to cancel our trademark initiated a process nearly identical to litigation. As such, our legal counsel has asked us to limit what we say about the matter. However, we pride ourselves on our commitment to transparency. In those rare instances when we initiated or funded legal action — to defend the public interest through GPL enforcement — we have been as candid as possible about the circumstances. We always explain the extent to which we exhausted other possible solutions, and why we chose litigation as the last resort.

Currently, this trademark action is in its early stages. SFLC filed a petition on September 22. Yesterday, we provided an answer that lists defenses that we plan to use. However, we welcome press inquiries and interviews on the subject and will do our best to respond and engage in public discussion when possible.

We are surprised and sad that our former attorneys, who kindly helped our organization start in our earliest days and later excitedly endorsed us when we moved from a volunteer organization to a staffed one, would seek to invalidate our trademark. Conservancy and SFLC are very different organizations and sometimes publicly disagree about detailed policy issues. Yet, both non-profits are charities organized to promote the public's interest. Thus, we are especially disappointed that SFLC would waste the precious resources of both organizations in this frivolous action.

Meanwhile, there is now widespread agreement in the FLOSS community, embodied both in the FSF's and Conservancy's Principles of Community-Oriented GPL Enforcement and the Linux Kernel Enforcement Statement, that FLOSS community members view “legal action as a last resort, to be initiated only when other community efforts have failed to resolve the problem.” We at Conservancy have always adhered to this fundamental principle, not only in GPL enforcement, but in all endeavors. In stark contrast, SFLC made no efforts — over the last eleven years since Conservancy was formed, nor in the last five years since we registered our name as a trademark — to express any concerns about our name, or a desire for us to change our name. We first learned of SFLC's complaints from this surprise attack of legal action.

SFLC's actions indicate that while they have provided legal services to some members of our FLOSS community, they do not view themselves as members of our FLOSS community, nor consider themselves bound by our community's norms. We are prepared to defend our brand, not just for ourselves but for our many member projects who have their home at Conservancy, our Outreachy diversity initiative, and our collective efforts to promote FLOSS. Nevertheless, we hope SFLC will see the error of their ways and withdraw the action, so that both organizations can refocus resources on serving the public.

[permalink]

Tags: conservancy, law

Join me at Free Society Conference and Nordic Summit!

by Bradley M. Kuhn on November 2, 2017

I'm delighted to be en route to Oslo, Norway as I write this post. I'll be speaking this weekend at FSCONS, the Free Society Conference and Nordic Summit. FSCONS is admittedly a small event, but has a theme that is absolutely intriguing and incredibly important to the future of software freedom. As can be read on the FSCONS website, the conference looks at the intersection of society, culture and technology. They invite speakers from throughout the Open Source and Free Software world as well as Free Culture and privacy and other technology activists.

I'll be giving a talk entitled The Crumbling Intellectual Infrastructure of Free Software & Free Culture Licensing. My talk will explore the history of Free Software and Free Culture licensing, how it relates to rise of for-profit popularity of Open Source, and the larger political and societal implications of where we are now. Admittedly the title sounds bleak, and I'm certainly known for my pessimistic talks about the future of software freedom, but I'll also include suggestions and ideas for activists to work to solve the problems our community now faces.

I want to thank in advance the great work of the organizers of FSCONS. Not only are they funding travel for speakers, but they've sent numerous clear and understandable emails about the weekend's events. It's made my planning smooth and easy.

I really encourage you to join us in Oslo this weekend; tickets are still available, and I did a quick check and round-trip flights from major cities in Europe this weekend to Oslo are around €200. I think it's well worth the trip! See you there!

[permalink]

Tags: conservancy, conferences

How Additional Permissions (aka Exceptions) Impact a Project's License

by Bradley M. Kuhn on October 20, 2017

When first learning about FLOSS (Free, Libre and Open Source) licenses, most of us learned them by their specific names, and generally when someone asks: What license is your project under?, the answer is a short moniker like GPLv2-only or GPLv3-or-later. However, since the earliest advent of FLOSS licenses, the concept of “additional permissions ” — or, the older term for it: “exceptions” — have been an essential part of the licensing infrastructure of our community.

The first additional permission for a copyleft license dates back to the Bison license. Since the 1980s, the GNU project gave an exception to the GPL for Bison to assure that typical uses of Bison — which copy some of Bison's own source code into the program's output — did not cause the GPL to apply to that output. This exception was simple, straightforward, and necessary. Users of parser generators would be surprised to learn that using Bison to generate their parser would cause their work to be governed by copyleft. Additional permissions are a scalpel-like tool for authors of copylefted software that carefully craft project policy to best fit their community. Indeed, these exceptions became such an important component of GPLv2 licensing that GPLv3 formalized the concept in the actual license text, defining the term “additional permission ” in GPLv3 itself.

This name better described the purpose of these clauses. Historically, the FSF called them “exceptions”. Throughout the 1990s and early 2000s, software authors deployed these solutions in creative ways, and it became clear that the phrase “license exception” was a poor descriptor (particularly given that “taking exception” is often considered a bad thing)! Slowly, the term “additional permission” became preferred.

Additional permissions are now quite prevalent. Some pursue esoteric policy goals, but most are simply stated and achieve a narrow goal. While additional permissions often make it impossible to name a project's license as simply “GPLv2-only”, the intended policy is usually clear by quickly reading the additional permission(s).

By way of example, despite our common shorthand of saying that Linux's license is GPLv2-only, the details are more complicated. Linux's license has a long-standing additional permission regarding syscalls. Specifically, this additional permission states that the copyleft terms do not cover user programs that use kernel services by normal system calls. This means that even though GPLv2 is a strong copyleft and seeks to apply to any derivative and/or combined work with Linux under copyright, downstream may license parts of combined works that use kernel services by normal system calls under terms other than GPLv2. While some contributors' code in Linux is licenses without this additional permission (such as plain GPLv2-only), most Linux contributors license their copyrights under “GPLv2 with the syscall exception”.

This week, the Linux community began a process to add another additional permission to Linux's license. As with the syscall exception (and any other additional permission), copyright holders must opt-in to grant this additional permission (and a long list of copyright holders have already done so for the new Statement). Conservancy has lauded this effort, since this additional permission allows violators (in some cases) to officially receive permission from those copyright holders to operate under the GPLv3 termination provisions. Copyright holders who participate in Conservancy's GPL Compliance Project for Linux Developers have long followed this, anyway (first informally, and then more formally in adherence to our Principles of Community-Oriented GPL Enforcement). The Linux Kernel Enforcement Statement formalizes this practice as an opt-in additional permission for Linux's license.

Fortunately, copyleft-based additional permissions (aka license exceptions) aggregate reasonably well. Specifically, additional permissions are fully compatible with the main copyleft license. At their option, downstream can usually remove the additional permission and distribute under the main license. Sometimes, licensing experts will talk about the effective license of a work. In practice this means: given a codebase that combines copyrighted material under many different licenses, and possibly many different additional permissions and exceptions, what's the lowest common denominator licensing requirement that, if met, will satisfy all the licensing requirements of all of the relevant licenses? With most copylefted works, this often does simplify to those easier monikers!

This begs the question: what's the effective license of Linux? Well, more than likely, it's simply GPLv2-only. The reason is this: all the copyrighted code that comprises Linux is (at least) licensed under GPLv2-only. A overwhelming majority is under “GPLv2 with the syscall exception”, and (with this week's announcement) an ever-growing swath will be licensed under “GPLv2 with the syscall exception and with the Linux Kernel Statement additional permission”. Not every copyright holder whose code is in Linux will grant either exception. Thus, the abbreviation to GPLv2-only, as a moniker for Linux's effective license, remains accurate.

Additional permissions are handy tools when building a community around a codebase, particularly when some community members have reservations about some aspect of the standard copyleft license. Copyright holders can grant an additional permission — even one that isn't strictly necessary — to quell concerns and clarify the licensing infrastructure.

Finally, all this begs one more question: Why aren't additional permissions to copyleft licensing (particularly after they were formalized in detail as part of GPLv3 itself) more widely utilized? My anecdotal theory is that licensing remains a difficult area of comprehension for FLOSS contributors and adopters. Like everyone whose primary expertise lies elsewhere, licensing novices prefer simple buckets that are easily understood; difficult concepts often dive deeper than necessary for typical daily work. While licensing geeks like me enjoy pondering and exploring the flexibility provided by additional permissions, many developers prefer a simple moniker to describe a project's license. As such, you'll even hear licensing experts oversimplify to describe a project's license. As one of my undergraduate Computer Science professors said to me, all your professors will oversimplify until you're graduate students, because we've yet to figure out the topological sort necessary to tell you the whole story in proper order such that we avoid these oversimplications that make experts cringe.

[permalink]

Tags: conservancy, GPL