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