<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 4, 2020 at 3:47 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>> wrote:<br>
><br>
> I think for this one we can only hope that the original author agrees to<br>
> a re-licensing. Otherwise it is only possible to add a replacement.<br>
><br>
<br>
I suggest starting to make a plan for a clean room re-implementation.<br>
Ideally, one entity can extract the requirements from the current code<br>
or interface and write them up, so that another entity can<br>
re-implement the code from the written requirements. This is a little<br>
bit challenging in our situation, since the only entities that will<br>
write the code have already been exposed to the copyrighted version.<br>
(<a href="https://en.wikipedia.org/wiki/Clean_room_design" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Clean_room_design</a>) But we can still try<br>
our best!<br></blockquote><div><br></div><div>+1</div><div><br></div><div>IANAL but I don't expect hostility for having an independent implementation</div><div>of this interface anyway. This is likely just a case where the original author</div><div>has been unresponsive to the NetBSD Foundation and me. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Interfaces are not, in general, copyright-protected. So, the person<br>
that captures the requirements can rely on the interface, but needs to<br>
write the requirements for implementing the interface in their own<br>
words.<br></blockquote><div><br></div><div>Yep. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Gedare<br>
<br>
> On 04/08/2020 20:34, Niteesh G. S. wrote:<br>
> > ping.<br>
> ><br>
> ><br>
> > On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S. <<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a><br>
> > <mailto:<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
> > <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.<br>
> > <<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a> <mailto:<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a>>> wrote:<br>
> ><br>
> > Hello,<br>
> ><br>
> > In a recent review of these patches<br>
> > <a href="https://lists.rtems.org/pipermail/devel/2020-July/060653.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-July/060653.html</a><br>
> > Gedare mentioned that we cannot use these patches with the<br>
> > current license. More details regarding the conversation can be<br>
> > found in the following archive.<br>
> > <a href="https://lists.rtems.org/pipermail/devel/2020-July/061000.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-July/061000.html</a><br>
> ><br>
> > The following files have been ported to RTEMS to implement<br>
> > the OFW API.<br>
> > 1) openfirm.h -- BSD-4 License<br>
> > 2) openfirm.c -- BSD-4 License<br>
> > 3) ofw_fdt.c -- BSD-2 License<br>
> ><br>
> > The files with BSD4 cannot be used and Gedare suggested to<br>
> > check if we can remove the entire 4-clause cluster or remove<br>
> > clauses #3 and #4. I checked this along with the help of<br>
> > Christian<br>
> > and it seems that we can't remove those. Christian suggested<br>
> > that we can use the header file with the BSD-4 license to some<br>
> > extent but the source files to pose a problem. We also checked<br>
> > OpenBSD it has the same licensing.<br>
> ><br>
> ><br>
> > NetBSD appears to be the origin of the code and although I believe<br>
> > they did a largely blanket change from BSD-4, this code is old and<br>
> > normally, I would doubt they found the original submitter. Which<br>
> > would be odd in this case because this is his website with email:<br>
> ><br>
> > <a href="https://solfrank.net/Wolfgang/" rel="noreferrer" target="_blank">https://solfrank.net/Wolfgang/</a><br>
> ><br>
> > I have privately emailed to politely ask him to relicense it to<br>
> > BSD-2<br>
> > for use in RTEMS. And try to do that in a way that gets it on a<br>
> > path<br>
> > to get changed upstream.<br>
> ><br>
> > Hopefully this will solve it.<br>
> ><br>
> ><br>
> > Thanks for doing this Joel :).<br>
> ><br>
> ><br>
> ><br>
> > So we have come up with the following suggestions<br>
> > 1) Use the header files as it is.<br>
> ><br>
> ><br>
> > How close are you to being able to merge? Do we have time to let<br>
> > him answer?<br>
> ><br>
> ><br>
> > Yes, we do have a lot of time. All of my patches are based on the<br>
> > new build<br>
> > system so we won't be able to merge until the build system is<br>
> > merged. And<br>
> > also there are other things that have to be discussed regarding the<br>
> > patch.<br>
> ><br>
> ><br>
> ><br>
> > 2) Most OF_* functions defined in openfirm.c have 1:1 mapping<br>
> > with the FDT implementation in ofw_fdt.c so there is a<br>
> > possibility<br>
> > to remove openfirm.c and only use openfirm.h and ofw_fdt.c.<br>
> > For those functions which don't have a 1:1 mapping, we can add<br>
> > an implementation in ofw_fdt.c. And remove the functions which<br>
> > don't have an FDT based implementation eg. OF_write, OF_open<br>
> > etc.<br>
> ><br>
> > Also please remember that these patches were created with a goal<br>
> > to import the OFW into RTEMS and remove them from libBSD so<br>
> > will using the above approach has a chance of breaking libBSD<br>
> > compatibility in the future?<br>
> ><br>
> ><br>
> > Yikes. That would mean having to create our own files that are<br>
> > compatible but don't have the license issue.<br>
> ><br>
> > And that our implementation is in a source transparent form that<br>
> > allows updates easily from the upstream source.<br>
> ><br>
> > If we can't get relicense permission, I think we have to rewrite the<br>
> > BSD-4 code and provide compatible versions. :(<br>
> ><br>
> ><br>
> > As of now, this seems to be the only option but let's hope for someone<br>
> > to come up with a better approach or get the license relaxed.<br>
> ><br>
> > Thanks,<br>
> > Niteesh<br>
> ><br>
> ><br>
> ><br>
> > Thanks,<br>
> > Niteesh.<br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a> <mailto:<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> ><br>
</blockquote></div></div>