* 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.
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.
In the thread started by John Paul Adrian Glaubitz in 2020 regarding the APSL
1.2, one issue I had with the license was the practical implications employed by
section 2.2 (c) (2.0 version):
> (c) If You Externally Deploy Your Modifications, You must make
> Source Code of all Your Externally Deployed Modifications either
> available to those to whom You have Externally Deployed Your
> Modifications, or publicly available. Source Code of Your Externally
> Deployed Modifications must be released under the terms set forth in
> this License, including the license grants set forth in Section 3
> below, for as long as you Externally Deploy the Covered Code or twelve
> (12) months from the date of initial External Deployment, whichever is
> longer. You should preferably distribute the Source Code of Your
> Externally Deployed Modifications electronically (e.g. download from a
> web site).
Compare this to the GPL 2:
> 3. You may copy and distribute the Program (or a work based on it, under
> Section 2) in object code or executable form under the terms of Sections 1
> and 2 above provided that you also do one of the following:
>
> a) Accompany it with the complete corresponding machine-readable source
> code, which must be distributed under the terms of Sections 1 and 2
> above on a medium customarily used for software interchange; or,
> b) Accompany it with a written offer, valid for at least three years, to
> give any third party, for a charge no more than your cost of physically
> performing source distribution, a complete machine-readable copy of the
> corresponding source code, to be distributed under the terms of Sections
> 1 and 2 above on a medium customarily used for software interchange; or,
> c) Accompany it with the information you received as to the offer to
> distribute corresponding source code. (This alternative is allowed only
> for noncommercial distribution and only if you received the program in
> object code or executable form with such an offer, in accord with
> Subsection b above.)
The difference between having to make source code available unconditionally (to
users or publicly, which thankfully is an or-condition) vs. upon request can be
a huge one. Contrary to what I have written for APSL 1.2 in 2020, APSL 2.0's
section is compatible with the DFSG as far as I can see, so this is not a
concern, but practically, APSL 2.0 can be inconvenient. Imagine Debian was
forced to stop distribution of source and binary forms. In such a case, to stay
conformant with the license, it would need to find a way to continue
distributing APSL-2.0-licensed source code publicly, for practical matters, to
meet the twelve months requirement. For GPL-2-licensed software, it would be
enough to have somebody available to handle requests for source code on a
case-by-case basis.
Then again, maybe I am misinterpreting the ASPL 2.0, since it does not
explicitly mention how to make source code available to those to whom the
software was deployed to and case-by-case distribution upon request is likewise
not explicitly mentioned or forbidden. If that is the case, then the only
actual, practical, difference is the time period, which is more lenient for APSL
2.0.
Note that the common argument of "distributing source code along binary code",
which would circumvent the requirement to make source code publicly or
semi-publicly available, is good and true in its core, but not a practical one
for software distributors that provide binary packages as the primary means of
installation, since the binary packages are almost never accompanied by source
code. Practically, Debian will always need to make source code available
externally, unless we require bundling source code with APSL-2.0-licensed binary
works.
Again, these thoughts are merely ones pertaining to practicability, not DFSG
compatibility. It is, however, not inconceivable that FTP Master would reject
software based on practical reasons, even if the license itself is DFSG-compatible.
Lastly, and as a side note, I would like to point out that I do not have a
personal agenda against Apple's or APSL-licensed software. I do find software
such as hfsprogs useful and occasionally used them myself. As an example,
hfsprogs has been packaged for a while now and is part of the non-free section,
which is good to have.
Mihai
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature