SwiftDtoa: License / portability - a question and a hint.

[newbie-02]

hello @all, new here, sorry if I harm habits out of knowledge,

evtl. gnumeric would like to use SwiftDtoa,
evtl. slightly modified,
but gnumeric is licensed at users choice under GPL2 or GPL3,
from which GPL2 is said not compatible with Apache 2.0 ???
I'm not used to such matters, can anyone shed some light if there is
any option to manage this legally correct? Special allowance?
SwiftDtoa not affected by the incompatible paragraphs,
claims / patenting regulated therein? Or similar?
@tbkka: is it correct to deduce from the file history that you are the main author?
allowed to ask if you can allow use in gnumeric?

SwiftDtoa points out to care for portability, I got a hint that rows 790 - 793
and evtl. more might not be 'fully free portable', don't know about details,
just as a hint.

[tbkka]

...from which GPL2 is said not compatible with Apache 2.0 ???

You would need to talk to a lawyer about this.

SwiftDtoa points out to care for portability, I got a hint that rows 790 - 793 and evtl. more might not be 'fully free portable', ....

I don't see any issue with these lines:

    // Step 0: Deconstruct an IEEE 754 binary64 double-precision value
    uint64_t raw = *(const uint64_t *)d;
    int exponentBitPattern = (raw >> significandBitCount) & exponentMask;
    uint64_t significandBitPattern = raw & significandMask;
    int negative = raw >> 63;

This code builds and runs correctly on at least macOS, Windows, and Linux, on i386, x86_64, arm32, and arm64. In theory, there could be platforms where uint64_t and double have differing byte orders, but I've never seen one. If you have a specific platform where this fails, I'd be interested.

[newbie-02]

[ edit ] Wikipedia writes about the problems,
the point 'Floating Point' lists the problematic systems [ /edit ]

That was my thought too, different endianness conflicting with shifts?
I think I'd read something like that, and I think it could have been ARM
or MIPS ... but I'm really no pro for it. Search engine with 'cpu int double different byte order' looks promising, but is outside my area of expertise. For me it could be built on a Xeon without any problems.

Maybe you can ask Morten Welinder at gofficee issues he likes to be
short and to the point. You can see there that the issue is bothering
me / us for long time ...

Talking to a lawyer - I think if you talk to 3 you get 9 different opinions,
and their first question would be 'what does the author say'.
Suicide would also be an alternative. I think you wrote the code,
so the original copyright is yours, the Apache license is a general
rule that anyone can use the code, and probably contains some
restrictions that are not compatible with GPL2. Since gnumeric can't
or won't change its license policy, a simple way out - in my opinion -
would be that you allow to use the code, and specify individually
if you want to be named as author, if the connection to Swift should
be mentioned ...

Maybe the easiest way would bet that you provide it as a patch to goffice / gnumeric?

Unless the code does not belong to you but to a company, then it
gets more complicated of course.

[grynspan]

There doesn't appear to be an actionable change here. May I suggest taking your discussion to the Swift Forums? Swift uses the Apache 2.0 license intentionally and switching to the GPL is not planned.

[tbkka]

[ edit ] Wikipedia writes about the problems, the point 'Floating Point' lists the problematic systems [ /edit ]

Quoting from that article:

However, on modern standard computers (i.e., implementing IEEE 754), one may safely assume that the endianness is the same for floating-point numbers as for integers, making the conversion straightforward regardless of data type.

[newbie-02]

@grynspan:
It was not! the question to change the licensing of swift, it was the question if dtoa can be used with relaxed restrictions.
In the meantime gnumeric implemented ryu.
@tbkka:
It was just mentioned as SwiftDtoa explicitly demands portability, and is just a question how fanatic one wants to cover exotic systems.

[newbie-02]

@tbkka:
just for completeness, a report about a real world incident with such problem:
Bug 350973 - [ARM] Mangled floating point constants
I know it's old, but was told recently that ARM processors are becoming important actually.

[tbkka]

This code has been tested on Linux, Darwin/XNU, and FreeBSD on 32-bit and 64-bit ARM and works correctly on all of them. If I understand that report correctly:

• This was a problem 15 years ago on Linux systems using the now-mostly-defunct "hard float" ABI and is not a problem with the armeabi ABI being used by current 32-bit ARM Linux.
• There's no reliable way to check for this at compile time because it depends on the runtime ABI.

I'll consider adding a runtime assertion to catch byte-ordering mismatches. That will at least ensure that any issues here are detected promptly.

[newbie-02]

hello @tbkka,
thanks for caring,
that's beyond my level of technical knowledge,
but sounds meaningful ... :-)