GSoC 2020: OFW Import To RTEMS License Issue
Gedare Bloom
gedare at rtems.org
Sat Aug 8 14:05:36 UTC 2020
On Sat, Aug 8, 2020 at 2:48 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
>
> Hello,
>
> So if I understand correctly, we will be having the following files
> under RTEMS.
>
> 1) rtems-ofw.h / rtems-ofw.c These files will contain the RTEMS
> friendly implementation of the OF interface.
> For eg:
>
> rtems_ofw_find_device(phandle_t node)
>
> here I plan to implement all the functions that are required by the
> original openfirm API and also few auxiliary functions which will be
> helpful while implementing drivers.
>
yes
> 2) openfirm.h This will provide the interface for libBSD and ported
> drivers in RTEMS. And we will have to install openfirm.h for libBSD.
>
> And also please remember that the openfirm.c in libBSD creates
> xref to node handle structure for efficient translation. And the libBSD
> drivers depend on this so if we remove these, the libBSD drivers will
> not work. [1]
> So we can not remove the openfirm.c completely.
>
ok.
Another thought occurs, you can dig through the bsd history and find
the original source file with the 4-BSD clause. That will let you know
what is covered by that license. It may be a lot of this code has been
rewritten or is under the newer 2-BSD with the other contributor's
licensing.
>
> [1]: https://github.com/freebsd/freebsd/blob/c07cb50dbbf88e174e93f344a820fff68d24778d/sys/dev/ofw/openfirm.c#L119
>
>
> On Fri, Aug 7, 2020 at 6:28 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> 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