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