Using libpijul in a non-GPLed free software project

1

I’m considering using libpijul, and possibly sanakirja, in a Rust project I’m
working on. This project, Intermodal, is not itself GPL-licensed, but is
permissively licensed under the CC0.

The legal ramifications of combining GPL-licensed code with non-GPL-licensed
code is complex. And, some concepts, like what constitutes a combined or
dervied work, are ambiguous.

So, I wanted to give my interpretation of the situation that using libpijul in
my project would create. This is both so that anyone who is more familiar with
the GPL can correct me, if am mistaken in my interpretation, and to get some
feeling for if what I would be doing is acceptable to the Pijul developers in
terms of the spirit in which the GPL is applied to the Pijul project.

Of course, any changes to libpijul itself would be themselves licensed under
the GPL and contributed upstream.

So, the situation is this:

Intermodal is a library and a binary licensed under the all-permissive CC0
public domain dedication and fallback license.

Intermodal is written in rust and statically links to all its dependencies.

Let’s call Intermodal’s source code imdl-src, and Intermodal’s binary imdl-bin.

imdl-src is currently licensed CC0. imdl-src links to a number of dependencies,
with a variety of permissive licenses. These are, 0BSD, Apache-2.0, MIT,
Apache-2.0 WITH LLVM-exception, BSL-1.0, MIT, Zlib, BSD-3-Clause, CC0, MIT,
Unlicense, and disjunctive combinations (A OR B) of these licenses.

My understanding is that the statically linked imdl-bin is a “combined work” of
all of these dependencies, and so, roughly speaking, is restricted by the
conjuction of these licenses. Since these are all fairly permissive licenses,
this is a relatively uncomplicated situation, and there are no restrictions on
the distribution of imdl-bin.

So, let’s consider a hypothetical future version of imdl-src, imdl-src’, that
depends on libpijul.

My understanding is that imdl-src’, because it does not contain libpijul, and
only calls API functions from libpijul, is not a derived or combined work with
respect to libpijul, and thus can continue to be licensed under CC0.

However, I believe that imdl-bin’, a statically-linked binary built from
imdl-src’, and its dependencies, including libpijul, would be considered a
combined work , and thus would be restricted by the conjunction of the licenses
above, and the GPL, due to the addition of libpijul as a dependency.

As I understand it, the restrictions of the GPL would then trigger if I
distributed imdl-bin’, for example by offering pre-built binaries built from
imdl-src’ for download.

I believe that these provisions would be easy to comply with. I read the GPL
2.0, and I think that it would impose two additional restriction on me, the
distributor of imdl-bin’.

One would be a requirement to make imdl-src’ available for download, which I
already do and continue to keep doing indefinitely.

The second would be that I would required to distribute copies of the GPL along
with imdl-bin’, which I could easily do.

Am I correct in my interpretation of the GPL? Also, would doing this be
acceptable to the pijul authors and community?

2

I think you are mistaken in this.
The FAQ for Static vs. Dynamic says

Does the GPL have different requirements for statically vs dynamically linked modules with a covered work?
No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

So it’s a combined work, not a derived work.

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL.

You have a GPLed program that I’d like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?
Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions.

1 Like
3

Thank you, I have updated the original post to use the term combined work where appropriate.

I interpret the above FAQ items to be in line with my original post.

Using the language of the first item: imdl-src’ is a “software modules that link with the library” , and thus can be CC0 (which is GPL-compatible), imdl-bin’ is “the work as a whole”, which must be licensed under the GPL.

Using the language of the second item, imdl-src’ is “your program”, which must be released “under a license compatible with the GPL” (CC0), imdl-bin’ is “the combination itself”, which is available under the GPL.

Is this correct?

4

I don’t think you can separate the source from the binary and give them two different licenses. Your code is a combined work of the various parts (with different licenses), and when you distribute that combined work, it should be GPL. The binary may be what you distribute, but it has to have the source too, because of the license.

1 Like
5

It sounds like the question is, what happens when you distribute just the source? And like, publishing imdl-src' on github without removing the original licenses and replacing them with GPL is perfectly legal, from my understanding of things; the ' adding a use libpijul:: does not in itself constitute a license violation.

(Nor someone building imdl-bin' on their machine, which constitutes commercial and/or private use, and will pull in a copy of the copyright notice by virtue of how cargo works)

6

My interpretation is that this is actually permitted.

Consider this sequence of events:

  1. imdl-src exists, which is the source code of intermodal. It is licensed CC0.
  2. I modify imdl-src to produce imdl-src’. imdl-src’ now depends on libpijul. However, it does not include any source code from or other contents of libpijul, so it is not a derived or combined work with respect to libpijul. It is just imdl-src, plus things like use libpijul::*, and calls to the lipijul API. My understanding it is that imdl-src’ may still be licensed as CC0.
  3. Now, I run the rust compiler, to produce imdl-bin’. The rust compiler does include the contents of libpijul, i.e. its source code, and this source code is combined with the source code of imdl-src’, and the source code of all the other dependencies. This combined work, imdl-bin’, is now bound by all restrictions in all licenses in all dependencies, which now includes the GPL, due to the inclusion of libpijul.

My understanding is that modifying imdl-src from #1 to imdl-src’ in #2 does not force imdl-src’ to be relicensed under the GPL.

However, the binary, imdl-bin’, is bound by the GPL, so the distributor of imdl-bin’, me, must honor the terms of the GPL, and thus must make available the source code, imdl-src’. However, I don’t believe that this also requires that imdl-src’ be licensed under the GPL.

7

I am not a lawyer, but it seems you can’t use an GPL library in a non-GPL program. This is what the LGPL is for. Two things:

  • Intermodal seems really awesome, but I don’t quite see why you would need Pijul for that.

  • Sanakirja is already MIT/Apache-2.0 (at your convenience), which essentially means that you only have to give credit.

The choice of the GPL for Libpijul was done at a time where Pijul was still experimental, and it wasn’t clear how it could scale. We wanted to encourage others to help us rather than take the ideas and improve it privately.

This didn’t quite happen, as it seems few people understood the ideas to begin with. Now that this is not a concern anymore, we might want to change the license.

8

I think the LGPL actually covers another scenario, which is when a non-open source program wishes to link to a LGPL library. In that case, the LGPL does not trigger when the binary is distributed, and the program author is not obligated to release the source of the program.

In my case though the GPL would trigger on the binary, imdl-bin’, but since I already make the source code available, idml-src’, I can be in compliance with the GPL without relicensing imdl-src’ to also be GPL.

But, I’m not a lawyer either, and when I’ve been researching this question I’ve found disagreement wherever it’s discussed.

Here’s a link which I think supports, roughly, the the interpretation that I wrote above. It discusses how a project may include GPLed files, and permissively licensed files in a single source tree. This quote:

preservation of notices on parts added to a GPL’d project may facilitate extraction of those parts by downstream users so that they may be used under the permissive terms instead of the GPL

Suggests that the permissively licensed files continue to be permissively licensed, although the work as a whole must be licensed under the GPL. In that case though, the hypothetical project actually contains copies of GPLed source files in the source tree, so it’s a little different.

Right now Intermodal is just a bittorrent metainfo utility, but I’m working on an archive format for use when distributing collections of files over P2P networks, and in other circumstances. I’m hoping to make the archive format more like a Git repository, in that it’s possible to track changes to content, add changes, and send those changes on to other users.

Since it’s a distributed P2P context though, it’s very important that changes retain their identity, so they can be signed, and those signatures can be distributed and verified. This makes a git-style system a less than ideal choice, since any rebasing or re-ording of history would render all signatures on all patches invalid.

So, I’m interested in Pijul, since I could have archives contain collection of patches, and preserve individual signatures over those patches.

I think some people don’t like having GPLed dependencies, but I don’t mind at all, as long as I don’t have to relicense other parts of the program.

9

I contacted the FSF Licensing & Compliance Team, which provides free licensing advice, for clarity about what specifically happens when combining CC0 and GPL code. Here’s what they said:

CCO license is compatible with GPL and GPL code can be combined with CCO code, but the combined (binary) work should be released under GPL. The parts of its source code will remain under the licenses which were given to them by their copyright holders. These licenses should be compatible with GPL too. No one, except the copyright holder, can change the license of its source code.

2 Likes
10

As far as I know LGPL requires that you can replace the LGPL licensed component as a user. Rust crates can’t be replaced without recompiling all dependents, so linking to libpijul would still require releasing the source code even if libpijul was LGPL licensed.

11

This functionality can have users in user applications. So it might be worthwhile to consider MIT/Apache-2.0 for the whole project. In the spirit of copy-free software.

12

I certainly did, and I still do consider that. I’m unfortunately more interested in math and code than in legal stuff, but that has recently resulted in getting plagiarised on academic papers, and seeing relicensing of stuff taken from Pijul source code.

So my stance on it is to not think to much about it at the moment, but I’ll consider it.

13

The main thing to make Pijul successful it to have many people use it. With Git being so dominant it not displace it on its own merit. So make it a library wich other projects can reuse. This way people many use it and also perhaps contribute back when there are essential features they need. For them to use contribute they need to use it 1st. Usage and contribution will make the project successful.

14

Pijul has the same license as Git, yet people use Git. I’ve never really understood that. argument that GPL prevents usage, because I don’t think it’s true in reality.

Edit: don’t get me wrong, I’m totally open to other licenses, but in the early days of Pijul, this was the only thing discussed on the internet about Pijul. The fact that so many “HackerNews life lecturers” had a strong opinion about this blocked me from considering a change.

3 Likes
15

Git started off early as one of the 1st open sources DVCS. The Linux kernel was also hosted on it which has a large contributor base who needed to learn Git to contribute. I guess this project does not have both these advantages of being early to the game and has many widely contributed software hosted on it. Also, the nature of Git was such that the project was not solely dependent on the main contributor.

So one strategy you can pursue is modularised the project and have other projects consume the algorithms and components. This will increase usage and contributions if people have usage-specific enhancements.

For embedded usage, may projects reimplement Git so it is not dependent on the GPL code. E.g.

  • JGit
  • Gogs
  • Gitea
  • EGit
  • Gerrit
  • Gitblit
  • NetBeans Git Plugin
  • etc.

If other projects want the functionality in Pijul then they will be forced independently Pijul algorithms like in the above projects which is a hassle to the developers, also leads to fragmented efforts than improving the core project, and not have the desired attribution. If Pijul is a dependency there is acknowledgement of usage if one digs into the dependencies.

16

Iirc the 1.0 release post also claims copyright over the algorithms, such that any clean-slate reimplementations would still have to be GPL2. Which definitely isn’t how copyrights work where I am in the US, but may hold up in European jurisdictions? Idk I’m mostly with pmeunier that “can this be built into a useful tool practical as a better replacement for git” is at this juncture much more important than “can you embed the reference implementation”.

1 Like
17

practical as a better replacement for git”

To make this better than Git one needs to also have good tooling and applications around it. If tools, IDEs and application trying to use Pijul as a Versioned Virtual File System (non GPLed) cannot freely embed these functionalities then chances of been better than Git may not be realised as in these fronts there are liberally licensed implementations of Git which can be used for such products. With Git I guess many users use additional tooling and integration than just the core command line.

18

Your examples kinda prove the opposite of your point.
Many of the reimplementation listed are written in the same language, with a more permissible license, and (I may be wrong, just had a quick look) don’t seem to share a lot of code.

1 Like
19

don’t seem to share a lot of code.

That’s the point. Independent reimplementation is a waste of effort. If there is one implementation which is well maintained and everyone can use and compatible with their licensing requirements then it is better than reinventing the wheel every time just to get around the GPL licensing requirement.

20

If there are several reimplementations in the same language, all of them with a more permissive license, surely they couldn’t all have been motivated by licensing?

1 Like