On Tue, Aug 4, 2020 at 3:47 PM Gedare Bloom <ged...@rtems.org> wrote:
> 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! > +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...@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
