On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. <[email protected]> wrote:
> Hello, > > In a recent review of these patches > https://lists.rtems.org/pipermail/devel/2020-July/060653.html > Gedare mentioned that we cannot use these patches with the > current license. More details regarding the conversation can be > found in the following archive. > https://lists.rtems.org/pipermail/devel/2020-July/061000.html > > The following files have been ported to RTEMS to implement > the OFW API. > 1) openfirm.h -- BSD-4 License > 2) openfirm.c -- BSD-4 License > 3) ofw_fdt.c -- BSD-2 License > > The files with BSD4 cannot be used and Gedare suggested to > check if we can remove the entire 4-clause cluster or remove > clauses #3 and #4. I checked this along with the help of Christian > and it seems that we can't remove those. Christian suggested > that we can use the header file with the BSD-4 license to some > extent but the source files to pose a problem. We also checked > OpenBSD it has the same licensing. > NetBSD appears to be the origin of the code and although I believe they did a largely blanket change from BSD-4, this code is old and normally, I would doubt they found the original submitter. Which would be odd in this case because this is his website with email: https://solfrank.net/Wolfgang/ I have privately emailed to politely ask him to relicense it to BSD-2 for use in RTEMS. And try to do that in a way that gets it on a path to get changed upstream. Hopefully this will solve it. > So we have come up with the following suggestions > 1) Use the header files as it is. > How close are you to being able to merge? Do we have time to let him answer? > 2) Most OF_* functions defined in openfirm.c have 1:1 mapping > with the FDT implementation in ofw_fdt.c so there is a possibility > to remove openfirm.c and only use openfirm.h and ofw_fdt.c. > For those functions which don't have a 1:1 mapping, we can add > an implementation in ofw_fdt.c. And remove the functions which > don't have an FDT based implementation eg. OF_write, OF_open etc. > > Also please remember that these patches were created with a goal > to import the OFW into RTEMS and remove them from libBSD so > will using the above approach has a chance of breaking libBSD > compatibility in the future? > Yikes. That would mean having to create our own files that are compatible but don't have the license issue. And that our implementation is in a source transparent form that allows updates easily from the upstream source. If we can't get relicense permission, I think we have to rewrite the BSD-4 code and provide compatible versions. :( > > Thanks, > Niteesh. > _______________________________________________ > devel mailing list > [email protected] > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list [email protected] http://lists.rtems.org/mailman/listinfo/devel
