On Thu, May 7, 2015 at 7:47 AM, Paul Jakma <[email protected]> wrote: > On Thu, 7 May 2015, Alexis Rosen wrote: > >> True, the quagga-specific changes wouldn't be in that BSD version, but >> that should be fine - anyone who needs it under BSD license can't use quagga >> anyway. > > > The source files have both Juliusz' MIT/X11 notices and GPL licence notices. > > Further, we require that any contributions to that directory come with > MIT/X11 licence grants so that they are guaranteed to be available to > Juliusz for use in the MIT/X11-only standalone-babeld.
Well, why I was pressing this point was that I would like to be able to contribute to babeld, quagga, bird, and also one day move stuff into hardware offloads. I think ipv6 source specific routing, in particular, is very critical for the future health of the internet, I would like to get atomic updates working (due to the RCU related changes in linux in particular, but also hardware offloads emerging), and I have this nifty short-rtt + fq_codel routing metric idea that I would like to apply not only to babel but to routing metrics in other protocols like ISIS or ospf. A concern with the recent merge of more recent babel stuff was that I was unsure if that contained the final mods to the wire protocol that landed in 1.5 and 1.6 in the mainline babel daemon. Seeing the commit history preserved this time in that merge was reassuring, although I now understand that that merge did not include a revert of the original commits, preserving original authorships. It seems to me the clearest path to be able to do useful future work in quagga is to be assured that my commits remain mine so I can apply whatever licenses I want to other implementations of the same idea and my version of the code, and to keep sane, try to make sure that anything substantial enters the less restrictive codebases first. Also, I have always treated bug fixes and small bits of code (< 10 lines) as basically license-free, but that is yet another untested legal theory (that I am willing to leave untested.) My biggest concern remains that unless there is a maintainer willing to keep the two babel protocol implementations correct and up to date that the partial support in quagga is a major barrier to future protocol revisions emerging from the ietf standardization process. > regards, > -- > Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A > Fortune: > If you notice that a person is deceiving you, they must not be > deceiving you very well. > > > _______________________________________________ > Quagga-dev mailing list > [email protected] > https://lists.quagga.net/mailman/listinfo/quagga-dev -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
