Am 01.11.2013 um 03:49 schrieb Jeff Epler <[email protected]>: > On Thu, Oct 31, 2013 at 09:03:08PM +0100, Michael Haberler wrote: >> >> Am 31.10.2013 um 20:38 schrieb Jeff Epler <[email protected]>: >> >>> Why not start by fixing new files in src/ with gnu-style copyright >>> blocks? >> >> I already committed to take this on. > > Great. I didn't see the commit, sorry for ragging on you. > >>> We can have an argument about "configuration files" and >>> licenses later. >>> >>> The problem I'm worried is tougher is the files in UB which are clearly >>> marked with licenses that are not GPL-compatible (the "All rights >>> reserved" files in xeno_math). >> >> This directory defines a kernel module which started as a copy of the >> rtai_math subtree of the RTAI distribution as it stands, and uses a subset >> of the files therein. >> >> If that is actually an issue, then it is an issue for the RTAI kernel as >> currently distributed by linuxcnc.org as well. >> >> If the answer to this question is 'well it isnt an issue for RTAI for reason >> X', say because it's distributed as different package, then the answer for >> xeno_math is to package it separately I would assume, but not some license >> tagging. > > Well sh--. We'll need to address this now that we're aware of it. I > absolutely agree it's a problem in our rtai package as well. If you can > determine that this problem still affects current rtai, then we need to > make them aware of this issue. Do you feel you have a contact with whom > you'd like to raise it? I don't have any contacts in rtai, though I > could raise it on the public list.
I met Paolo at the Lugano RTLWS meeting, he certainly will reply I assume; other than that I'd the list is the place to ask rough guess: zero changes between the time I fetched rtai_math and now but I should check just to be sure on the files below: I did construct the list of files to be added to xeno_math by trial and error, i.e. every time some run created an undefined symbol error I added the relevant function; so I think the list in xeno_math is actually the minimum set needed. Also I think there is some cross-referencing between files; I dimly remember scalb is such a case alternatively we might just use files from eglibc, which is LGPL and might have most of what we need: see http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_14/libc/math/ it might actually be easier/faster to rename xeno_math to kmath and build from license-clean files for both rtai and xenomai-kernel -m ps: I'm currently under state of siege by visitors, I get around to working more systematically only end of next week > > In our rtai package for Hardy, I now have a list of 8 files that I am > aware of with Apple "All Rights Reserved" as the only declaration of > rights: > rtai-3.8.1/base/math/ceilfloor.c > rtai-3.8.1/base/math/fpmacros.c > rtai-3.8.1/base/math/fpP.h > rtai-3.8.1/base/math/frexpldexp.c > rtai-3.8.1/base/math/logb.c > rtai-3.8.1/base/math/rndint.c > rtai-3.8.1/base/math/scalb.c > rtai-3.8.1/base/math/sign.c > Of those, all but these > rtai-3.8.1/base/math/fpmacros.c > rtai-3.8.1/base/math/fpP.h > rtai-3.8.1/base/math/rndint.c > are noops except when defined(__ppc__), so they contribute no object > code to our rtai binary package. > > "fpmacros.c" implements __fpclassifyf, __fpclassify, __isnormalf, > __isnorma (sic), __isfinitef, __isfinite, __isnanf, __isnan, __signbitf, > __signbit. None of these are used in linuxcnc, though we have an > independent implementation of __isnan. GCC intrinsics can provide most > or all of these if we turn out to need them. > > "fpP.h" is only included in "fpmacros.c", so this one can go away. > > "rndint.c" implements rint, nearbyint, rinttol, round, roundtol, trunc, > modf (some only when __ppc__). Again, none of those appear to be used > in linuxcnc realtime, though we have a prototype for round in rtapi_math.h. > > So unless my analysis is wrong, we should simply excise these from our > rtai (fixing up the makefiles as required), rebuild, make sure linuxcnc > still works, and issue a new rtai package. > > The same analysis probably applies to the copies in UB unless somebody > really intends on supporting ppc -- just nuke it, it's cruft. whoopsie, > etc. > > Jeff > > ------------------------------------------------------------------------------ > Android is increasing in popularity, but the open development platform that > developers love is also attractive to malware creators. Download this white > paper to learn more about secure code signing practices that can help keep > Android apps secure. > http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
