Licensing of beancount derivatives

105 views
Skip to first unread message

Chary Chary

unread,
Feb 26, 2024, 11:21:06 AM2/26/24
to Beancount
Dear all,

I just noticed, that the products which I would call beancount derivatives (e.g. fava  or smart_importer) are licensed with MIT license. However beancount itself is GPL-2.

I am not a legal person, but I am just wondering, shouldn't they also have to be GPL?

I know there is always a question as to how much of the original beancount code is reused in them, but if you google for this subject then you get for instance such statement:

https://opensource.stackexchange.com/questions/10180/how-much-of-my-code-becomes-gpl-if-i-use-some-gpl-code-and-how-different-does-my

https://softwareengineering.stackexchange.com/questions/338586/when-does-a-modification-of-gpl-code-stop-being-one

This is exactly why big companies who are developing code that is known to be vulnerable to lawsuits because there is an existing implementation to people could accuse you of copying (especially in cases where you'Re reverse engineering it) will do a clean room implementation by very explicitly prohibiting the developers to so much as look at the code they might be accused of copying.

Eric Altendorf

unread,
Feb 26, 2024, 12:11:17 PM2/26/24
to bean...@googlegroups.com
Is beancount code used in fava or smart_importer?

derivatives should indeed be GPL but if you simply write code that interfaces with the core beancount code, I think you can use any license you want (though I am not a lawyer)

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/85b2f2a7-2514-43ee-9ce6-f3fb13d445can%40googlegroups.com.

Daniele Nicolodi

unread,
Feb 26, 2024, 3:21:58 PM2/26/24
to bean...@googlegroups.com
On 26/02/24 17:21, Chary Chary wrote:
> Dear all,
>
> I just noticed, that the products which I would call
> beancount derivatives (e.g. fava or smart_importer) are
> licensed with MIT license. However beancount itself is GPL-2.
>
> I am not a legal person, but I am just wondering, shouldn't they also
> have to be GPL?
>
> I know there is always a question as to how much of the original
> beancount code is reused in them

AFAIK no Beancount code is reused (in the sense of have been copied) in
Fava or smart_importer. What Fava, smart_importer, and many other
projects do is to link to the Beancount code. This is not what is
usually defined as derivative work.

Linking to code licensed under the GPL is allowed when the code linking
to it is released under a license compatible with the GPL. Licenses
compatible with the GPL are licenses that give users the same or more
rights (often called freedoms, in the copyleft world). The MIT license
is compatible with the GPL, thus Fava and smart_importer are not
violating the Beancount license.

The situation is more complex for projects derived from Fava or
smart_importer. The MIT license would, in principle, allow anyone to
take their code and use it to develop something with a much more
restrictive license. However, this would violate the Beancount license.
Therefore the MIT license applies to Fava or smart_importer only for the
part of code that does not interact (directly or indirectly) with Beancount.

Cheers,
Dan

Daniele Nicolodi

unread,
Feb 26, 2024, 3:42:53 PM2/26/24
to bean...@googlegroups.com
On 26/02/24 18:11, Eric Altendorf wrote:
> Is beancount code used in fava or smart_importer?
>
> derivatives should indeed be GPL but if you simply write code that
> interfaces with the core beancount code, I think you can use any license
> you want (though I am not a lawyer)

This is incorrect. It is possible to link to GPL licensed code only from
code released under a compatible license.

Cheers,
Dan

Eric Altendorf

unread,
Feb 26, 2024, 4:04:52 PM2/26/24
to bean...@googlegroups.com
I might need a reference with more detail to understand what you mean.  If I interpret what you said naively, it would seem, for example, that any code that is written to make calls to the Linux kernel (ie anything that runs on linux) would have to be GPL....
 

Cheers,
Dan


--
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+...@googlegroups.com.

Daniele Nicolodi

unread,
Feb 26, 2024, 5:26:28 PM2/26/24
to bean...@googlegroups.com
On 26/02/24 22:04, Eric Altendorf wrote:
>
>
> On Mon, Feb 26, 2024 at 12:42 PM Daniele Nicolodi <dan...@grinta.net
> <mailto:dan...@grinta.net>> wrote:
>
> On 26/02/24 18:11, Eric Altendorf wrote:
> > Is beancount code used in fava or smart_importer?
> >
> > derivatives should indeed be GPL but if you simply write code that
> > interfaces with the core beancount code, I think you can use any
> license
> > you want (though I am not a lawyer)
>
> This is incorrect. It is possible to link to GPL licensed code only
> from
> code released under a compatible license.
>
>
> I might need a reference with more detail to understand what you mean.

There are countless explanations of this principle online, starting with
official GNU position on the matter:
https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL

For completeness of information, it is worth noting that this principle
is sometimes disputed. This limitation was clearly meant to exist when
the GPL license was written, however, AFAIK it has never been tested in
court. The Beancount mailing list is not the place where this matter
should be discussed.

> If I interpret what you said naively, it would seem, for example, that
> any code that is written to make calls to the Linux kernel (ie anything
> that runs on linux) would have to be GPL....

There is no linking going on between the Linux kernel and user space.
There is the syscal interface, which is covered by the so-called "syscal
exception" annotation, see for example
https://en.wikipedia.org/wiki/Linux_kernel#cite_note-12 and
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES/exceptions/Linux-syscall-note


Most programs, however, interface with the kernel via the C standard
library, which on most Linux systems is the GNU libc, or glibc, which is
indeed released under the terms of the LGPL, not the GPL. The LGPL
allows linking to code released under non-compatible licenses.

Cheers,
Dan

Reply all
Reply to author
Forward
0 new messages