A VyOS 1.2.0-alpha image with FRR instead of Quagga is available for testing (and we've found a GPL violation in VyOS)

by Daniil Baturin

FreeRangeRouting

Now that 1.1.8 release candidate is out and is (hopefully) being tested by community members, we can get back to building the future of VyOS.

It's been obvious that Quagga needs a replacement, and, since we've been using a Quagga fork inherited from Vyatta Core that includes features that never made it to the mainline quagga, even more so. The mainline Quagga still doesn't have usable commands for configuring multiple routing tables, nor they seem to actively accept patches that would be OS-specific.

The options were discussed many times and so far it seems FreeRangeRouting is the best option. It's a fork of Quagga that is being actively developed, actively accepts contributions, and already includes a number of features that Quagga lacks, such as support for network namespaces, PIM-SM, working IS-IS and more. There's also work being done on non-disruptive config reload.

While FRR is more or less a drop-in replacement for Quagga, it's not identical, and many CLI adjustments will be needed to make VyOS work with it. It needs a lot of testing. For this I've built a custom image that has vyatta-quagga replaced with FRR.

You can download the image here: http://dev.packages.vyos.net/tmp/vyos-1.2.0-alpha-frr-test.iso Please test it and report any issues in the routing protocols configuration you find. It's obviously experimental and you shouldn't use it in real routers, the best way to test is to load your production configs into test virtual machines.

GPL violation

Now to the GPL violation we've found. That violation in fact has been there for over five years and no one noticed it! Then again, it's relatively indirect and subtle.

Quagga is licensed under GPL (and so is FRR). In Vyatta/VyOS, Quagga has been built with SNMP support, so it links with net-snmp. In turn, net-snmp is built with SSL support and links with OpenSSL. This is where the problem is, OpenSSL is licensed under a four-clause BSD license that is not compatible with GPL.

Sadly, there is no easy way out, so it will take some time to fix this violation. The options are:

  • Build Quagga/FRR without SNMP support, which means routing protocol data will not be available through SNMP
  • Build net-snmp without SSL support, which means SNMPv3 will stop working
  • Patch net-snmp to support another cryptographic library that is GPL-compatible

The third option is hardest to implement, but it's the most appealing of all since all functionality will be preserved. We'd like to hear your suggestions regarding the libraries that would be license compatible and that can co-exist with OpenSSL.

Upvote Upvoted 12
26 responses
Well, mbed TLS is dual-licensed for GPLv2 and Apache, and I've been told the API is way, way better documented and easier to work with than OpenSSL.
— Chris Wadge
Yuriy Andamasov upvoted this post.
OpenSSL is moving to Apache License v2.0, which is GPL-compatible, so don't necessarily have to switch. https://www.openssl.org/blog/blog/2017/03/22/li... later update post (which throws a server error for me at the moment, posting archive.org copy). https://web.archive.org/web/20170804003631/http...
— Chris Buechler
Hi! Tried some routing protocols. - Multi-area OSPF with stubs, RIP, BGP - Redistributions (via one router) Diagram: https://imgur.com/3PqpIr1 All worked as expected, minus this one thing: when attempting to redistribute connected to ospf, using route-map, I kept getting this: vyos@VYOSALPHA12-1## set protocols ospf redistribute connected route-map REDISTCONN [edit] vyos@VYOSALPHA12-1# commit [ protocols ospf redistribute connected ] % Unknown command. [[protocols ospf]] failed Commit failed If I leave the route-map out, all is good. Also, few times got into this kind of slump after commit: vyos@vyos# save DEBUG vexit_internal: calling getEditResetEnv() without config session Saving configuration to '/config/config.boot'... Done [edit] vyos@vyos# exit exit There are stopped jobs. DEBUG vexit_internal: calling getEditResetEnv() without config session [edit]
— Antti
Well done Antti! Joi us on https://phabricator.vyos.net.net i will be copying your report to https://phabricator.vyos.net/T306
— Yuriy Andamasov
Are other FRR protocols also available with VyOS 1.2 alpha Like IS-IS v4 and v6, that is not supported with VyOS stable builds with Quagga.
— Hamid
There's a much bigger GPL violation issue, in that Cumulus Networks, 6WIND, Bigswitch Networks et al refuse to accept that when code is made to explicitly use or extend and depend upon functionality and abstractions that are provided and implemented by GPL code that that code must itself (source code especially) be distributed in accordance with the GPL. They waged a multi-year campaign on that. When they didn't get their way, they and their partners squashed my ability to work on Quagga. More to the point, they also are distributing code that depends on GPL licensed code from Quagga (inc. code I have copyright in) outwith the terms of the GPL licence, as per their incorrect views above. As a result Section 4 of the GPL became applicable to the FRRouting codebase, and to Cumulus Networks, 6WIND, Bigswitch networks, and any others involved in this infringement. This means any copying, use or distribution (amongst other things) of that code-base no longer has a GPL licence - it is unlicensed. This applies to any further downstream use of their code-base. I reserve the right to recover compensation for any activity by an entity or person, through use or distribution or otherwise, that would infringe on the copyright on any software I made available under the GPL via the Quagga project, where that activity would not otherwise be permitted by the GPL licence. For infringement by use alone, I will be entitled to ask for compensation of £2000 or %0.12 of annual gross revenue or income, for each calendar month in infringement occurs, from any person or entity involved in infringement.
— Paul Jakma
Hi Paul, long time no see! I have to admit I haven't done any in-depth review of FRR yet. It looks good to me on the surface though: full text of proper GPL without strange exceptions thrown in is present, so are license headers. Since you obviously know a lot more about the situation than I do, could you explain what exactly the wrongdoing of FRR is?
— Daniil Baturin
Hi Danill, As I said, there was a long campaign by those behind the FRRouting fork to undermine the GPL of Quagga. They argue that you can build software on top of Quagga (extending and using abstractions and functionality from lib/ and zebra/) and then just /ignore/ the requirement of the GPL that any such works must themselves be distributed in accordance with the GPL - including the source code. They resisted this legal reality *vehemently*, even after the Quagga project obtained formal legal advice (and they had input into the drafting of the query) and that legal advice came back that what they argued for was not permitted by the GPL. You can see this manifested in the "babeld/" and "ldpd/" directories of FRRouting. Code that has been adapted and modified to make specific use of Quagga provided functionality and abstractions, such as the "thread", "vty" , "zprivs" functionality, as well as relying explicitly on the "zebra" daemon via the "zserv" IPC. Yet, the prominent licence notifications on the files in those directories do NOT fulfill the conditions that the GPL requires. Which is quite deliberate. For they have argued repeatedly that you can ignore the GPL when it comes to source code, even when it depends explicitly on Quagga GPL code (and been told repeatedly this is not permitted). There simply is _no_ GPL licence for the FRRouting code. Use or distribution of it is infringement. I reserve the right to recover compensation from any one who infringes on the copyright I have in that code-base. This will remain the case so long as they refuse to settle this matter with me. I'm sorry about this. It sucks for users. However, it also sucks for me. I never asked to be put in this position. Paul
— Paul Jakma
Not worried about that, for us is still long road to FRR and once it will be closer we will clarify all with linux foundation folks
— Yuriy Andamasov
The Linux Foundation will tell you what they believe their corporate members want them to tell you.
— Paul Jakma
Yea, very likely. Everybody do the same
— Yuriy Andamasov
Hey Paul, yes, I see babeld and ldpd are indeed under MIT, and there's no indication of it at the top level. I also wonder why LGPL has been included in the package since Zebra times if everything under /lib is actually under GPL (I would guess allowing people to write new daemons under any license _might_ have been Mr. Ishiguro's intent). I've contacted FRR people about it. Oh, by the way, since we are both here... remember those Vyatta patches for PBR etc.? Would you want to import them in the mainline quagga? It's the only thing that was keeping us from updating to the normal quagga, and ironically, FRR doesn't have support for configuring multiple routing tables (as opposed to configuring a single custom table to put all routes in), so right now we are blocked from upgrading to either.
— Daniil Baturin
Daniil, Sorry, only saw this now. I can't say I remember those patches, but if you want to push them upstream, feel free.
— Paul Jakma
On there being a copy of the Library GPL in the top-level "COPYING.LIB". I've never taken that as anything but a copy of the LGPL, for other files to refer to if they wish - as they do for the "COPYING" file. The 2 lib/regex*.{c,h} files, from Glibc are the only files that refer to "COPYING.LIB", the rest of the files generally have GPL headers, and refer to the "COPYING" licence file.
— Paul Jakma
11 visitors upvoted this post.