More permissive license for BNFC

12 views
Skip to first unread message

Andreas Abel

unread,
Oct 21, 2020, 12:19:44 PM10/21/20
to bnfc...@googlegroups.com
Dear BNFC developers,

BNFC currently is licensed under GPL-2 which is a bit strict and
excludes e.g. industrial users from using the sample grammars in
closed-source projects.

I just released BNFC 2.8.4, still under the old license (GPL-2).

I am planning to release BNFC 2.9 under a more permissive license (MIT
or similar).

If you have anything to comment on this (approval or concern), please
join this discussion.

Best regards,
Andreas -- Your BNFC maintainer

--
Andreas Abel <>< Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andrea...@gu.se
http://www.cse.chalmers.se/~abela/

Jean-Philippe Bernardy

unread,
Oct 21, 2020, 3:54:55 PM10/21/20
to bnfc...@googlegroups.com
Dear Andreas,

I am opposed to giving away my work for free.
If industrial users wish to profit from our work without giving anything back in terms of contributions to BNFC, they have the freedom to negotiate a paid license with the authors.

Besides, it seems like a really drastic measure to change the license of the whole source code to MIT for just sample grammars.
Can't those be provided separately under a specific license?

In sum I am very much against such a plan.
Should you decide to go with it, I demand that you remove any contribution that I have made and may remain in the source code today.

Thanks in advance for respecting my copyright!
-- JP

--
You received this message because you are subscribed to the Google Groups "BNFC Developers and Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bnfc-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bnfc-dev/9bbc3e32-1fa2-8a0b-62b7-241d965ef7ee%40chalmers.se.

Ivan Perez

unread,
Oct 21, 2020, 5:17:26 PM10/21/20
to BNFC Developers and Users
Hi,

I can offer a bit of context about this, as I reached out to Andreas and the BNFC team originally.

There is no expectation, desire or plan on our part to use this in any commercial, closed-source project.

We are currently using BNFC for an NASA project that we are preparing for public, open-source release (it's currently sitting with the lawyers). NASA's open-source license is more permissive that GPL. GPL is getting in the way right now: it may limit our ability to use the some grammars, and it may limit our ability to integrate the use of BNFC in the compilation process. (I use 'may' because it appears to be slowing us down, but I am not a lawyer so I cannot determine if we can't or can, and I have not received final word on that either.)

It may be the case that there would be a specific provision in the license that could potentially allow us to use the by-product of BNFC but not BNFC itself. But what happens in practice is that once you mention there's a GPL tool that generates code that is linked involved, it makes a lot of lawyers uneasy about the process and it either takes a really long time (> years) to get an answer, or the answer is, conservatively, no. Our project can also not pay the BNFC group to relicense the work. So in practice we might have to drop BNFC, instead of using it in an open-source project that we hope gives everyone visibility, including BNFC.

BNFC could also have a more complex license that specifies which parts are GPL, how the by-product is not bound to the GPL license (is it?????), and how the grammars under examples/ have such and such license, and so on. But the price we pay in complexity is that, again, lawyers would take a really, really long time to examine things in detail to make sure NASA won't get sued. In practice, it makes the release process so slow and complex that it's just not worth using it even if it is technologically very good, and that would be a real shame.

Having talked to other grant applicants, I also know that for some DARPA-funded work, GPL is a no-go in practice (at least for them), and we simply do not use any GPL libraries for DARPA projects either (but we use BSD and share code with BSD/MIT or a more permissive license). (In the Haskell community, by the way, it's very, very, very common for people to use BSD, and I myself have published nearly all of my open source work under that license, although I fully understand the reasons not to want e.g., a company to be able to take it and profit commercially for it, which they might do, and I respect that choice.)

So, this is, in my opinion, a reasonable mid point to facilitate integrating BNFC in bigger projects and, hopefully, increase adoption.

All the best,

Ivan

Aarne Ranta

unread,
Oct 22, 2020, 2:37:27 AM10/22/20
to bnfc...@googlegroups.com
Dear Andreas, Ivan, Jean-Philippe,

The success of academic software is measured in impact, not money. Impact means essentially how widely the software is used. The harder it is to use, the less impact it will have. This is my fundamental argument why we should make BNFC free from licenses that make it harder to use.

Another argument is that publicly funded research and software should be free for everyone to use, including companies. We receive the public funding since we are expected to contribute to society by creating new knowledge and technology. We have already been paid for our work, and we should not require to be paid again.

The main way in which industrial users give back to the community is by their very adaptation of the software, which proves its impact. Other ways can be: contributions to the code (some BNFC contributors may already have been paid by companies), topics for real-world case studies, job opportunities. In comparison to this, any license fees we might be able to collect look insignificant to me.

Now, even though we strongly feel for the most liberal licenses, we must keep our promises and contracts - in this case, with the people who have contributed under the condition that the code is in GPL. We can try to persuade them - as I have done above - that liberal licenses are the way to go, and my experience is that this is OK for most people. But we cannot force anyone to do this, and hence we will have to remain in GPL until there is no code left from people who haven't agreed with the change of license. 

A possible way out is that such code is removed, as Jean-Philippe suggests, and rewritten by other people if needed. 

-- this ends my main argument: a little background follows

I started BNFC in 2002 together with Markus Forsberg, first with the Happy/Haskell backend. Michael Pellauer joined in 2003 and built Java, C, and C++. This matrix structure - to generate multiple modules for multiple target languages - was the essence of the approach, together with the ambition to keep the LBNF notation simple and declarative. Many other people joined soon after, extending and improving the software, and I am extremely happy that BNFC is now stronger than ever and constantly improved by new generations. 

Back in 2002, GPL was the natural choice for open-source projects, and we did not think more about it. Later, from around 2006, when I had basically left the development of BNFC myself and concentrated on GF, the GF project started to get requests from people in companies that we should go for more permissive licenses. It was not too late to do this for the grammar libraries and the runtime, which became LGPL and later alternatively BSD. The grammar compiler was more difficult to change, due to so many contributors starting from 1998, and there were no such requests for this part either. But the currently active developers would probably not mind changing the license, as we have since around 2006 expressed the intention to make GF as liberal as possible.

With best regards

  Aarne














 







Jean-Philippe Bernardy

unread,
Oct 22, 2020, 10:12:16 AM10/22/20
to bnfc...@googlegroups.com
So, in the big picture, you're saying that:

1. the GPL is highlighting how incompetent, expensive and obstructionists lawyers are;
2. Ideologues in the US government refuse to contribute to free software as a matter of principle.

I think you're really making a great case that the GPL, and the free software movement, is a great resource to fight against evil.
We have so few such resources, I must say that I am quite disgusted that anyone would consider squandering it.

Coming to the details, a lot of GPL compilers and tools produce non-GPL outputs (bison, gcc, etc.). There is no novelty here.

And before I forget: you should make sure to send your lawyers all the paper saying that *all contributors* have agreed to  re-license their contributions.
Otherwise any one of the contributors may decide to sue for copyright infringement!

Best,
-- JP.


On Wed, Oct 21, 2020 at 11:17 PM Ivan Perez <ivan....@nianet.org> wrote:

Jean-Philippe Bernardy

unread,
Oct 22, 2020, 10:23:24 AM10/22/20
to bnfc...@googlegroups.com
On Thu, Oct 22, 2020 at 8:37 AM Aarne Ranta <aa...@chalmers.se> wrote:
Dear Andreas, Ivan, Jean-Philippe,

The success of academic software is measured in impact, not money. Impact means essentially how widely the software is used. The harder it is to use, the less impact it will have. This is my fundamental argument why we should make BNFC free from licenses that make it harder to use.

IMO this is a short-sighted argument.  GPL is already very liberal: it only demands that distributing derivatives of the work include the source code of the derivative. This way, creative commons can be created. Non-copyleft licenses do not have this kind of long-term benefit.

Best,
-- JP.

Aarne Ranta

unread,
Oct 22, 2020, 10:40:23 AM10/22/20
to bnfc...@googlegroups.com
Jean-Philippe, a short answer: if we lose some potential users of BNFC because of GPL, then it is a loss of how widely the software is used. I have never heard of anyone refusing to use software just because it is BSD and not GPL.


--
You received this message because you are subscribed to the Google Groups "BNFC Developers and Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bnfc-dev+u...@googlegroups.com.

Jean-Philippe Bernardy

unread,
Oct 22, 2020, 11:18:41 AM10/22/20
to bnfc...@googlegroups.com
I don't think that this addresses my points in any way. My views remain the same in the matter.

Best,
-- JP.

Andreas Abel

unread,
Oct 23, 2020, 4:01:52 AM10/23/20
to bnfc...@googlegroups.com
> 21 okt. 2020 kl. 19:08 skrev Markus Forsberg <markus....@svenska.gu.se>:
>
> I'm all for a more permissive license, such as MIT. At Språkbanken we regularly release our software under MIT, so the suggestion is very natural to me. Why lock out potential users, I say. GPL-2 is from my point of view just a historical remnant. It was The license back in the days.
>
> With regards,
> Markus

Markus Forsberg

unread,
Oct 26, 2020, 3:44:52 AM10/26/20
to bnfc...@googlegroups.com
(My mail bounced last week, but Andreas has fixed that problem, so here is a resend.)

And just to add to my short answer: I’m in total agreement with what Aarne has been writing. If Aarne and I would have started with BNFC today, we would have decided to use MIT (or similar) rather than GPL, simply because we both want to maximize the number of potential users.

Markus

Vidarebefordrat mejl:

Från: Markus Forsberg <markus....@gu.se>
Ämne: Re: [SOCIAL NETWORK] [bnfc-dev] More permissive license for BNFC
Datum: 21 oktober 2020 19:08:41 CEST

Dear Andreas,
--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

andrea...@gu.se
http://www.cse.chalmers.se/~abela/

--
You received this message because you are subscribed to the Google Groups "BNFC Developers and Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bnfc-dev+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages