On Thu, Jun 30, 2016 at 3:25 AM, Paul Jakma <p...@jakma.org> wrote: > On Wed, 29 Jun 2016, Avneesh Sachdev wrote: > > As you said, this file merely defines the wire format of messages >> exchanged with the FPM. Our (Sproute's) view is that this format should be >> no more subject to the GPL than, say, the OSPF wire format. >> > > The specific scenario we're thinking about is if that someone links code >> generated from the .proto file into their "Forwarding Plane Manager" >> component, then other code in that component should not be subject to the >> GPL. >> > > Maybe, maybe not. One should seek appropriate legal counsel about the > implications of having one's code depend on other GPL code, if that is > important to oneself. > > Incidentally, there is a precedent for this license verbiage -- fpm.h in >> the same directory. I had initially proposed putting only an ISC license >> header on that file -- but we settled on the current text after a >> discussion on the mailing list. Please see: >> > > https://lists.quagga.net/pipermail/quagga-dev/2012-October/009932.html and >> https://lists.quagga.net/pipermail/quagga-dev/2012-November/010020.html. >> > > I didn't notice that and I didn't merge that, but the question remains, > what does "Please retain both licenses below when modifying this code in > the Quagga tree." - is that a friendly request, is it part of the licence > and binding (in addition to all other things one may be bound in these > matters)? >
The intent of that was to allow a user to retain one license header of their choice (ISC or GPL) when they copy the file out to another codebase. Quagga itself could also choose to use the file under one of the licenses -- the above is a friendly request. > I wouldn't have given this any thought a year or 6 ago, but now I need to > be _super clear_ about this kind of stuff. > > And, while I have your attention, thanks for all the work you're putting >> into merging these and other patches! >> > > No worries. > > Another quick question. If we merge this, can we merge it with lowered > guarantees of future stability? I.e., I don't have any objections to > merging it, but we're seeing a lot of different state-extraction protocols > being put forward. If at some point in the future we need to consolidate > them, I don't want Quagga to be committed to having to support all of them. > > Is that basis OK? That will be fine... Thanks, Avneesh > > > regards, > -- > Paul Jakma | p...@jakma.org | @pjakma | Key ID: 0xD86BF79464A2FF6A > Fortune: > You roll my log, and I will roll yours. > -- Lucius Annaeus Seneca >
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
