On Tue, Aug 4, 2020 at 12:38 PM Christian Mauderer <o...@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...@gmail.com > > <mailto:niteesh...@gmail.com>> wrote: > > > > > > > > On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill <j...@rtems.org > > <mailto:j...@rtems.org>> wrote: > > > > > > > > On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S. > > <niteesh...@gmail.com <mailto:niteesh...@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@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
