GSoC 2020: OFW Import To RTEMS License Issue

[Christian Mauderer]

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.

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
>