Re: Is the APSL 2.0 DFSG-compliant?

[Francesco Poli]

On Fri, 5 Aug 2022 10:32:06 +0200 Mihai Moldovan wrote:

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

Please note that Debian satisfies section 3 of the GNU GPL v2 by
choosing subsection 3a, not 3b!

Debian is not making written offers to provide source.
Debian is making source available for download on the same archive (and
mirrors) where the binary can be downloaded from.
The FSF has [clarified] that this suffices to satisfy subsection 3a.

[clarified]: 


As a consequence, in your hypothetical scenario where Debian is forced
to stop distribution of software, Debian would have no further
obligations for GPLv2-licensed software.

On the other hand, Debian would be forced to still make source
available for at least 12 months from the date of the initial "External
Deployment" of any APSL-v2.0-licensed software.

I think this is a huge difference: the GPLv2 allows you to follow a
strategy, where you have already satisfied all your obligations and
have no future requirements to worry about.
The APSL-v2.0 does not.

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

As I have said above, I think the difference is definitely bigger.

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

Re: Is the APSL 2.0 DFSG-compliant?

[Steve McIntyre]

On Fri, Aug 05, 2022 at 10:49:05AM +, Stephan Verbücheln wrote:
>On Fri, 2022-08-05 at 10:31 +0100, Steve McIntyre wrote:
>> 
>> 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.
>
>To me it sounds like a more explicit “No Warranty” clause for critical
>applications.

Yup, exactly.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Re: Is the APSL 2.0 DFSG-compliant?

[Stephan Verbücheln]

On Fri, 2022-08-05 at 10:31 +0100, Steve McIntyre wrote:
> 
> 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.

To me it sounds like a more explicit “No Warranty” clause for critical
applications.

Regards

Re: Is the APSL 2.0 DFSG-compliant?

[Steve McIntyre]

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

Re: Is the APSL 2.0 DFSG-compliant?

[Mihai Moldovan]

* 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 

Re: Is the APSL 2.0 DFSG-compliant?

[Stephan Verbücheln]

On Fri, 2022-08-05 at 08:25 +0800, Paul Wise wrote:
> I wouldn't put any weight on the presence of the APSL 2.0 license
> text
> in the archive, probably it got into Debian in those packages due to
> lack of copyright/license review rather than deliberate acceptance,
> especially since it is in one of the many code copies in both of
> them.

There could also be cases of dual-licensing.

Regards

Re: Is the APSL 2.0 DFSG-compliant?

[Stephan Verbücheln]

> Interesting, the APSL 2.0 is seen in some relatively important
> packages like Chromium and QtWebEngine.

What code is exactly under that license? As far as I know, WebKit
itself (which Chromium is a fork of) is licensed under LGPL (KDE code)
and 2-clause BSD (Apple code).

In your example of Chromium, it appears to be “XNU” and “Cross-Platform
Mach Interface Generator (mig)”.

https://sources.debian.org/src/chromium/103.0.5060.134-1/third_party/mig/README.chromium/

So for Debian GNU/Linux, it could be easily removed and ignored.
However, Debian GNU/Darwin might want to have those libraries.

Regards

Re: Is the APSL 2.0 DFSG-compliant?

[Walter Landry]

Ben Westover writes:
> On August 5, 2022 1:03:18 AM EDT, Walter Landry  wrote:
>>As someone who participated in that original exchange in 2004, APSL 2.0
>>still looks impossible to follow.  If Debian suddenly goes off-line,
>>Debian is not in compliance with the license.
>
> How exactly does Debian "go off-line", with so many mirrors and other
> forms of redundancy?

The long arm of the law can make that happen.  Whatever problems Debian
may have with the law, that does not excuse its obligations under the
license.

But that is just if Debian wanted to distribute the code in non-free.
For the main archive, the DFSG is a guarantee for the users.  I know
that if I, as an individual, get code from main and distribute changes,
at most I will have to publish the corresponding source at the same
time.  The APSL requires me, personally, to make the corresponding
source available for 12 months.  I can not just take down my website and
work on a farm.

>>For all of the other
>>licenses, offering the source at the same time is sufficient.  For APSL
>>2.0, Debian has to keep the source archive up for at least 12 months
>>since it last published a modification.
>
> Doesn't the GPL2 mandate three years of distribution for non-personal
> modifications?

No.  If you distribute the corresponding source at the same time, that
is enough.

Cheers,
Walter Landry

Re: Is the APSL 2.0 DFSG-compliant?

[Ben Westover]

Hi Walter,

On August 5, 2022 1:03:18 AM EDT, Walter Landry  wrote:
>As someone who participated in that original exchange in 2004, APSL 2.0
>still looks impossible to follow.  If Debian suddenly goes off-line,
>Debian is not in compliance with the license.

How exactly does Debian "go off-line", with so many mirrors and other forms of 
redundancy?

>For all of the other
>licenses, offering the source at the same time is sufficient.  For APSL
>2.0, Debian has to keep the source archive up for at least 12 months
>since it last published a modification.

Doesn't the GPL2 mandate three years of distribution for non-personal 
modifications?

--
Ben Westover

signature.asc
Description: PGP signature

Re: Is the APSL 2.0 DFSG-compliant?

[Walter Landry]

Ben Westover writes:

> Hello,
>
> On 8/4/22 8:30 PM, Paul Wise wrote:
>> What would have changed since the 2004 review of APSL 2.0?
>
> Here's a quote from that 2020 challenge of the APSL-1.2 being considered
> non-free in 2001:
>
>> For the APSL-1.2, it seems that the only clause that makes the
>> license non-DFSG-compliant is this one:
>>
>>> (c)  You must make Source Code of all Your Deployed Modifications
>>>  publicly available under the terms of this License, including
>>>  the license grants set forth in Section 3 below, for as long as
>>>  you Deploy the Covered Code or twelve (12) months from the date
>>>  of initial Deployment, whichever is longer. You should
>>>  preferably distribute the Source Code of Your Deployed
>>>  Modifications electronically (e.g. download from a web site);
>>
>> It was claimed in [6] that this clause makes the APSL-1.2
>> non-DFSG-compliant as it's not possible for Debian to keep every
>> single modification around for at least 12 months.
>>
>> This claim may have been valid in 2001, but I think it does not hold
>> up for 2020 since source code to packaging in Debian is usually
>> maintained in Salsa or Github and therefore keeping all modifications
>> available for 12 months and longer, plus there is Debian Snapshots [7]
>> which keeps a older versions of a package around as well - including
>> source code.
>
> Things like this make me question whether the 2004 decision to consider
> the APSL 2.0 non-DFSG-compliant is still valid in 2022. In fact, after
> reading through the thread [1] the wiki references making the APSL 2.0
> incompatible with the DFSG, I'm not so sure it does that. IANAL, but
> from what I could understand it seemed that there was a good argument
> that the alleged non-DFSG clauses actually *did* comply with the DFSG,
> and that argument wasn't fully refuted. The wiki references one other
> thread, but that thread is specifically about the APSL 1.2, which the
> APSL 2.0 fixes the issues of according to the FSF. That thread was
> finished about two years before the APSL 2.0 came into existence.

As someone who participated in that original exchange in 2004, APSL 2.0
still looks impossible to follow.  If Debian suddenly goes off-line,
Debian is not in compliance with the license.  For all of the other
licenses, offering the source at the same time is sufficient.  For APSL
2.0, Debian has to keep the source archive up for at least 12 months
since it last published a modification.

Cheers,
Walter Landry

Re: Is the APSL 2.0 DFSG-compliant?

[Ben Westover]

Hello,

On 8/4/22 8:30 PM, Paul Wise wrote:
> What would have changed since the 2004 review of APSL 2.0?

Here's a quote from that 2020 challenge of the APSL-1.2 being considered
non-free in 2001:

> For the APSL-1.2, it seems that the only clause that makes the
> license non-DFSG-compliant is this one:
>
>> (c)  You must make Source Code of all Your Deployed Modifications
>>  publicly available under the terms of this License, including
>>  the license grants set forth in Section 3 below, for as long as
>>  you Deploy the Covered Code or twelve (12) months from the date
>>  of initial Deployment, whichever is longer. You should
>>  preferably distribute the Source Code of Your Deployed
>>  Modifications electronically (e.g. download from a web site);
>
> It was claimed in [6] that this clause makes the APSL-1.2
> non-DFSG-compliant as it's not possible for Debian to keep every
> single modification around for at least 12 months.
>
> This claim may have been valid in 2001, but I think it does not hold
> up for 2020 since source code to packaging in Debian is usually
> maintained in Salsa or Github and therefore keeping all modifications
> available for 12 months and longer, plus there is Debian Snapshots [7]
> which keeps a older versions of a package around as well - including
> source code.

Things like this make me question whether the 2004 decision to consider
the APSL 2.0 non-DFSG-compliant is still valid in 2022. In fact, after
reading through the thread [1] the wiki references making the APSL 2.0
incompatible with the DFSG, I'm not so sure it does that. IANAL, but
from what I could understand it seemed that there was a good argument
that the alleged non-DFSG clauses actually *did* comply with the DFSG,
and that argument wasn't fully refuted. The wiki references one other
thread, but that thread is specifically about the APSL 1.2, which the
APSL 2.0 fixes the issues of according to the FSF. That thread was
finished about two years before the APSL 2.0 came into existence.

I just want to reopen the issue of whether or not the APSL 2.0, not 1.2,
is DFSG-compliant, reviewing it fully instead of relying on a
questionable decision made in 2001/4.

Thanks,
--
Ben Westover

[1]: https://lists.debian.org/debian-legal/2004/06/msg00573.html


OpenPGP_signature
Description: OpenPGP digital signature

Re: Is the APSL 2.0 DFSG-compliant?

[Paul Wise]

On Thu, 2022-08-04 at 19:09 -0400, 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.

What would have changed since the 2004 review of APSL 2.0?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is the APSL 2.0 DFSG-compliant?

[Paul Wise]

On Thu, 2022-08-04 at 19:15 -0400, Ben Westover wrote:

> Interesting, the APSL 2.0 is seen in some relatively important
> packages like Chromium and QtWebEngine.

I wouldn't put any weight on the presence of the APSL 2.0 license text
in the archive, probably it got into Debian in those packages due to
lack of copyright/license review rather than deliberate acceptance,
especially since it is in one of the many code copies in both of them.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is the APSL 2.0 DFSG-compliant?

[Ben Westover]

Hello Paul,

On 8/4/22 02:32, Paul Wise wrote:

The wiki describes it as being non-free and cites two threads:

https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29
https://lists.debian.org/msgid-search/20010928105424z@physics.utah.edu
https://lists.debian.org/msgid-search/20040626225314.5da7f9da@firenze.linux.it

There are recent challenges to it being non-free in these threads:

https://lists.debian.org/msgid-search/d2119303-b470-9ebe-138e-1b57deb8c...@physik.fu-berlin.de
https://lists.debian.org/msgid-search/eff03d85-7990-af04-caac-57b076cc9...@physik.fu-berlin.de


Thanks for these links. My choices for precedent are a conversations 
from almost a decade ago or a modern challenge that talks about an 
earlier version of that license. The APSL 1.* is very different to the 
APSL 2.0, and many of the previous issues with 1.* are solved in 2.0 
according to the FSF. Some have argued it's less strict than even the 
GPL-2. I've seen a lot of those earlier conversations, but I just wanted 
a modern review of the license to see if version 2.0 specifically of the 
license is seen as DFSG-compliant in 2022, not based on 2000s precedent.



There are copies of the license in Debian main:

https://codesearch.debian.net/search?q=APPLE+PUBLIC+SOURCE+LICENSE=1


Interesting, the APSL 2.0 is seen in some relatively important packages 
like Chromium and QtWebEngine.


Thanks for the info!
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Re: Is the APSL 2.0 DFSG-compliant?

[Ben Westover]

Hello Mihai,

On 8/4/22 02:03, Mihai Moldovan wrote:

According to
https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29 ,
which also lists discussions/reasoning for version 1.0 (which is considered
non-free) and your desired version 2.0, it is considered free, but
DFSG-incompatible.


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.


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Re: Is the APSL 2.0 DFSG-compliant?

[Paul Wise]

On Wed, 2022-08-03 at 23:00 -0400, Ben Westover wrote:

> I was wondering if the Apple Public Source License (version 2.0)
> complies with the DFSG. The Free Software Foundation considers it to be
> a free software license (https://www.gnu.org/philosophy/apsl.en.html),
> but I just wanted to make sure it's compatible with the DFSG. Below is
> the full text of the license.

I don't know about that, but I note some things:

The wiki describes it as being non-free and cites two threads:

https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29
https://lists.debian.org/msgid-search/20010928105424z@physics.utah.edu
https://lists.debian.org/msgid-search/20040626225314.5da7f9da@firenze.linux.it

There are recent challenges to it being non-free in these threads:

https://lists.debian.org/msgid-search/d2119303-b470-9ebe-138e-1b57deb8c...@physik.fu-berlin.de
https://lists.debian.org/msgid-search/eff03d85-7990-af04-caac-57b076cc9...@physik.fu-berlin.de

There are copies of the license in Debian main:

https://codesearch.debian.net/search?q=APPLE+PUBLIC+SOURCE+LICENSE=1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Is the APSL 2.0 DFSG-compliant?

[Mihai Moldovan]

* On 8/4/22 05:00, Ben Westover wrote:
> I was wondering if the Apple Public Source License (version 2.0)
> complies with the DFSG. The Free Software Foundation considers it to be
> a free software license (https://www.gnu.org/philosophy/apsl.en.html),
> but I just wanted to make sure it's compatible with the DFSG.

According to
https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29 ,
which also lists discussions/reasoning for version 1.0 (which is considered
non-free) and your desired version 2.0, it is considered free, but
DFSG-incompatible.


Mihai


OpenPGP_signature
Description: OpenPGP digital signature