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.
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
