Re: Is the APSL 2.0 DFSG-compliant?
Mihai wrote:
>
>* On 8/5/22 01:09, Ben Westover wrote:
>> Those are based on conversations that are almost a decade old, and some
>> things have changed since then. I just wanted a re-review of the license
>> in 2022 to see if the complaints from before still hold up today.
>
>I can see how the outcome of, e.g., legal disputes can change the view on a
>license over time, especially since this would indicate practical application
>and interpretation of a license. Your request is understandable.
>
>I am, as a layman, still having a hard time understanding why any version of the
>APSL license would be considered free in the first place, since it certainly
>contains a discrimination clause in section 8:
>
>> You acknowledge that the Covered Code is not intended for use in the
>> operation of nuclear facilities, aircraft navigation, communication
>> systems, or air traffic control machines in which case the failure of
>> the Covered Code could lead to death, personal injury, or severe
>> physical or environmental damage.
>
>This directly contradicts freedom 0 and has been part of any APSL version, only
>slightly modified in wording ("Covered Code" vs. "Original Code" in previous
>versions), from version 1.0 to 2.0.
That's not a restriction, though. It's *not* saying "you may not use
this software for XXX", it's saying "this software is not intended for
XXX". There's quite a difference there IMHO.
>Daniel Hakimi pointed out a way of interpretation for which this would not be
>problematic due to internal contradiction:
>
>> Perhaps the OSI and FSF interpret this as only relating to the warranty...
>> But there is no warranty.
>
>Another way of interpreting this is by taking the words "not intended for use
>in" literally and arguing that as long as the author of the software does not
>intend the software to be used in these fields, everything is fine. However,
>that falls short to the actual deployment, which is also covered by this
>license, and the term also applies to purely users/integrators. In such a case,
>you, as a user/integrator, could claim that the usage in these fields was *not
>intended*, but *accidentally occurred*.
>
>Now, obviously, these arguments are not very convincing, but crucially, I have
>not found any statement from the FSF as to why they have deemed this subsection
>to be a non-problem. I might just go ahead and ask them directly.
I think it's lawyer-speak CYA. There's nothing magic there.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"We're the technical experts. We were hired so that management could
ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Reply to: