[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Apr 2016 00:14:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Cc: Christopher Lane <lanechr@...il.com>
Subject: Proposed COPYRIGHT file changes to resolve "PD" issue
After the previous discussions on the list, I spoke with one of
Google's lawyers on the phone. It's taken me a while to follow up
after that because I was away at ELC last week, but I think we have a
good resolution as long as there are no objections.
Where I was coming from was not wanting license crap to be an obstacle
to adoption of musl (after all, that's why I relicensed from LGPL to
MIT in the first place) but also not wanting to scrub my/our belief
that some of these files are non-copyrightable or retroactively claim
ownership of something we can't own.
Where they were coming from was a context of dealing with courts
wrongly (this is my opinion I'm injecting here) deeming interfaces to
be copyrightable, and having to spend ridiculously disproportionate
effort to determine if the license actually gives them permission to
use all the code.
While I don't really agree that they actually have cause for concern
in musl's case, I do agree that the simple fact that the current text
is causing concern means there's something wrong with it. A license
should not make you have to stop and think about whether you can
actually use the software, and certainly shouldn't necessitate 60+
message mailing list threads.
The proposal we reached on the phone call was that I would try
improving the previous patch to no longer make a statement about the
copyrightability of the files in question, but to note that we
expressed such a belief in the past. No new statement that we _do_
hold copyright over these files is made, but the grants of permission
are made unconditionally (i.e. without any conditions like "if these
files are found to be subject to copyright...").
How does this sound? See the attached patch for the specific wording
proposed and let me know if you have constructive ideas for improving
it. On our side, it's really the agreement of the contributors of the
affected code (I have a draft list of them in the patch) that matters,
but I'd welcome input from others too. Also, the patch itself has not
been run by Google's side yet -- I'm doing this all in the open -- so
there still may be further feedback/input from their side.
Rich
View attachment "google2.diff" of type "text/plain" (2560 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
