mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Christopher Lane <lanechr@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: musl licensing
Date: Tue, 29 Mar 2016 16:03:01 -0400	[thread overview]
Message-ID: <20160329200301.GO21636@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAKFiscfc3AYZ2_i0LvJmnv1pJmAFzt0y5zN2ruNFU=nPBpKupg@mail.gmail.com>

On Tue, Mar 29, 2016 at 10:21:25AM -0700, Christopher Lane wrote:
> >> If this is still bothering them, would it make them happy to put some
> >> "end of legal text" marking above that paragraph?
> >
> >
> Short answer: not really, no.
> 
> Long answer: every time I mention this to them, I get the same answer.  If
> the license file includes any ambiguity by including things like
> speculation on the copyrightability of the work, it's safer for us to just
> avoid it.  The potential penalties for copyright infringement are
> astronomical.
> 
> I understand (and agree) that the COPYRIGHT file is the most natural place
> to put comments on whether content should be copyrighted, but these are not
> merely inert comments.  Like code, a license file needs to be correct
> before it can be convenient.  Introducing text like "It is our belief and
> intent that these files ... would not be subject to copyright" is
> equivalent to introducing undefined behavior because we just don't know how
> a court might interpret it.  You wouldn't be satisfied with that ambiguity
> in your code; I'm asking you to treat your license the same way.
> 
> Listen, if we're asking you for too much, I get it.  This is not our
> project.  We didn't pour years into it, you did, and you have to do what
> you think is right.  If it's beyond your personal ethics to claim copyright
> over the trivial files and public headers you wrote, then that's the way it
> is.  I'll be sad, but we'll deal with it.
> 
> Or, if you want, I can set up a chat with one of our lawyers for you.  I've
> been so far unable to convince them to bend on this, but maybe you'll have
> better luck.  You're certainly welcome to try, anyway.

I would like that. I really want to make this work, but I do not want
to be taking arbitrary demands to scrub expression of opinion.

Some specific questions for them, which we could discuss directly or
which you could convey to them first if you like:

1. If the problem is file boundaries ("if the license file
contains..."), would this be any different if there were no "license
file", only one big README, and both texts (statement of opinion, and
copyright/license statements) were in the same file but separated by
section headers? I'm not really proposing doing that (although it's
one potential silly solution) but rather trying to draw out the
absurdity (as I see it) of deeming text that specificially says it's
NOT license text as if it were just because it's in the same file.

2. Taking that in the other direction, what good does it do burying a
record of our beliefs about the matter? It's not like we can erase
past statements. Taking the text out of the COPYRIGHT file increases
its distance in space and time from the license text, but it doesn't
change the fact that they were published together in the past. If
anything I think it's a disservice to parties who are (IMO wrongly)
concerned about the implications of such beliefs not to disclose them.
Having clarified text in the same place puts emphasis on the intent
that they not conflict and that we actually put effort into clarifying
where there was a perceived conflict.

3. I understand lawyers want to minimize risk. I don't understand how
a statement of opinion that, if it were deemed relevant and deemed
true by a court, would imply that we (actually nobody) has standing to
sue creates any risk. To use the UB analogy, when someone reports a
claim of UB, we actually want to see a code path that leads to UB
happening (without UB already having occurred by violating an
interface requirement), not just a claim like "if variables X and Y
have values A and B, UB results". Of course if there's a proposed
change that's simpler and doesn't require tracking down if UB actually
occurs, we'd just consider that outright, but when the current code
has advantages, there should be a real motivation to change it. If
we're going to treat the matter here as a "bug report" against the
COPYRIGHT file, I want to have an understanding of the alleged bug.

4. I'd also like to understand what the claim-copyright vs
not-claim-copyright distinction they're making is. As an analogy,
suppose I've written a math textbook containing "1+1=2" in it. The
statement "1+1=2" is most certainly not subject to copyright, and my
saying that (within the text or outside it) does not draw into
question the copyright status of the textbook. I really don't see any
difference between this example and what we're saying here with
regards to these files. We are claiming copyright (and asserting a
right to do so) for the work as a whole. The statement of opinion is
on the matter of these files taken by themselves. If the problem is
just that this isn't clear, maybe there's a trivial way to clarify
that and make everybody happy.

I know this has been a tedious process of back-and-forth and is using
lots more time (on both of our sides) than we'd probably like. But I
do want to see something good come out of it. Let's arrange a chat
with the lawyers (this probably can/should be done off-list) and see
what comes out of it.

Rich


  reply	other threads:[~2016-03-29 20:03 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-15 21:59 Petr Hosek
2016-03-15 22:17 ` croco
2016-03-16 16:32   ` Alexander Cherepanov
2016-03-16 22:50     ` Petr Hosek
2016-03-16 22:55       ` Josiah Worcester
2016-03-16 23:46       ` Rich Felker
2016-03-17  2:06         ` Christopher Lane
2016-03-17  3:04           ` Rich Felker
2016-03-17  8:17           ` u-uy74
2016-03-17 15:14             ` Christopher Lane
2016-03-17 15:28               ` FRIGN
2016-03-17 15:49                 ` Hugues Bruant
2016-03-17 15:57                   ` Rich Felker
2016-03-17 16:01               ` Rich Felker
2016-03-17 23:32                 ` Christopher Lane
2016-03-18  4:21                   ` Rich Felker
2016-03-18  4:47                     ` Christopher Lane
2016-03-18 18:07                       ` Rich Felker
2016-03-18 18:16                     ` Christopher Lane
2016-03-18 19:12                       ` Rich Felker
2016-03-18 19:47                         ` George Kulakowski
2016-03-19  4:35                           ` Rich Felker
2016-03-21 22:46                             ` Christopher Lane
2016-03-23  2:32                               ` Rich Felker
2016-03-23 20:35                                 ` Christopher Lane
2016-03-23 22:53                                   ` Rob Landley
2016-03-29 17:18                                     ` Christopher Lane
2016-03-29 17:21                                   ` Christopher Lane
2016-03-29 20:03                                     ` Rich Felker [this message]
2016-03-29 20:21                                       ` Christopher Lane
2016-03-30  6:56                                     ` u-uy74
2016-03-30 14:11                                       ` Christopher Lane
2016-03-30 14:43                                         ` u-uy74
2016-03-18  8:31               ` u-uy74
2016-03-17  1:26       ` Alexander Cherepanov
2016-03-17  2:20         ` Christopher Lane
2016-03-15 22:20 ` Kurt H Maier
2016-03-15 22:20 ` Josiah Worcester
2016-03-15 22:41 ` Rich Felker
2016-03-15 22:49   ` Shiz
2016-03-16  4:54   ` Isaac Dunham
2016-03-16  8:00   ` u-uy74
2016-03-16 10:31   ` Szabolcs Nagy
2016-03-16 10:55     ` FRIGN
2016-03-16 12:34       ` Szabolcs Nagy
2016-03-16 12:46         ` Anthony J. Bentley
2016-03-16 13:49           ` u-uy74
2016-03-16 14:07             ` FRIGN
2016-03-16 14:01         ` FRIGN
2016-03-16 14:47           ` Szabolcs Nagy
2016-03-16 10:22 ` FRIGN
2016-03-16 20:13 ` Rich Felker
2016-03-16 20:19   ` FRIGN
2016-03-16 20:34     ` Rich Felker
2016-03-16 21:11       ` Jens Gustedt
2016-03-16 21:15       ` FRIGN
2016-03-16 21:35         ` Rich Felker
2016-03-16 21:50           ` FRIGN
2016-03-16 21:34       ` John Levine
2016-03-16 21:38       ` Christopher Lane
2016-03-17  2:01       ` Ed Maste
2016-03-17  3:19         ` Rich Felker
2016-03-17 18:49           ` Ed Maste
2016-03-17 19:16             ` Rich Felker
2016-03-17 21:16               ` Wink Saville
2016-03-17 21:25                 ` Petr Hosek
2016-03-17 22:56                   ` Ruediger Meier
2016-03-17 23:07                     ` Anthony J. Bentley
2016-03-17 23:19                       ` Kurt H Maier
2016-03-17 23:31                         ` Anthony J. Bentley
2016-03-17 23:46                           ` Ruediger Meier
2016-03-18  3:30                           ` Kurt H Maier
2016-03-18  3:41                             ` Rich Felker
2016-03-18  3:55                               ` Christopher Lane
2016-03-17 21:42               ` Ed Maste
2016-03-17 23:37               ` Luca Barbato
2016-03-18  8:01             ` u-uy74
2016-03-18 12:35 ` chromium with musl libc (was: [musl] musl licensing) Natanael Copa

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=20160329200301.GO21636@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=lanechr@gmail.com \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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