is Beancount GPL2 or GPL2+ ?

[Stefano Zacchiroli]

Heya,
I've tried to understand the actual license under which Beancount is
released, but I haven't found a conclusive answer --- hence my question
here.

- the top-level COPYING file is the text of the GPL, version 2.0
- most .py files have no explicit license header
- setup.py and PKGINFO say "GPL" (without version); hence PyPi says the
same
- bin/treeify contains "__license__ = 'GNU GPL v2'"
- README says: "This code is distributed under the `GNU General Public
License <COPYING>`_;" (which looks like a typo/incomplete sentence?)

So it looks like Beancount is GPL2, but is not clear if it's "version 2
only" or "version 2 or above". Either way, being more explicit about all
this would be ideal and helps, for instance, distribution packagers.
(My 0.02 EUR: "2 or above" would be better.)

Martin: can you clarify?

While we are at it, I remember that in the past you started a discussion
about contributor agreements, but I don't remember reading a conclusion
about that. What do you currently require in order to accept patches
coming from contributors?
(My 0.02 EUR: just for something very lightweight, like the DCO, and
avoid other CAAs/CLAs.)

Many thanks in advance for your clarifications,
Cheers.
--
Stefano Zacchiroli . za...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[Martin Blais]

On Sun, Nov 13, 2016 at 5:31 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

Heya,
  I've tried to understand the actual license under which Beancount is
released, but I haven't found a conclusive answer --- hence my question
here.

- the top-level COPYING file is the text of the GPL, version 2.0
- most .py files have no explicit license header

The license at the root of the project applies.

Do I need to repeat the license in each and every file?

I used to do that on some other projects, didn't bother for this project.

 

- setup.py and PKGINFO say "GPL" (without version); hence PyPi says the
  same
- bin/treeify contains "__license__ = 'GNU GPL v2'"
- README says: "This code is distributed under the `GNU General Public
  License <COPYING>`_;" (which looks like a typo/incomplete sentence?)

So it looks like Beancount is GPL2, but is not clear if it's "version 2
only" or "version 2 or above". Either way, being more explicit about all
this would be ideal and helps, for instance, distribution packagers.
(My 0.02 EUR: "2 or above" would be better.)

Thanks for pointing out some loose ends.

Martin: can you clarify?

Yes, it's v2.

No strong opinions about moving it to v3, I just don't have time to review the implications.

While we are at it, I remember that in the past you started a discussion
about contributor agreements, but I don't remember reading a conclusion
about that. What do you currently require in order to accept patches
coming from contributors?
(My 0.02 EUR: just for something very lightweight, like the DCO, and
avoid other CAAs/CLAs.)

After much reading about this, I'm still set on having something like the Clojure project (and many others) with a signed CA for contributions beyond a few LOC. This hasn't been a problem yet, because most of the contributions are done upstream in the fava project (lots of activity there!). So far I've tried to respond to their needs myself and implement core changes when they need them. Note: It's still a GPL'ed project, and as always, my intent is for it to remain free forever.

I remember the license issue used to be somewhat of a problem for you, and I have no solution to offer. You'll have to decide for yourself whether ideology trumps practicality. (Note that you can accomplish a *lot* of customization via plugins, which you don't have to contribute back by changes to the project itself, so that's an alternative.)

Many thanks in advance for your clarifications,
Cheers.

--
Stefano Zacchiroli . za...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20161113103108.ppk3vo2ider4ocky%40upsilon.cc.
For more options, visit https://groups.google.com/d/optout.

[Stefano Zacchiroli]

On Sun, Nov 13, 2016 at 11:16:08PM -0500, Martin Blais wrote:
> The license at the root of the project applies.
> Do I need to repeat the license in each and every file?
> I used to do that on some other projects, didn't bother for this project.

That is recommended only if you care about code reuse patterns such as
"taking a file from beancount and using it elsewhere", but is not
strictly needed.

What is needed is writing somewhere what the applicable license is, and
having the text of GPL2 top-level is *not* enough. Most notably because
having it doesn't say if it's "GPL version 2 (only)" or "GPL version 2
or (at your option) any later version". The text of the GPL license
itself recommend specifying that in license headers; if you don't do so,
for whatever reason, you need to find another way (e.g., the README).

> Yes, it's v2.
> No strong opinions about moving it to v3, I just don't have time to review
> the implications.

Sorry to be pedantic, but this still doesn't answer my question: is it
"2 only" or "2 or later"? In passing, I note that "2 or later" is in
fact a step in between what you write here, as it will be usable *both*
as "v2" and as "v3", depending on the needs of people.

Given how useful as an accounting library Beancount is, I have hard time
believing that no one will ever need to use it in combination with some
"v3" code, so I really think that "v2 or above" is the choice that is in
the best interest of the project, but of course it's your call.

> After much reading about this, I'm still set on having something like the
> Clojure project (and many others) with a signed CA for contributions beyond
> a few LOC. This hasn't been a problem yet, because most of the
> contributions are done upstream in the fava project (lots of activity
> there!). So far I've tried to respond to their needs myself and implement
> core changes when they need them. Note: It's still a GPL'ed project, and as
> always, my intent is for it to remain free forever.
>
> I remember the license issue used to be somewhat of a problem for you, and
> I have no solution to offer.

Right now the license is a problem only in the sense that I'm not clear
on what that is and, for instance, I wouldn't be able to package
Beancount for Debian until that is clarified, but we're converging there :)

CAA/CLA OTOH, when you end up putting it in place, will be a "problem"
for me only in the sense that I will never sign a copyright transfer (or
similar) in order to contribute code. But of course I'll live with it,
either keeping local patches when needed, or trying to convince you to
reimplement the same features yourself :-) But this certainly won't stop
me from using Beancount as the beautiful piece of FOSS accounting tool
that it is.

> You'll have to decide for yourself whether ideology trumps
> practicality.

I didn't want to discuss politics here, but since you raised it: I'm
convinced it's not a matter of ideology, but of long-term strategy.
These kind of choices shape the structure of the community you want to
build around Beancount, with far reaching implications on the long term
sustainability of the project. But, again, I'm not complaining (I've
already done it in the past :-)) or anything, I'm just trying to clarify
and reach a final point on discussions that I perceived as still
ongoing.

Thanks,

[Stefan Monnier]

> Yes, it's v2. No strong opinions about moving it to v3, I just don't
> have time to review the implications.

FWIW, long earlier discussions and analysis of the problem of
"GPLv2-only for Linux" concluded that the GPL is one of the very rare
licenses which doesn't *automatically/implicitly* say "or further
versions".

So if you don't have a strong opinion, I suggest you go with "or later",
which is the recommended choice for the GPL and the apparently only
choice for most other licenses.


Stefan "firmly headed towards offtopic"

[Martin Blais]

So reading about this more, I have to say, I tend to agree about Linus' views on GPLv2 or later so far:

https://www.youtube.com/watch?v=PaKIZ7gJlRU

In a sense, you have more freedom with GPLv2 only.

I also don't want to impose my views on others.

For me, the reason to go "or later" would be practical ones, like, most of the code out there being v2 or later and not being able to build on top because of this.

(More reading...)

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+unsubscribe@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20161114072454.pj63gb56ydvpdqvq%40upsilon.cc.

[Stefano Zacchiroli]

On Sun, Nov 20, 2016 at 11:54:47AM -0500, Martin Blais wrote:
> In a sense, you have more freedom with GPLv2 only.
> I also don't want to impose my views on others.

I don't follow.

GPL2+ means "GPL2 OR any later version". The logical disjunction in
there is arbitrated by who receives the code, that is, your users. So
GPL2+ gives to your users *all* the freedoms of GPL2 *plus* the
alternative of opting for GPL3.

If you don't want to impose your views on others, GPL2+ is really the
only right choice here.

If, on the other hand, you want to make a political statement on why
GPL3 is a bad license (which is Linus' case) than you could want to go
for "GPL2 only", but that is precisely imposing your views on others.

Plus, on the pragmatic side, "GPL2 only" will inhibit both you and your
users to mix GPL3 code with the Beancount code base. Linus doesn't care
about this aspect because the Linux kernel is so important in the
ecosystem that they have the de facto power to *force* others to
relicense as GPL2-compatible just for being included in Linux. I doubt
that this is currently the case for Beancount, although I do wish you
that level of success :-)

Cheers.

[Martin Blais]

On Sun, Nov 20, 2016 at 2:38 PM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Sun, Nov 20, 2016 at 11:54:47AM -0500, Martin Blais wrote:
> In a sense, you have more freedom with GPLv2 only.
> I also don't want to impose my views on others.

I don't follow.

Here's the rub: My understanding so far in the process (and I'm still learning about this) is that assuming the clauses implicit in the GPLv2+ is akin to assuming a deeper part in the FSF's political ideology. I'm not against the FSF's mission, but in general I'm not really interested in being part of a movement, a club, etc. I just write code and I share it with others, it's very simple. From users I get back bug reports, documentation fixes, a forum to debate ideas and questions help in finding interesting solutions to problems I have to solve, and of course, the occasional patch. I'm much more interested in the technical aspects of problem-solving than in any kind of mission.

All I require if my code is used and modifications to the software are made, is that they be shared back with me, and by extension, with all others. I think it's a fair arrangement and a simple idea. Linus expresses this very well and succinctly in his response to the questioner and I feel the same way. I'm not sure the GPL is the best way to implement that, but I always thought it was. 

Now I'm not so sure anymore. I have to think about this some more; unfortunately, I have too little time to devote to understanding all the ramifications involved; most of my free time has to be spent on machine learning for a while. I'll go read some more and come back later.

GPL2+ means "GPL2 OR any later version". The logical disjunction in
there is arbitrated by who receives the code, that is, your users. So
GPL2+ gives to your users *all* the freedoms of GPL2 *plus* the
alternative of opting for GPL3.

If you don't want to impose your views on others, GPL2+ is really the
only right choice here.

That wouldn't work: If someone decides to make a copy as GPLv3, I wouldn't be take the changes back into my original v2+ version. Linus specifically addresses that issue in his response.

[Stefano Zacchiroli]

On Sun, Nov 20, 2016 at 03:35:07PM -0500, Martin Blais wrote:
> > If you don't want to impose your views on others, GPL2+ is really the
> > only right choice here.
>
> That wouldn't work: If someone decides to make a copy as GPLv3, I wouldn't
> be take the changes back into my original v2+ version. Linus specifically
> addresses that issue in his response.

But the Linux kernel doesn't have any CAA/CLA, which you seem to want
for Beancount. If you do have a CAA/CLA in place, the blocker for
including rogue changes that are made to Beancount without coordinating
with you will not be the license; it will be the lack of willingness to
sign the CAA/CLA.

In general you will encounter either coders that value integrating their
changes back into the upstream Beancount code base (so that it is you
maintaining the changes and not them), or coders that don't care and are
fine with keeping maintaining local changes. In the former case it will
be pointless for those coders to insist their changes are GPL >= 3,
because they know you won't accept them. In the latter case you'll find
plenty of other blockers for code inclusion before hitting the license
one (in fact, very likely you won't even know those code changes exist,
because their authors will probably not distribute them in the first
place).

[Martin Blais]

On Mon, Nov 21, 2016 at 3:51 AM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Sun, Nov 20, 2016 at 03:35:07PM -0500, Martin Blais wrote:
> > If you don't want to impose your views on others, GPL2+ is really the
> > only right choice here.
>
> That wouldn't work: If someone decides to make a copy as GPLv3, I wouldn't
> be take the changes back into my original v2+ version. Linus specifically
> addresses that issue in his response.

But the Linux kernel doesn't have any CAA/CLA, which you seem to want
for Beancount. If you do have a CAA/CLA in place, the blocker for
including rogue changes that are made to Beancount without coordinating
with you will not be the license; it will be the lack of willingness to
sign the CAA/CLA.

In general you will encounter either coders that value integrating their
changes back into the upstream Beancount code base (so that it is you
maintaining the changes and not them), or coders that don't care and are
fine with keeping maintaining local changes. In the former case it will
be pointless for those coders to insist their changes are GPL >= 3,
because they know you won't accept them.  In the latter case you'll find
plenty of other blockers for code inclusion before hitting the license
one (in fact, very likely you won't even know those code changes exist,
because their authors will probably not distribute them in the first
place).

Based on my roughly 20 years of experience developing my own and contributing to other people's open source software, I'm convinced that what you're claiming is inaccurate. My experience is that there are a few ideologues who make a lot of noise, and a vast majority of people who are just trying to get things done and who are grateful to get things for free and contribute the occasional patch back to the project within the framework established by the author, given a reasonable license (such as GPL). Most users initially try free software without even looking much at the specific terms--most people are interested in solving some problem they have first and foremost, "git clone this and that, let's try this out", and at the end of the day, they use what works best.

There are many examples of thriving OSS communities which require a CA and I've never heard anyone complain that it's putting brakes on their development. Except for a few notable instances, most OSS development really centers around a core of a few individuals in each project anyway (<10 usually, even for large projects). And even the FSF requires one for contributions, for example to Emacs. The Clojure community is very healthy too, in that way, and there are others. I still remember when I signed those projects' CAs; it was a tiny hurdle, but it made me think more seriously that I was sharing away that code, and at the end of the day, it made me proud that I was contributing something back to these projects--if anything, officializing my participation in that way only served to make me feel closer, to make me feel more of a part of those communities. There's something nice about it, even. And my itch to send back that bug fix for the change I really wanted to see integrated upstream has always _greatly_ overridden the little bits of annoyance of sending back a signed scan by email.

About GPLv2: Git and Linux are examples of very successful projects which require only the "GPLv2 only". I'll keep investigating the idea of upgrading the license from "v2 only" to "v2+ or later", but I'm really not worried about estranging a few people here and there because of that. So far I'm a bit uncomfortable with some of the v3 differences. You have to interpret my reaction to this in context: I'm not interested in being part of a movement; I'm not an activist, I'm just a guy who likes to build things, things that are useful and original and which solve my own problems first, and if it's easy to do so at the same time, to spend more time to make those solutions also usable and useful for others and share some of what I've learning in doing this. I'm not _trying_ to create a "community," if it happens, it's something that just happens by itself, and I hope it's because the code works. I'm really just trying to write code to build an awesome accounting system that I can use, scratching my own/ itch, and taking pride in doing so elegantly, there's no stronger motivation. I wouldn't do this otherwise. I do like it when other people find what I've built useful and I try to help them if I have time, but in the end, success is defined primarily by being able to solve my own problems. It's completely fine with me if some small number of people don't like some small detail about the terms of distribution.

I think at the EOTD we just disagree on the license issue and let's just leave it at that.

[Stefano Zacchiroli]

On Thu, Nov 24, 2016 at 12:10:22AM -0500, Martin Blais wrote:
> I think at the EOTD we just disagree on the license issue and let's
> just leave it at that.

Except I didn't start this thread trying to agree on a license. Or on
anything else, really. I started this thread just to point out that it
is not *clear* whether Beancount is GPL2 or GPL2+. That lack of clarity
gets in the way of getting things done, e.g., packaging Beancount for
distros because they usually insist on license clarity.

From what you wrote I understand you're now inclined to keep Beancount
GPL2 only, at least for now. Can you please make this choice apparent in
the code itself, maybe fixing the inconsistencies that I've pointed out
in my very first message in this thread, or do you prefer if I file a
issue about this?

[Martin Blais]

On Wed, Nov 23, 2016 at 9:30 PM, Stefano Zacchiroli <za...@upsilon.cc> wrote:

On Thu, Nov 24, 2016 at 12:10:22AM -0500, Martin Blais wrote:
> I think at the EOTD we just disagree on the license issue and let's
> just leave it at that.

Except I didn't start this thread trying to agree on a license. Or on
anything else, really. I started this thread just to point out that it
is not *clear* whether Beancount is GPL2 or GPL2+. That lack of clarity
gets in the way of getting things done, e.g., packaging Beancount for
distros because they usually insist on license clarity.

From what you wrote I understand you're now inclined to keep Beancount
GPL2 only, at least for now. Can you please make this choice apparent in
the code itself, maybe fixing the inconsistencies that I've pointed out
in my very first message in this thread, or do you prefer if I file a
issue about this?

I'll fix the inconsistencies, thanks for reporting them.

Cheers (from Oahu),