[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is the APSL 2.0 DFSG-compliant?



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]: <https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#AnonFTPAndSendSources>

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, Debian will always need to make source code available
> externally, unless we require bundling source code with APSL-2.0-licensed
> binary works.
[...]

Debian *is* offering source for download from the same archive/mirror
infrastructure.
This is enough for the GNU GPL v2, without any other future obligations.
Contrast this with the APSL v2.0, which imposes obligations for at least
12 months from the initial "External Deployment", even in the cases
where the source has been bundled with all binary distributions.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Attachment: pgp9Pz1BvYOyd.pgp
Description: PGP signature


Reply to: