• Re: Bug#1094969: git linked with OpenSSL

    From Henrik Ahlgren@21:1/5 to Pirate Praveen on Mon Apr 14 10:40:02 2025
    Pirate Praveen <praveen@onenetbeyond.org> writes:

    Didn't OpenSSL switch license to Apache 2.0 and now compatible with
    GPL? What am I missing here?

    https://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Stone@21:1/5 to Simon Josefsson on Tue Apr 15 16:10:01 2025
    On Tue, Apr 15, 2025 at 03:38:38PM +0200, Simon Josefsson wrote:
    I believe that is a fairly new (~5 years?) approach within Debian.
    Debian used to treat OpenSSL incompatible with GPLv2 and that all code
    that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone
    recall how and when this decision was made?

    I think it was at least in part a pragmatic realization that debian was
    being overly strict, as most other distributions (including those with
    lawyers presumably incentivized to protect assets worth suing over) were following a different interpretation.

    FWIW, I think the current interpretation is much more in line with the
    spirit of the text: we're not including openssl for the specific purpose
    of linking to git; libssl is a part of the distribution that happens to
    be pulled in (indirectly) when building git. It also seems not in
    keeping with the spirit of the license that a completly non-free OS
    linking non-free software would have fewer restrictions than a free OS
    linking free software.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon Josefsson@21:1/5 to Michael Stone on Wed Apr 16 07:30:01 2025
    Michael Stone <mstone@debian.org> writes:

    On Tue, Apr 15, 2025 at 03:38:38PM +0200, Simon Josefsson wrote:
    I believe that is a fairly new (~5 years?) approach within Debian.
    Debian used to treat OpenSSL incompatible with GPLv2 and that all code
    that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone >>recall how and when this decision was made?

    I think it was at least in part a pragmatic realization that debian
    was being overly strict, as most other distributions (including those
    with lawyers presumably incentivized to protect assets worth suing
    over) were
    following a different interpretation.

    Yes that seems likely. I think that the decision in other distributions
    may have had more to do with aligning interests with organization who
    fund them, though. It is a calculated risk to be in a better position
    to get access to X money by breaching one interpretation of a license
    that is unlikely to hurt financially. Debian doesn't have to follow the
    same kind of reasoning, but I realize it is easy to do so.

    Was invoking the system library exception discussed or decided on
    project-wide in Debian? I tried to find some earlier discussion around
    this, and while many discussions is possible to find, I don't see any conclusions.

    FWIW, I think the current interpretation is much more in line with the
    spirit of the text: we're not including openssl for the specific
    purpose of linking to git; libssl is a part of the distribution that
    happens to be pulled in (indirectly) when building git. It also seems
    not in keeping with the spirit of the license that a completly
    non-free OS linking non-free software would have fewer restrictions
    than a free OS linking free software.

    I disagree.

    I think the idea behind the "proprietary system library" GPL exception
    is to make it possible to distribute GPL binaries linked to non-free
    system libraries on systems where that is pretty much unavoidable, e.g.
    system libraries on AIX, IRIX etc. The exception is that you are not
    required to distribute source code for the non-free system libraries:

    https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

    The exception in the GPLv2 says:

    However, as a special exception, the source code distributed need not
    include anything that is normally distributed (in either source or
    binary form) with the major components (compiler, kernel, and so on)
    of the operating system on which the executable runs, unless that
    component itself accompanies the executable.

    I believe that those components (compiler, kernel, OpenSSL, etc)
    accompany the executable for Debian. So the exception does not appear applicable to me.

    The system library exception was not intended for distributions to be
    able to link GPLv2 code to GPLv2-incompatible code: there is no "just
    happens to" occuring in this situation, it is an intentional decision
    made by packagers (which can be reversed to respect copyright holders).

    /Simon

    -----BEGIN PGP SIGNATURE-----

    iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmf/P9kUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFokt1AP0SGkWAZMc/ vBo2jcp1WdDvckOE9m3eHD8l0vmsJK96jQD+MVTQWAZKWTQo/1go3hxkQ+/34TKO 5i9kpyZlQ04eMA4=
    =MUi2
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Metzler@21:1/5 to simon@josefsson.org on Wed Apr 16 08:10:01 2025
    On 2025-04-16 Simon Josefsson <simon@josefsson.org> wrote:
    [...]
    Was invoking the system library exception discussed or decided on project-wide in Debian? I tried to find some earlier discussion around
    this, and while many discussions is possible to find, I don't see any conclusions.

    Good morning,

    iirc it came up multiple times on diverse mailing lists as a suggestion.

    We did not have a GR or something like it. We have a dedicated team to
    decide what is acceptable to distribute (ftp-masters) and they made the
    call. Given that they are the ones who need to be convinced of the
    correctness of such decisions and stand by them I still think that was
    the right way.

    cu Andreas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar =?UTF-8?Q?=F0=9F=99=80?=@21:1/5 to Simon Josefsson on Wed Apr 16 08:40:01 2025
    Hi,

    On Wed, 2025-04-16 at 07:27 +0200, Simon Josefsson wrote:
    Yes that seems likely.  I think that the decision in other distributions
    may have had more to do with aligning interests with organization who
    fund them, though.

    This is moving into conspiracy theory territory... We can as well
    suspect reptiloids behind this.

    Maybe other distributions also noticed that the system library
    exception is required to distribute most GPL-2-only or GPL-3-only
    software in practice. That is something the FSF forced, whatever their motivations behind this are.

    I believe that those components (compiler, kernel, OpenSSL, etc)
    accompany the executable for Debian.  So the exception does not appear applicable to me.

    The system library exception was not intended for distributions to be
    able to link GPLv2 code to GPLv2-incompatible code: there is no "just
    happens to" occuring in this situation, it is an intentional decision
    made by packagers (which can be reversed to respect copyright holders).

    Debian has always allowed GPL-2-only code linked against GPL-3+-only
    libraries such as the libstdc++ or GCC runtime libraries. (You ignore
    that libraries aside of OpenSSL exist.)

    Debian also has always allowed GPL-2-only code linked against OpenSSL
    if one specific means of doing so was not used, for example we had (and continue to have) GPL-2-only code using `import ssl` (directly or
    indirectly) in Debian which happens to... link OpenSSL at runtime.

    Debian treated one specific technical implementation of linking
    (instructions for ld.so) for one specific system library (OpenSSL)
    differently and stopped doing so.

    So let me ask you directly: do you think we should remove all GPL-3
    software directly or indirectly including anything from
    /usr/include/linux/*.h?

    Do you think we should remove all GPL-2 software linking libstdc++ or
    other GCC runtime libraries?

    Do you think we should remove all GPL-2 software linking (L)GPL-3+
    libraries such as GnuTLS?

    Do you think we should remove all GPL-2 software linking OpenSSL in any
    way (including via `import ssl` or similar)?

    Do you think we should remove all GPL-2 software linking any other
    library licensed under, say, Apache-2 in any way (including via Python
    imports or similar)?

    Do you have any idea how much software would be affected?

    Which of those must in your opinion be done before the release of
    trixie?

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henrik Ahlgren@21:1/5 to Pirate Praveen on Wed Apr 16 09:50:02 2025
    Pirate Praveen <praveen@onenetbeyond.org> writes:

    But the crucial point here is that the git upstream is choosing not to correct that mistake by moving to GPLv3 (probably they don't like some
    other changes introduced) or giving another specific exception to
    linking with Apache 2.0.

    Well, Torvalds founded Git, and it is well known that he likes GPLv2 and dislikes v3. Apparently he is still a major copyright holder, even after handing over the project maintenance to Junio Hamano very early.

    And how many copyright holders are involved in the project? It might be permanently stuck to v2, much like the Linux kernel, which is now
    practically impossible to change licenses.

    Interestingly, the COPYING file in the Git tree states the following (https://github.com/git/git/blob/master/COPYING):

    Note that the only valid version of the GPL as far as this project
    is concerned is _this_ particular version of the license (ie v2, not
    v2.2 or v3.x or whatever), unless explicitly otherwise stated.

    HOWEVER, in order to allow a migration to GPLv3 if that seems like
    a good idea, I also ask that people involved with the project make
    their preferences known. In particular, if you trust me to make that
    decision, you might note so in your copyright message, ie something
    like

    This file is licensed under the GPL v2, or a later version
    at the discretion of Linus.

    might avoid issues. But we can also just decide to synchronize and
    contact all copyright holders on record if/when the occasion arises.

    Linus Torvalds

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henrik Ahlgren@21:1/5 to Simon Josefsson on Wed Apr 16 09:20:01 2025
    Simon Josefsson <simon@josefsson.org> writes:

    I think the idea behind the "proprietary system library" GPL exception
    is to make it possible to distribute GPL binaries linked to non-free
    system libraries on systems where that is pretty much unavoidable, e.g. system libraries on AIX, IRIX etc. The exception is that you are not required to distribute source code for the non-free system libraries:

    I feel it is important to remember that the GPL v2 was released in June
    1991. This was the era of proprietary UNIX, and the concept of a
    (GNU/)Linux distribution, or the Linux kernel as a serious project, had
    yet to emerge. Ian Murdoch founded Debian in 1993.

    BTW, FSF considers Apache 2.0 as a good license and that "it's
    unfortunate that the Apache License 2.0 isn't compatible with some free software licenses like GPLv2". Compatibility with it was one important
    goal for GPLv3. So, this incompatibility was not never designed, it was
    just a mistake of an early free software license from a different era.

    https://www.fsf.org/blogs/licensing/new-license-recommendations-guide

    I believe that the term "system library" lacks significant meaning in an operating system like Debian. One could argue that all libraries in
    Debian qualify as "system libraries".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Urlichs@21:1/5 to All on Wed Apr 16 11:10:02 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rvGudofnyCw7G2KbJi5tmGzE
    Content-Type: multipart/mixed; boundary="------------97ijX0R270xDx1evMsCCnQZa"

    --------------97ijX0R270xDx1evMsCCnQZa
    Content-Type: multipart/alternative;
    boundary="------------3YfwDSdfCOZHhFxd7yS7PRVk"

    --------------3YfwDSdfCOZHhFxd7yS7PRVk
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    T24gMTYuMDQuMjUgMDc6MjcsIFNpbW9uIEpvc2Vmc3NvbiB3cm90ZToNCj4gSSB0aGluayB0 aGUgaWRlYSBiZWhpbmQgdGhlICJwcm9wcmlldGFyeSBzeXN0ZW0gbGlicmFyeSIgR1BMIGV4 Y2VwdGlvbg0KPiBpcyB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIGRpc3RyaWJ1dGUgR1BMIGJp bmFyaWVzIGxpbmtlZCB0byBub24tZnJlZQ0KPiBzeXN0ZW0gbGlicmFyaWVzIG9uIHN5c3Rl bXMgd2hlcmUgdGhhdCBpcyBwcmV0dHkgbXVjaCB1bmF2b2lkYWJsZSwNCg0Kd2hpY2gsIGlm IHlvdSByZW1vdmUgdGhlICJwcm9wcmlldGFyeSIgYW5kICJub24tZnJlZSIgd29yZGluZyB3 aGljaCB3YXMgDQp1bmF2b2lkYWJsZSB3aGVuIHRoZSBHUEwgd2FzIHdyaXR0ZW4gYnV0IGlz bid0IG5vd2FkYXlzLCBpcyBleGFjdGx5IHdoYXQgDQp3ZSBoYXZlIGhlcmU6IGl0J3MgcHJl dHR5IG11Y2ggdW5hdm9pZGFibGUgZm9yIG5vbnRyaXZpYWwgcHJvZ3JhbXMgdG8gDQpzb21l aG93IGxpbmsgdG8gbGlicmFyaWVzIHdpdGggImluY29tcGF0aWJsZSIgbGljZW5zZXMuDQoN CkkgdGh1cyBtb3ZlIHRoYXQgd2UgZGVjbGFyZSBldmVyeSBsaWJyYXJ5IHRoYXQgc3VwcGxp ZXMgYmFzaWMgZmVhdHVyZXMgDQoobm93YWRheXMgU1NMIGNlcnRhaW5seSBjb3VudHMgYXMg c3VjaCkgdG8gYSB3aWRlbHkgZGlzcGFyYXRlIGNhYmFsIG9mIA0KYXBwbGljYXRpb25zIChk aXR0bynCoCB0byBiZSBhIFN5c3RlbSBMaWJyYXJ5Lg0KDQoqTm9ib2R5KiBpcyBnb2luZyB0 byBnbyBhZnRlciBEZWJpYW4gd2l0aCBhIGRlbWFuZCB0byBzdG9wIGRvaW5nIHN1Y2ggDQps aW5raW5nLCBtdWNoIGxlc3MgZGVtYW5kIGNvbXBlbnNhdGlvbiBvZiBhbnkgZGFtYWdlcy4g SWYgYW55Ym9keSBldmVyIA0KZG9lcywgd2VsbCwgd2UgY2FuIGRpc2N1c3MgaG93IHRvIGZp eCB0aGUgcHJvYmxlbSB0aGVuLCAqKmFsb25nIHdpdGggDQpwcmV0dHkgbXVjaCBldmVyeSBv dGhlciBkaXN0cm8gb3V0IHRoZXJlKiouIFRoaXMgaXMgbm90IGEgRGViaWFuIA0Kc3BlY2lm aWMgcHJvYmxlbS4NCg0KR29pbmcgb3V0IG9mIG91ciB3YXkgdG8gcHJvLWFjdGl2ZWx5IGtv d3Rvd1sxXSB0byBiYXJlbHktdW5kZXJzdG9vZCANCmxlZ2FsZXNlICh3ZSBhbGwgYXJlIG5v dCBsYXd5ZXJzLCB1cCB0byBhbmQgaW5jbHVkaW5nIHRoZSBGVFAgdGVhbSkgaXMgDQpub3Qg VGhlIFdheS4gTmVpdGhlciBpcyBjcmlwcGxpbmcgc29tZSBmZWF0dXJlcyBvZiBnaXQsIG9y IHdoaWNoZXZlciANCmVsc2UgcHJvZ3JhbSBkdSBqb3VyIGhhcyB0aGlzIHByb2JsZW0uDQoN Ck5CIG5vIGl0J3Mgbm90IHBvc3NpYmxlIHRvIHJlLWxpY2Vuc2UgZ2l0IHRvIEdQTHYzLiBU aGF0J2QgYmUgb25seSANCnNsaWdodGx5IGxlc3MgZGlmZmljdWx0IGFzIHJlLWxpY2Vuc2lu ZyB0aGUgTGludXgga2VybmVsLg0KDQpbMV0gInRvIHNob3cgb2JzZXF1aW91cyBkZWZlcmVu Y2UiKg0KKg0KDQotLSANCi0tIG1pdCBmcmV1bmRsaWNoZW4gR3LDvMOfZW4NCi0tIA0KLS0g TWF0dGhpYXMgVXJsaWNocw0KDQo=
    --------------3YfwDSdfCOZHhFxd7yS7PRVk
    Content-Type: text/html; charset=UTF-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
    <div class="moz-cite-prefix">On 16.04.25 07:27, Simon Josefsson
    wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:87ecxszndy.fsf@josefsson.org">
    <pre class="moz-quote-pre" wrap="">I think the idea behind the "proprietary system library" GPL exception
    is to make it possible to distribute GPL binaries linked to non-free
    system libraries on systems where that is pretty much unavoidable,</pre>
    </blockquote>
    <p>which, if you remove the "proprietary" and "non-free" wording
    which was unavoidable when the GPL was written but isn't nowadays,
    is exactly what we have here: it's pretty much unavoidable for
    nontrivial programs to somehow link to libraries with
    "incompatible" licenses.</p>
    <p>I thus move that we declare every library that supplies basic
    features (nowadays SSL certainly counts as such) to a widely
    disparate cabal of applications (ditto)  to be a System Library.<br>
    </p>
    <p>*Nobody* is going to go after Debian with a demand to stop doing
    such linking, much less demand compensation of any damages. If
    anybody ever does, well, we can discuss how to fix the problem
    then, **along with pretty much every other distro out there**.
    This is not a Debian specific problem.<br>
    </p>
    <p>Going out of our way to pro-actively kowtow[1] to
    barely-understood legalese (we all are not lawyers, up to and
    including the FTP team) is not The Way. Neither is crippling some
    features of git, or whichever else program du jour has this
    problem.</p>
    <p>NB no it's not possible to re-license git to GPLv3. That'd be
    only slightly less difficult as re-licensing the Linux kernel.<br>
    </p>
    <p>[1] "<span class="dt "><span class="dtText">to show obsequious
    deference"<b><br>
    </b></span></span></p>
    <pre class="moz-signature" cols="72">--
    -- mit freundlichen Grüßen
    --
    -- Matthias Urlichs</pre>
    </body>
    </html>

    --------------3YfwDSdfCOZHhFxd7yS7PRVk--

    --------------97ijX0R270xDx1evMsCCnQZa
    Content-Type: text/vcard; charset=UTF-8; name="matthias.vcf" Content-Disposition: attachment; filename="matthias.vcf" Content-Transfer-Encoding: base64

    QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOlVybGljaHM7TWF0dGhpYXM7OzsNCk5JQ0tO QU1FOlNtdXJmDQpFTUFJTDtQUkVGPTE6bWF0dGhpYXNAdXJsaWNocy5kZQ0KVEVMO1RZUEU9 d29yaztWQUxVRT1URVhUOis0OSA5MTEgNTk4MTggMA0KVVJMO1RZUEU9aG9tZTpodHRwczov L21hdHRoaWFzLnVybGljaHMuZGUNCkVORDpWQ0FSRA0K

    --------------97ijX0R270xDx1evMsCCnQZa--

    --------------rvGudofnyCw7G2KbJi5tmGzE--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmf/ZnQFAwAAAAAACgkQcs+OXiW0wpOz zhAAn6kRvSVglp+3O17PaOM+9UBEkvMMH/zAa+NYWpfuQojKT+f8DStkMb+E4mP9hjtN1sLXHQrF Wb74XUU+fQQyOM6JtZdLBaoa+DsynNzfOSJqtLvakdDCVNEL4NTZ8oxpTAsffzLBKb+aMvmfkFOA VmFdbDU837J3cNZ2bGyzBSud7ZECpcN1IXI9HhPq8FJnsQ4pn0KkK898iVNkp2jehXMMZeURjUp7 trSMB4JNNuxz4f68JL7Kl+FSAk
  • From Simon Josefsson@21:1/5 to Henrik Ahlgren on Wed Apr 16 11:30:02 2025
    Henrik Ahlgren <pablo@seestieto.com> writes:

    Simon Josefsson <simon@josefsson.org> writes:

    I think the idea behind the "proprietary system library" GPL exception
    is to make it possible to distribute GPL binaries linked to non-free
    system libraries on systems where that is pretty much unavoidable, e.g.
    system libraries on AIX, IRIX etc. The exception is that you are not
    required to distribute source code for the non-free system libraries:

    I feel it is important to remember that the GPL v2 was released in June
    1991. This was the era of proprietary UNIX, and the concept of a
    (GNU/)Linux distribution, or the Linux kernel as a serious project, had
    yet to emerge. Ian Murdoch founded Debian in 1993.

    Sure. But the concept of non-free system libraries is still common and
    the exception is applicable to these situations. Compare how Homebrew
    can distribute GPLv2 binaries linked to system libraries on macOS
    without having to distribute source code for those system libraries.

    BTW, FSF considers Apache 2.0 as a good license and that "it's
    unfortunate that the Apache License 2.0 isn't compatible with some free software licenses like GPLv2". Compatibility with it was one important
    goal for GPLv3. So, this incompatibility was not never designed, it was
    just a mistake of an early free software license from a different era.

    That would be a good argument for git to use GPLv3 from 2007 instead of
    older GPLv2. I don't think that will happen, so we are stuck with GPLv2
    for git, and the consequences of that decision.

    I believe that the term "system library" lacks significant meaning in an operating system like Debian.

    I think that I agree with this. System libraries were intended for
    things outside of the collection of work that you are distributing, such
    as non-free system libraries on proprietary Unix. The comparable
    element for Debian would be the UEFI boot loader or BIOS software.

    But if this is the case, it seems you cannot invoke the GPL exception?
    It is only valid for linking to something that qualify as a system
    library. If OpenSSL in Debian isn't a system library, there is no
    exception that allows linking.

    One could argue that all libraries in Debian qualify as "system
    libraries".

    Yes, I think that could also be reasonable. However I think this interpretation fails the "unless that component itself accompanies the executable" part of the GPLv2 system library exception:

    However, as a special exception, the source code distributed need not
    include anything that is normally distributed (in either source or
    binary form) with the major components (compiler, kernel, and so on)
    of the operating system on which the executable runs, unless that
    component itself accompanies the executable.

    All this said, I think primarily the assumption that other distributions
    made is that Linus won't sue to defend his GPLv2 copyright in Linux and
    isn't likely to do so for Git either. That assumption works less well
    for other copyright holders that may be more interested in defending
    their rights.

    /Simon

    -----BEGIN PGP SIGNATURE-----

    iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmf/dncUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFojvGAQCEeH56faQg Y8HyMPwJUptwYL+wXC99llJZ2+OKE++aDQD/XRWMk+dxsess+pyirq+ityUjWze6 i0LUVdS6A/guZgU=
    =JpD2
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Matthias Urlichs@21:1/5 to All on Wed Apr 16 12:40:01 2025
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0W8k2PBrinEylVF7wjgNz9yy
    Content-Type: multipart/mixed; boundary="------------hhfCui4zWX8oZoxEuvxiimwt"

    --------------hhfCui4zWX8oZoxEuvxiimwt
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    T24gMTYuMDQuMjUgMDk6NDYsIEhlbnJpayBBaGxncmVuIHdyb3RlOg0KPiBCdXQgd2UgY2Fu IGFsc28ganVzdCBkZWNpZGUgdG8gc3luY2hyb25pemUgYW5kDQo+ICAgIGNvbnRhY3QgYWxs IGNvcHlyaWdodCBob2xkZXJzIG9uIHJlY29yZCBpZi93aGVuIHRoZSBvY2Nhc2lvbiBhcmlz ZXMuDQoNCkxpbnVzIFRvcnZhbGRzIHNob3VsZCBoYXZlIGtub3duIGJldHRlciB0aGFuIHRv IGJlICp0aGF0KiBvcHRpbWlzdGljLg0KDQpUaGUgbnVtYmVyIG9mIHN1Y2ggbm90aWNlcyBt aWdodCBzZXJ2ZSBhcyBhIHJvdWdoIGluZGljYXRvciBmb3IgaG93IG1hbnkgDQpwZW9wbGUg cmVhZCBzdWNoIGxpY2Vuc2UgZmlsZXMgaW4gdGhlIGZpcnN0IHBsYWNlLiAoU3BvaWxlcjog YWxtb3N0IG5vYm9keS4pDQoNCi0tIA0KLS0gcmVnYXJkcw0KLS0gDQotLSBNYXR0aGlhcyBV cmxpY2hzDQoNCg==
    --------------hhfCui4zWX8oZoxEuvxiimwt
    Content-Type: text/vcard; charset=UTF-8; name="matthias.vcf" Content-Disposition: attachment; filename="matthias.vcf" Content-Transfer-Encoding: base64

    QkVHSU46VkNBUkQNClZFUlNJT046NC4wDQpOOlVybGljaHM7TWF0dGhpYXM7OzsNCk5JQ0tO QU1FOlNtdXJmDQpFTUFJTDtQUkVGPTE6bWF0dGhpYXNAdXJsaWNocy5kZQ0KVEVMO1RZUEU9 d29yaztWQUxVRT1URVhUOis0OSA5MTEgNTk4MTggMA0KVVJMO1RZUEU9aG9tZTpodHRwczov L21hdHRoaWFzLnVybGljaHMuZGUNCkVORDpWQ0FSRA0K

    --------------hhfCui4zWX8oZoxEuvxiimwt--

    --------------0W8k2PBrinEylVF7wjgNz9yy--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEEr9eXgvO67AILKKGfcs+OXiW0wpMFAmf/gy8FAwAAAAAACgkQcs+OXiW0wpO6 fQ//VoDHh78wCTsjd/0zBiDGduD3GZ03deJ3rDsQkP1jE709uO0IKQ+kSqtTYI2RQh86ErTaqe1h 8I18MnnXjmUjYmlDk5gg65zkKvnVKnWHPuIE/nAAvSNltng8SrBEoh0w/ag3yYwypp1KchfDrG2P q2AGf8j17TpNPvVVqBvoGxfkwHMSf2+gNCaGeUXFgr3lp0AP02ruJ5Ycix+CV47XxZ72KSkDVVUL FBO1UCBY/dz2l2s7MOYEF0jt5Yn0E86uzyhJkj7N/lTSy/EAvxRRsG2aDiFkGZZJQ4+4oqoTNsJJ ar45Ba428j0VzAUqM50E9XnRFn93EClUhK3CIZVMt3FNL1wAV5iSXlGq9sYjBS1lDPVc8Z+Zs/K8 XkF04Y6xltYr6kJfixq1gzJgdh8PrDMXMClklGcwLuO76H/OAlQaNfYm9gV0PXWZlu0LwfKw9Pb+ G3JbuSL+z60kcpcXQ1rYEEobtNI751iSQAfOJWd67cF9iWM8hni+v59hDq4/SLEUVkMObLEfoMB5 HCnIy543Xx3NOFKcth+5Hg6nE9u5q5lH0fpE30lN8PQFmOCuOw9A8s9kHhGW/hV/AVDVoNzpyRIs 8yoXLHrBykZdRF37uxWpbpq7y/w5e7JoAezBhVynW2b9potfpiCmSWr0YFVYULoixpfv3QvcBGLi fFQ=
    =WWBS
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bill Allombert@21:1/5 to All on Wed Apr 16 19:20:01 2025
    Le Wed, Apr 16, 2025 at 08:39:18AM +0200, Ansgar 🙀 a écrit :
    Hi,

    On Wed, 2025-04-16 at 07:27 +0200, Simon Josefsson wrote:
    Yes that seems likely.  I think that the decision in other distributions may have had more to do with aligning interests with organization who
    fund them, though.

    This is moving into conspiracy theory territory... We can as well
    suspect reptiloids behind this.

    This is uncalled for. Saying that Fedora is influenced by RedHat for
    example is not a conspiracy theory.

    Debian has traditionally adopted a stricter approach to licenses than
    other distributions.

    Debian has always allowed GPL-2-only code linked against GPL-3+-only libraries such as the libstdc++ or GCC runtime libraries. (You ignore
    that libraries aside of OpenSSL exist.)

    Note that libstdc++ and GCC runtime libraries are covered by the
    GCC Runtime Library Exception which is different from the system
    library exception.

    Cheers,
    Bill.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ansgar =?UTF-8?Q?=F0=9F=99=80?=@21:1/5 to Bill Allombert on Wed Apr 16 20:40:01 2025
    Hi,

    On Wed, 2025-04-16 at 17:12 +0000, Bill Allombert wrote:
    Le Wed, Apr 16, 2025 at 08:39:18AM +0200, Ansgar 🙀 a écrit :

    Debian has always allowed GPL-2-only code linked against GPL-3+-only libraries such as the libstdc++ or GCC runtime libraries. (You ignore
    that libraries aside of OpenSSL exist.)

    Note that libstdc++ and GCC runtime libraries are covered by the
    GCC Runtime Library Exception which is different from the system
    library exception.

    How is that relevant? Note that

    (a) the runtime exception doesn't allow you to distribute the source
    for libstdc++ under GPL-2-compatible terms which would be required by
    the GPL-2-licensed software if one claims the system library exception
    does not apply.

    Otherwise: assume the runtime exception does so for all licenses, then
    it would trivially allow to distribute the libstdc++ source under
    proprietary licenses and one could just use a permissive license from
    the start instead of GPL-3+-with-limited-extra-permissions.

    (b) The OpenSSL license has a runtime library exception "built in" as
    it doesn't require libraries linking it to be distributed under similar
    terms as OpenSSL to begin with. So if it was relevant, the OpenSSL
    problem would be solved too. (And proprietary operating system vendors
    could just grant themselves an exception too if they wanted to
    distributed GPL-2 programs as part of the operating system.)

    Ansgar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)