GSoC 2020: OFW Import To RTEMS License Issue

Tue Aug 4 20:46:48 UTC 2020

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.

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