GSoC 2020: OFW Import To RTEMS License Issue
joel at rtems.org
Fri Jul 31 20:07:17 UTC 2020
On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
> In a recent review of these patches
> Gedare mentioned that we cannot use these patches with the
> current license. More details regarding the conversation can be
> found in the following archive.
> 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:
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
> 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. :(
> devel mailing list
> devel at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel