GSoC 2020: OFW Import To RTEMS License Issue

[Niteesh G. S.]

ping.


On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S. <niteesh.gs at gmail.com> wrote:

>
>
> On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. <niteesh.gs at gmail.com>
>> 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.
>>
>
> Thanks for doing this Joel :).
>
>>
>>
>>> 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?
>>
>
> Yes, we do have a lot of time. All of my patches are based on the new build
> system so we won't be able to merge until the build system is merged. And
> also there are other things that have to be discussed regarding the patch.
>
>>
>>
>>> 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. :(
>>
>
> As of now, this seems to be the only option but let's hope for someone
> to come up with a better approach or get the license relaxed.
>
> Thanks,
> Niteesh
>
>
>>
>>> Thanks,
>>> Niteesh.
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200805/cf9c747f/attachment.html>