linux-spdx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Fontana <rfontana@redhat.com>
To: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Subject: Re: [ASIS-5 patch 0/2] Deep review of 'AS IS' disclaimers - part 5
Date: Wed, 12 Jun 2019 00:58:55 -0400	[thread overview]
Message-ID: <CAC1cPGyAnedqtt_8xfihDyXTfY88h-BXcF_LTwocD-aoLpaOeg@mail.gmail.com> (raw)
In-Reply-To: <7b8044bb-8df7-963a-95ce-38e15d97e691@lohutok.net>

On Sat, Jun 8, 2019 at 3:42 PM Allison Randal <allison@lohutok.net> wrote:
>
> On 6/5/19 10:10 AM, Thomas Gleixner wrote:
> > This is the fifth variant of disclaimer modifications.
> >
> > Standard disclaimer:
> >
> >     this program is distributed in the hope that it will be useful
> >     but without any warranty without even the implied warranty of
> >     merchantability or fitness for a particular purpose
> >
> > Modified disclaimer:
> >
> >     this software is provided as is and without any express or implied
> >     warranties including without limitation the implied warranties of
> >     merchantability and fitness for a particular purpose
> >
> > So as with the previous 4, I don't see anything contradicting or
> > substantially different.
>
> The added wording "as is" and "express or implied" was copied from
> GPLv2, and so doesn't add any additional disclaimers.

So "as is" is in theory this legally magical phrase that can have the
effect of disclaiming implied warranties, and this is associated with
UCC Article 2 (which concerns sales of goods) where it is somewhat
confusingly presented. I might ultimately agree with the view that the
"as is" variant of the GNU source file disclaimer can be subsumed into
the SPDX license identifier notice. But I don't think the issue is as
simple as you may be assuming.

This is a little like my concern about getting rid of explicit
disclaimers of the implied warranties of title and non-infringement,
although less significant. The person (or some original person) who
decided to use the "as is" variant probably did so because they
thought there was something deficient about the absence of "as is" in
the traditional license notice, despite their (presumed) knowledge
that there was a copy of GPLv2 that the recipient would also be
getting that they could look at and have notice of. We should not
forget that this is a GPL compliance issue, because GPLv2 says you
have to "keep intact all the notices that refer . . . to the absence
of any warranty". You are saying that because GPLv2 itself has the "as
is" language, you can delete the "as is" language in this notice
without effectively violating that clause of GPLv2, though literally
of course you *are* violating it. I am just saying that I'm not sure
yet whether I agree with that interpretation.

I guess this also raises the question why I am not really bothered by
getting rid of the traditional GNU license notice warranty disclaimer
language. I don't have a super good answer for that, other than that
the language is just boilerplate recommended by the GPL text itself
and has been prevalent for a really long time. Anytime some
contributor just parrotted the GNU boilerplate, it can be seen as
relatively meaningless. But when a contributor deliberately departed
from the widely-used boilerplate in ways that arguably were motivated
by legal concerns, I am more troubled by the idea that the warranty
disclaimer language can be deleted without the permission of the
copyright holder who originally included that modified warranty
disclaimer language.

Richard

      reply	other threads:[~2019-06-12  4:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05 14:10 [ASIS-5 patch 0/2] Deep review of 'AS IS' disclaimers - part 5 Thomas Gleixner
2019-06-05 14:10 ` [ASIS-5 patch 1/2] treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 298 Thomas Gleixner
2019-06-05 17:05   ` Enrico Weigelt, metux IT consult
2019-06-08 19:44   ` Allison Randal
2019-06-05 14:10 ` [ASIS-5 patch 2/2] treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 302 Thomas Gleixner
2019-06-05 17:06   ` Enrico Weigelt, metux IT consult
2019-06-08 19:44   ` Allison Randal
2019-06-08 19:42 ` [ASIS-5 patch 0/2] Deep review of 'AS IS' disclaimers - part 5 Allison Randal
2019-06-12  4:58   ` Richard Fontana [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC1cPGyAnedqtt_8xfihDyXTfY88h-BXcF_LTwocD-aoLpaOeg@mail.gmail.com \
    --to=rfontana@redhat.com \
    --cc=allison@lohutok.net \
    --cc=linux-spdx@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).