AGPL for accounting-api for now; LAGPL when it exists; maybe LGPL in a year if LAGPL never happens (was Re: A specific proposal on licensing)

[Bradley M. Kuhn]

TL;DR: I'm going to be spending more of my own time on this project, so
       it will be copylefted because I insist on that.  I'm open-minded
       about using weak copyleft for some parts of this project, but we
       should carefully chose and we may need to wait for the LAGAPL.
       If that takes more than a year, we have to seriously consider
       LGPL.

Full Details:

Josh, first of all, thanks for all your input at SCALE and our
discussions there about the licensing issue, and for your post.

Josh Berkus wrote at 13:34 (EST) on Sunday:
> I wanted to post this based on a discussion in Bradley's presentation
> yesterday on the project here at SCALE.

(BTW, for others: my SCALE talk slides aren't fully up yet because I
used a video in them and therefore I'm trying to figure out how to get
that working on a webpage slide publication properly; I'll fool with
that this weekend and hopefully get them properly published.)

The first thing to mention here, because it's related, is that I
pre-announced at SCALE that this spring, I'm rejiggering my workflow at
Conservancy, and Conservancy will be increasing staff, such that I can
spend at least 50% of my full-time Conservancy work on this project.
Thus, I expect the project to finally get moving at a more reasonable
speed.  (I realize the work has moved at a glacial pace since we
started, and I'm working to fix that soon(-ish).  I admit it may be June
before I've transitioned my workflow appropriately and can hunker down.)

That said, what this means is that I'm going to be funded by Conservancy
to be this project's leader.  As such, I'd like to to be clear and
transparent about a personal fact: I have no interest in, and will not
spend a lion's share of time on, a software project that isn't
copylefted.  If there's objection to that sufficient to change the minds
of Conservancy's Board of Directors, Conservancy will just have to
reassign me to other work.  (But, I think the Board of Directors are
likely with me on this. :)

That said, there are plenty of copyleft licenses around, and I see the
appeal and am indeed somewhat swayed by Josh's arguments for a weak
copyleft license for accounting-api.  But, I'm also a fan of RMS' essay:
           https://www.gnu.org/philosophy/why-not-lgpl.html

.. and therefore I don't want to jump to the conclusion that LGPL is the
right license for the double-entry accounting library we're building.
The key sentence from that essay, though, that sticks in my mind is:

>>    The most common case is when a free library's features are readily
>>    available for proprietary software through other alternative
>>    libraries. In that case, the library cannot give free software any
>>    particular advantage.

I thus see two conflicting arguments regarding accounting-api's license:

  (0) There *are* lots of implementations of double-entry accounting "out
      there", both proprietary and Free Software, but

  (1) none of them is a generalized library.

Under (0), an argument for weak copyleft dominates.  Under (1), the
argument for strong copyleft dominates.

Nevertheless, I'm starting to come around to find (0) more salient,
particularly when I think about API standardization.  For example,
BeanBooks is non-Free Software/non-Open Source software with a
double-entry accounting API of its own, and we'll have to compete with
that.  Plus, this isn't *that novel* of an idea.  We probably won't
influence anyone to make a Free Software application who wouldn't
otherwise have done so.  (i.e., I doubt anyone will say: "I was going to
make this proprietary, but this library is SO GOOD that I will just have
to write an Affero GPL my application now").

That said, I have spoken often about the issue of web services copyleft,
and frankly I think that in the age of the web-deployed application, the
traditional LGPL is has the same licensing effects (in practice) as a
non-copyleft license, since most deployments of the software will be on
the web (and not in a distributed software application).  Of course, the
Javascript portions might get distributed, but the at the moment the
library is in Python and will run server-side.

So, my tentative conclusion is: this yet another example of why we
desperately need the Lesser Affero GPL.  This has been an oft-discussed
idea for years and the FSF has communicated its willingness to work with
me and others in drafting a LAGPL.  The accounting-api gives me the
incentive for pushing on this issue is more important than ever.  I'm
going to start in earnest as soon as my schedule is cleared to work with
FSF on drafting the LAGPL.  While it's hard to speak to the merits of a
license that doesn't exist yet, my goal would be to get a weak copyleft,
web-services license that's right for this (and other) projects.

For the moment, though, that means we have to continue with the Affero
GPL.  We can't make the license more lax now, then less lax later.
Thus, leaving it AGPL'd now and then going to LAGPL later will be a move
to grant more lax permissions, but if we were go to LGPL now, then LAGPL
later, it would merely cause even more acrimony for those who had
adopted the accounting-api library under LGPL.

However, I realize this may be a hollow assurance to some.  I thus will
make the promise that if we *can't* get the Lesser AGPL written and
published by FSF within a year, then I relicense any copyrights of my
own in accounting-api under LGPL, and will urge other copyright holders
to do so.

Regardless, I will be asking all copyright holders to stay in touch with
me about this relicensing discussion so that we don't end up in a
situation where we want to relicense but a drive-by contributor holds us
up.  I'll have a conversation with every new contributor about this.

> Bradley argued that "we can wait until someone comes to us and wants
> to build something to relicense".  I believe that's a huge mistake;
> the majority of potential downstream application builders will dismiss
> the project without ever contacting us if the license is wrong.

I see your point about this, and it's a somewhat persuasive argument,
but for reasons stated above, I think we have to stick with the Affero
GPL for now.  I welcome a patch to the wiki and the codebase itself that
summarizes my points above so that people know what we're thinking and
know that a weak copyleft license for accounting-api is "on its way".

> This is distinct from the eventual NPO accounting *application*, which
> should probably be AGPL because Blackbaud.

Yes, I think the application portions will be Affero GPL'd and that's
100% non-negotiable.  My discussion above is purely regarding the
accounting-api repository only.
-- 
Bradley M. Kuhn, President, Software Freedom Conservancy