Except that libgit2 has a linking exception. The Linux kernel also has a similar exception. GPLv2 is problematic as-is.
1 Like
That’s a bit unfair. I don’t know for sure what comments of mine you refer to, but I have indeed done that, rarely, and only after answering as honestly as I could for a few comments in a thread, before noticing that the other party had no interest in understanding my answers, and weren’t even reading them.
Now, the issue about license is, I’m open to the different options, but I don’t think we’re on the same page: Pijul is not quite usable at the moment (I’m confident that it will be in the next few weeks, though), and has never been usable before.
Yet, the most common comments I’ve heard over the years are about the license. Is this really the right moment to talk about licenses? My point is, not for me. My choice of the GPL-2.0 was a default one, might change (for example, the linking exception seems reasonable to me) and I don’t see how anyone would benefit from using libpijul before it’s properly debugged in real-life usage (the debugging for tests has been going on for a long time).
FWIW I think your choice of licence, name and whatever else kind of nonsense surrounding the project is completely fine. The project is amazing and will see use on it’s technical merit, there’s no need to listen to the HN crowds complaints, they are in such a rush to have the currently fashionable opinion that they rarely consider the long view…
As another datapoint, I would be very interested using libpijul in a commercial (closed source) application. It is fine if you don’t want to allow this, but if you do, then it needs to be something different than GPL.
1 Like
Or at least dual-licensed 
1 Like
Hi, I’ve created an account here just for answering this, after getting redirected from the #irc channel where I asked for a possibility of having a LGPL licence for libpijul.
I understand that this is not the right moment for you @pmeunier (the focus on the release is more important than the rest) but it’s actually more important than you might think to have an answer for this question as it’s actually quite crucial for some people.
I came for providing an actual example against your argument that the GPL doesn’t prevent usage. With my professional experience, it does.
I’ve been in the position for game studios to push for internal choices between Perforce, git and Mercurial. Most game studio have very specific assets and source code management needs and have to use the versioning system by creating custom tools around it for internal use. This use case is covered by the GPL and in theory would be fine, but there are cases where those tools needs to be provided to third party (a contractor for instance) and then would clash with the license (as there is no way they would provide their source code or change the licensing.
As a result, lots of those studios put rules preventing integration of GPL licenced libraries. For some of them it’s an automatic rule, for some others we have to go through a validation process with a lawyer checking it, but in both case the result will be a NO for GPL licenced code. LGPL can be argued (as long as it’s for tools and not for runtime engine that needs to run on specific hardware forcing static linking).
What it means in practice is that as much willing, we as software engineers, would like to use that tool and integrate it into our work pipeline, we can’t because of external restrictions.
Being a mercurial user for years, I’ve faced some of those issues first hand, and can tell you that yes it’s a very important point for convincing higher ups. Most of the time Perforce wins by default, because they prefer paying for something that everybody use and has no “strange” restrictions. Also, I wasn’t aware of the git linking exception and I can bet that most people would just stop at the “it’s GPL”.
I’m personally very excited about the idea of using both pijul and libpijul, and to share it with my professional contacts, but I already know that their first question will be the licensing and they will reject it because of the GPL. You are competing in a place where technical achievement is not enough for being convincing.
I hope you’ll take that comment in account, I love what you are doing and I wish this project a great success (even if you don’t update the licence :D). Also side note, I’m not coming from HackerNews and more from DLFP
3 Likes
In the WordPress docs team, there are ongoing discussions about GPL for plugins, and they are saying they will just link to the WP license page, which links to the Drupal license page, which answers some specific questions.
Two of the questions seem to apply here:
Is an agency, or service provider ‘distributing code’ on behalf of a client when under contract?
Can I write a “bridge module” to interface between Drupal and another system or library?
I can’t stand copyright personally, so if it were in any way a vote, I’d definitely vote for a permissive license. Although pijul’s main goal (AFAIK) of just being a command line tool with some integration is served OK by the GPL, I hope some of the testaments here will change pmeunier’s opinion on the matter. (Which might be the case since he said he is open to it.)
I’m a fan of the OSL license, it’s not parasitic (so doesn’t have linking issues), and it has a clause similar to the cloud stuff like the AGPL, it’s not GPL compatible so that might be off-putting to some.