Conditions to have code accepted into the project
Dear all, We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project. Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure. Best regards Albert López
Albert - If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end. As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up. donald On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
Exciting news, a LISP implementation in FRR would be amazing! Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem. Best Regards, Renato. [1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license... On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Albert -
If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end.
As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up.
donald
On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
On licensing, all submissions need to be GPLv2 because it virally inherits GPL as soon as you include any macros, data structures, CLI infrastructure, etc. We are currently working on getting all of that under control for the project, so current state is not a refection of what needs to happen. To be extremely precise, if you are able to completely separate the "core" of your function away from the code that interacts with the rest of FRR, then you can keep your core as Apache-2 and only have the "adaptation" be GPL. With that said, each time this approach is studied, it become extremely complicated. Additionally, you can keep your project elsewhere as Apache and pull it into FRR (always "forward merging"), which means that any bug fixes, enhancements, etc that are proposed in FRR need to be separately done in your Apache repo and then pull into FRR. Here is a pretty good reference if you decide to take this path... https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.htm... This has an opportunity of getting into a long email discussion, so if you'd like to discuss more, perhaps a phone/video call would be best. cheers, JR On Thu, Jan 10, 2019 at 5:13 AM Renato Westphal < renato@opensourcerouting.org> wrote:
Exciting news, a LISP implementation in FRR would be amazing!
Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem.
Best Regards, Renato.
[1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license...
On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Albert -
If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end.
As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up.
donald
On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating
how
easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
Thank you every one for your comments. I see that legal part of the problem is more complex that the technical one. We need to study in more detail the possible options to make our code compatible with GPLv2. If we find an acceptable option, we will come back to you to validate the option as feasible. Best regards Albert López On 10/1/19 17:14, JR Rivers wrote:
On licensing, all submissions need to be GPLv2 because it virally inherits GPL as soon as you include any macros, data structures, CLI infrastructure, etc. We are currently working on getting all of that under control for the project, so current state is not a refection of what needs to happen.
To be extremely precise, if you are able to completely separate the "core" of your function away from the code that interacts with the rest of FRR, then you can keep your core as Apache-2 and only have the "adaptation" be GPL. With that said, each time this approach is studied, it become extremely complicated.
Additionally, you can keep your project elsewhere as Apache and pull it into FRR (always "forward merging"), which means that any bug fixes, enhancements, etc that are proposed in FRR need to be separately done in your Apache repo and then pull into FRR. Here is a pretty good reference if you decide to take this path...
https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.htm...
This has an opportunity of getting into a long email discussion, so if you'd like to discuss more, perhaps a phone/video call would be best.
cheers, JR
On Thu, Jan 10, 2019 at 5:13 AM Renato Westphal <renato@opensourcerouting.org <mailto:renato@opensourcerouting.org>> wrote:
Exciting news, a LISP implementation in FRR would be amazing!
Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem.
Best Regards, Renato.
[1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license...
On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com <mailto:sharpd@cumulusnetworks.com>> wrote: > > Albert - > > If you already have your own infrastructure there is no need to use > ours. I think the only real requirement is the usage of our ZAPI > protocol for talking to the RIB(zebra). This is especially true if > there is going to be active ongoing maintenance from your end. > > As for licensing I've added JR and David who are both better than me > on licensing and their implications. I'll let them speak up. > > donald > > On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu <mailto:alopez@ac.upc.edu>> wrote: > > > > Dear all, > > > > We have an implementation of the LISP protocol and we are evaluating how > > easy would be to adapt it to be integrated in the FRRouting project. Our > > initial code has its own memory management, timers (task scheduling), > > ... In order to know how much of the code can be reused, I would like to > > know if it is really mandatory to use the memory management library > > provided by the FRRouting project or the task scheduling (for instance > > to send periodic control messages) to have the code accepted and merged > > in the FRRRouting project. > > > > Another question we have is that our code is licensed under Apache 2. Is > > FRRouting license compatible with apache 2 ? I believe yes but I am not > > sure. > > > > Best regards > > > > Albert López > > > > > > _______________________________________________ > > dev mailing list > > dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> > > https://lists.frrouting.org/listinfo/dev > > _______________________________________________ > dev mailing list > dev@lists.frrouting.org <mailto:dev@lists.frrouting.org> > https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
Renato - If they just stuck to the encode/decode functions, and used non-blocking i/o wouldn't that just `work`? donald On Thu, Jan 10, 2019 at 8:13 AM Renato Westphal <renato@opensourcerouting.org> wrote:
Exciting news, a LISP implementation in FRR would be amazing!
Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem.
Best Regards, Renato.
[1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license...
On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Albert -
If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end.
As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up.
donald
On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
Yes, that would be possible with some effort, but it would solve only part of the problem. In addition to the CLI, all of ours plugins (confd, sysrepo, snmp, zmq, etc) are integrated with the FRR main event loop, so using anything else would be complicated (impossible isn't the right word here). And the effort to convert a new daemon to use the FRR event library should be much smaller than adapting FRR to accommodate different event libraries. On Fri, Jan 11, 2019 at 10:23 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Renato -
If they just stuck to the encode/decode functions, and used non-blocking i/o wouldn't that just `work`?
donald
On Thu, Jan 10, 2019 at 8:13 AM Renato Westphal <renato@opensourcerouting.org> wrote:
Exciting news, a LISP implementation in FRR would be amazing!
Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem.
Best Regards, Renato.
[1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license...
On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Albert -
If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end.
As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up.
donald
On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
-- Renato Westphal
Our implementation have an initial support of netconf to configure the deamon. It would be acceptable to have our daemon (Apache 2) configured through FRR using netconf? As an initial step our intention is only support LISP MS/MR (only control plane functionalities) Best regards Albert On 11/1/19 14:17, Renato Westphal wrote:
Yes, that would be possible with some effort, but it would solve only part of the problem. In addition to the CLI, all of ours plugins (confd, sysrepo, snmp, zmq, etc) are integrated with the FRR main event loop, so using anything else would be complicated (impossible isn't the right word here). And the effort to convert a new daemon to use the FRR event library should be much smaller than adapting FRR to accommodate different event libraries.
On Fri, Jan 11, 2019 at 10:23 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Renato -
If they just stuck to the encode/decode functions, and used non-blocking i/o wouldn't that just `work`?
donald
On Thu, Jan 10, 2019 at 8:13 AM Renato Westphal <renato@opensourcerouting.org> wrote:
Exciting news, a LISP implementation in FRR would be amazing!
Regarding your questions, here are my two cents: * FRR's CLI and zclient code are tightly coupled to the FRR event loop (lib/thread.[ch]), and this essentially makes it impossible for a daemon to use a different event loop. ldpd and nhrpd used libevent and libev, respectively, and both had to be converted to use FRR's event library. * Not using FRR's memory management should be fine (ldpd doesn't use it for instance, and other daemons use it only partially). * Our documentation says the Apache 2.0 and GPLv2 licenses are incompatible [1] unfortunately. Maybe JR and David can provide you guidance on how to solve this problem.
Best Regards, Renato.
[1] http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license...
On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp <sharpd@cumulusnetworks.com> wrote:
Albert -
If you already have your own infrastructure there is no need to use ours. I think the only real requirement is the usage of our ZAPI protocol for talking to the RIB(zebra). This is especially true if there is going to be active ongoing maintenance from your end.
As for licensing I've added JR and David who are both better than me on licensing and their implications. I'll let them speak up.
donald
On Thu, Jan 10, 2019 at 5:31 AM Albert López <alopez@ac.upc.edu> wrote:
Dear all,
We have an implementation of the LISP protocol and we are evaluating how easy would be to adapt it to be integrated in the FRRouting project. Our initial code has its own memory management, timers (task scheduling), ... In order to know how much of the code can be reused, I would like to know if it is really mandatory to use the memory management library provided by the FRRouting project or the task scheduling (for instance to send periodic control messages) to have the code accepted and merged in the FRRRouting project.
Another question we have is that our code is licensed under Apache 2. Is FRRouting license compatible with apache 2 ? I believe yes but I am not sure.
Best regards
Albert López
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev
-- Renato Westphal
participants (4)
-
Albert López -
Donald Sharp -
JR Rivers -
Renato Westphal