> -----Original Message----- > From: Chris Johns [mailto:chr...@rtems.org] > Sent: Thursday, June 11, 2020 2:26 AM > To: Sommer, Jan; mritunjaysharma...@gmail.com > Cc: rtems-de...@rtems.org > Subject: Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This > time building for xilinx_zynq_a9_qemu > > On 5/6/20 6:03 pm, jan.som...@dlr.de wrote: > > We came across the PPSi library for PTP support some time ago: > https://ohwr.org/project/ppsi > > In their documentation its says they started with ptpd and then made an > overhaul of the source code. > > Interesting. Did you check the licenses and authors? > > A search for "ptp v2.1.0" lists PTP v2.1.0 in SF and github. The github repo > seems a more recent version of the SF repo but they seem similar.
In the PPSi manual they write: "The algorithm and computation routines regarding the basic ieee 1588 are derived from the PTPd project, v.2.1.0 (see AUTHORS for details about copyright); but as of March 2013 very little remains of the original code base." In their AUTHORS file they seem to have copied the information from here: https://sourceforge.net/p/ptpd/code/HEAD/tree/branches/ptpd-2.1.1/COPYRIGHT >The PPSi code is GPLv2 and the SF and github code is 2C-BSD and the list of >copyright > holders is different. > Most of it seems to be LGPL with 2 exceptions according to the manual: "The code is licensed according to the GNU LGPL, version 2.1 or later. Some files are individually released to the public domain, when we think they are especially simple or generic. Both the full and the partial printf code is distributed according to the GPL-2, as it comes from the Linux kernel. This means that any code using our diagnostics fall under the GPL requirements; you may compile and use the diagnostic code internally with your own proprietary code but you can’t distribute binaries with diagnostics without the complete source code and associated rights. You may avoid the GPL requirements by using different printf implementations; if so we’d love to have them contributed back in the package. The same issue about the GPL license applies to the div64_32 function. We need this implementation in our wrpc code base because the default libgcc division is very big, and we are always tight with our in-FPGA memory space." It would have been nice if this information would be more prominent in their repository and not hidden in the manual. Cheers, Jan > > They also claim portability as one of their goals. We haven't had time to > look at it closer yet, but the projects looks a bit more active and seems to > have the CERN behind it. > > Then I hope the copyright is in order. > > > Maybe it is worth checking out, if ptpd keeps making trouble. > > It is GPL when the other code I have looked at it BSD. > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
