GSoC 2020: OFW Import To RTEMS License Issue

Joel Sherrill joel at rtems.org
Wed Aug 5 13:59:58 UTC 2020


On Tue, Aug 4, 2020 at 3:47 PM 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!
>

+1

IANAL but I don't expect hostility for having an independent implementation
of this interface anyway. This is likely just a case where the original
author
has been unresponsive to the NetBSD Foundation and me.

>
> 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.
>

Yep.

>
> 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200805/3d988bc0/attachment.html>


More information about the devel mailing list