GSoC 2020: OFW Import To RTEMS License Issue

Gedare Bloom gedare at rtems.org
Fri Aug 7 12:57:48 UTC 2020 

On Fri, Aug 7, 2020 at 3:25 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
>
> On Wed, Aug 5, 2020 at 2:16 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer <oss at c-mauderer.de> wrote:
>> >
>> > I think for this one we can only hope that the original author agrees to
>> > a re-licensing. Otherwise it is only possible to add a replacement.
>> >
>>
>> I suggest starting to make a plan for a clean room re-implementation.
>> Ideally, one entity can extract the requirements from the current code
>> or interface and write them up, so that another entity can
>> re-implement the code from the written requirements. This is a little
>> bit challenging in our situation, since the only entities that will
>> write the code have already been exposed to the copyrighted version.
>> (https://en.wikipedia.org/wiki/Clean_room_design) But we can still try
>> our best!
>>
>> Interfaces are not, in general, copyright-protected. So, the person
>> that captures the requirements can rely on the interface, but needs to
>> write the requirements for implementing the interface in their own
>> words.
>
>
> You mentioned about providing an RTEMS friendly API for openfirm if we
> want to implement openfirm in RTEMS and make the interface public to
> avoid namespace pollution.
> I have a few questions regarding this.
>
> 1) what about the imported drivers? The main reason for importing openfirm
> into RTEMS was to reduce the number of modifications done to the imported
> driver. So will we have two interfaces, one that is RTEMS-friendly and another
> that provides the same interface as in openfirm?
>
> 2) What about libBSD? If we implement it in RTEMS we can remove it from
> libBSD after thorough testing. This case is related to previous, libBSD expects
> the interface provided by openfirm.h, you also mentioned about handling
> FreeBSD-compat by providing macros
> i.e: #define OF_finddevice rtems_ofw_find_device
> This redefinition should be in RTEMS, right? because if we have it libBSD
> we will need to have two redefinitions one in RTEMS to support the imported
> drivers and others in libBSD.

The redefinition approach can be implemented in a header file (e.g.,
openfirm.h) included by drivers and by libbsd to address both of your
points. As long as they aren't trying to access OF_finddevice by a
linked/indirect function call which requires the symbol to exist.
(Only a real problem for binary blobs, which could be solved by the
application developer by providing instead some kind of openfirm.c
that just calls the OF_* functions.)

We just need to be a bit careful about the namespace. It is possible
to add an OF_* interface, but we need to eliminate other options
first.

>>
>>
>> Gedare
>>
>> > On 04/08/2020 20:34, Niteesh G. S. wrote:
>> > > ping.
>> > >
>> > >
>> > > On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S. <niteesh.gs at gmail.com
>> > > <mailto:niteesh.gs at gmail.com>> wrote:
>> > >
>> > >
>> > >
>> > >     On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <joel at rtems.org
>> > >     <mailto:joel at rtems.org>> wrote:
>> > >
>> > >
>> > >
>> > >         On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
>> > >         <niteesh.gs at gmail.com <mailto: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 <mailto:devel at rtems.org>
>> > >             http://lists.rtems.org/mailman/listinfo/devel
>> > >
>> > >
>> > > _______________________________________________
>> > > devel mailing list
>> > > devel at rtems.org
>> > > http://lists.rtems.org/mailman/listinfo/devel
>> > >

More information about the devel mailing list