On Wed, Aug 5, 2020 at 2:16 AM 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! > > 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. > You mentioned about providing an RTEMS friendly API for openfirm if we want to implement openfirm in RTEMS and make the interface public to avoid namespace pollution. I have a few questions regarding this. 1) what about the imported drivers? The main reason for importing openfirm into RTEMS was to reduce the number of modifications done to the imported driver. So will we have two interfaces, one that is RTEMS-friendly and another that provides the same interface as in openfirm? 2) What about libBSD? If we implement it in RTEMS we can remove it from libBSD after thorough testing. This case is related to previous, libBSD expects the interface provided by openfirm.h, you also mentioned about handling FreeBSD-compat by providing macros i.e: #define OF_finddevice rtems_ofw_find_device This redefinition should be in RTEMS, right? because if we have it libBSD we will need to have two redefinitions one in RTEMS to support the imported drivers and others in libBSD. > > 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
