<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Best regards</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">Albert López<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">On 10/1/19 17:14, JR Rivers wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEsrGHqNR-5nQV8Xfm6OhkoJWxAUpK8kc2Ld2Hsw7Ge3Z+o5bw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr"><br>
            <div>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.  </div>
            <div><br>
            </div>
            <div>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.</div>
            <div><br>
            </div>
            <div>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...</div>
            <div><br>
            </div>
            <div><a
href="https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html"
                moz-do-not-send="true">https://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html</a><br>
            </div>
            <div><br>
            </div>
            <div>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.<br>
            </div>
            <div><br>
            </div>
            <div>cheers, JR</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">On Thu, Jan 10, 2019 at 5:13 AM Renato Westphal
          <<a href="mailto:renato@opensourcerouting.org"
            target="_blank" moz-do-not-send="true">renato@opensourcerouting.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Exciting
          news, a LISP implementation in FRR would be amazing!<br>
          <br>
          Regarding your questions, here are my two cents:<br>
          * FRR's CLI and zclient code are tightly coupled to the FRR
          event loop<br>
          (lib/thread.[ch]), and this essentially makes it impossible
          for a<br>
          daemon to use a different event loop. ldpd and nhrpd used
          libevent and<br>
          libev, respectively, and both had to be converted to use FRR's
          event<br>
          library.<br>
          * Not using FRR's memory management should be fine (ldpd
          doesn't use<br>
          it for instance, and other daemons use it only partially).<br>
          * Our documentation says the Apache 2.0 and GPLv2 licenses are<br>
          incompatible [1] unfortunately. Maybe JR and David can provide
          you<br>
          guidance on how to solve this problem.<br>
          <br>
          Best Regards,<br>
          Renato.<br>
          <br>
          [1] <a
href="http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license-for-contributions"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://docs.frrouting.org/projects/dev-guide/en/latest/workflow.html#license-for-contributions</a><br>
          <br>
          On Thu, Jan 10, 2019 at 10:39 AM Donald Sharp<br>
          <<a href="mailto:sharpd@cumulusnetworks.com"
            target="_blank" moz-do-not-send="true">sharpd@cumulusnetworks.com</a>>
          wrote:<br>
          ><br>
          > Albert -<br>
          ><br>
          > If you already have your own infrastructure there is no
          need to use<br>
          > ours.  I think the only real requirement is the usage of
          our ZAPI<br>
          > protocol for talking to the RIB(zebra).  This is
          especially true if<br>
          > there is going to be active ongoing maintenance from your
          end.<br>
          ><br>
          > As for licensing I've added JR and David who are both
          better than me<br>
          > on licensing and their implications.  I'll let them speak
          up.<br>
          ><br>
          > donald<br>
          ><br>
          > On Thu, Jan 10, 2019 at 5:31 AM Albert López <<a
            href="mailto:alopez@ac.upc.edu" target="_blank"
            moz-do-not-send="true">alopez@ac.upc.edu</a>> wrote:<br>
          > ><br>
          > > Dear all,<br>
          > ><br>
          > > We have an implementation of the LISP protocol and
          we are evaluating how<br>
          > > easy would be to adapt it to be integrated in the
          FRRouting project. Our<br>
          > > initial code has its own memory management, timers
          (task scheduling),<br>
          > > ... In order to know how much of the code can be
          reused, I would like to<br>
          > > know if it is really mandatory to use the memory
          management library<br>
          > > provided by the FRRouting project or the task
          scheduling (for instance<br>
          > > to send periodic control messages) to have the code
          accepted and merged<br>
          > > in the FRRRouting project.<br>
          > ><br>
          > > Another question we have is that our code is
          licensed under Apache 2. Is<br>
          > > FRRouting license compatible with apache 2 ? I
          believe yes but I am not<br>
          > > sure.<br>
          > ><br>
          > > Best regards<br>
          > ><br>
          > > Albert López<br>
          > ><br>
          > ><br>
          > > _______________________________________________<br>
          > > dev mailing list<br>
          > > <a href="mailto:dev@lists.frrouting.org"
            target="_blank" moz-do-not-send="true">dev@lists.frrouting.org</a><br>
          > > <a href="https://lists.frrouting.org/listinfo/dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.frrouting.org/listinfo/dev</a><br>
          ><br>
          > _______________________________________________<br>
          > dev mailing list<br>
          > <a href="mailto:dev@lists.frrouting.org" target="_blank"
            moz-do-not-send="true">dev@lists.frrouting.org</a><br>
          > <a href="https://lists.frrouting.org/listinfo/dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.frrouting.org/listinfo/dev</a><br>
          <br>
          <br>
          <br>
          -- <br>
          Renato Westphal<br>
        </blockquote>
      </div>
    </blockquote>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">
</pre>
  </body>
</html>