From: John Snow <jsnow@redhat.com>
To: Eric Blake <eblake@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>
Cc: famz@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
armbru@redhat.com, vsementsov@parallels.com, stefanha@redhat.com,
mreitz@redhat.com
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v6 00/21] block: transactionless incremental backup series
Date: Thu, 23 Apr 2015 15:40:03 -0400 [thread overview]
Message-ID: <55394A93.9020209@redhat.com> (raw)
In-Reply-To: <55394593.8050707@redhat.com>
On 04/23/2015 03:18 PM, Eric Blake wrote:
> On 04/23/2015 08:41 AM, John Snow wrote:
>
>> I know I said "primarily to be difficult" but I was just being
>> facetious. I didn't find the GPL2+ to be suitable for documentation,
>> strictly, so I went to read up on the documentation licenses that the
>> fsf support/recommend.
>>
>> There's the GNU documentation license, but I found that unsuitable for a
>> couple reasons -- one of them was that you are forbidden(!) from
>> changing the text of the license,
>
> Note that it is usually only the license text proper that is locked
> down; the rest of the documentation is not under the same restriction
> unless you declare specific invariant sections such as a cover page. But
> I know that the Debian project has typically frowned upon any use of FDL
> with invariant sections, and the FDL has therefore earned a somewhat
> questionable reputation outside of FSF projects.
>
Understood; however the GNU FDL specifies within the license where and
how the GNU FDL must be displayed. I didn't like these requirements, and
might've used the FDL, but you are prohibited from altering the license,
so I chose against this license.
It's too restrictive for me.
>> and there are some provisions in there
>> I didn't like, such as requiring the full text of the license to be
>> included with compiled copies of the document. That's not something I
>> care about -- a reference in source, for instance, is sufficient, or a
>> copy of the license being distributed *with* the compiled source is
>> fine, but I have no need for the full license to be copied with the
>> compiled version.
>
> Yes, I like those benefits of the FreeBSD Documentation License.
>
>>
>> The other documentation license the fsf recommends is the FreeBSD one,
>> and that one looked appealing, short, and to the point, so it is the one
>> I chose. It is essentially the FreeBSD license with words altered to
>> clarify what "code" and "source" means with respect to a document.
>
> In particular, according to the FSF, the FreeBSD Documentation License
> _should be_ acceptable for use with a GPLv2 program:
>
> https://www.gnu.org/philosophy/license-list.html#FreeDocumentationLicenses
>
> although this is probably not the right list to get a definitive answer
> from a lawyer familiar with the various copyright licenses and laws.
>
>>
>> Sorry for /actually/ being difficult; but Eric Blake was urging me to
>> select a license instead of relying on the implicit GPL, so I did go out
>> of my way to choose one I found appropriate.
>>
>> I stand by my pick.
>
> I also agree with the pick; I think that GPLv2+ on documentation is a
> bit questionable - if someone else implements the same interface using
> just the documentation, is their code required to be under the GPL by
> virtue of "using" the documentation? Using a more permissive
> documentation license feels nicer to me, as it would allow non-GPL
> implementations if someone is so inclined. Sorry if encouraging the
> issue has made matters more difficult.
>
It's too late! You've opened Pandora's Box!
next prev parent reply other threads:[~2015-04-23 19:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 23:49 [Qemu-devel] [PATCH v6 00/21] block: transactionless incremental backup series John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 01/21] docs: incremental backup documentation John Snow
2015-04-22 16:17 ` Max Reitz
2015-04-22 19:20 ` Eric Blake
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 02/21] qapi: Add optional field "name" to block dirty bitmap John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 03/21] qmp: Ensure consistent granularity type John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 04/21] qmp: Add block-dirty-bitmap-add and block-dirty-bitmap-remove John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 05/21] block: Introduce bdrv_dirty_bitmap_granularity() John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 06/21] hbitmap: cache array lengths John Snow
2015-04-23 13:39 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 07/21] hbitmap: add hbitmap_merge John Snow
2015-04-22 16:22 ` Max Reitz
2015-04-22 22:00 ` Eric Blake
2015-04-23 13:40 ` Stefan Hajnoczi
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 08/21] block: Add bitmap disabled status John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 09/21] block: Add bitmap successors John Snow
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 10/21] qmp: Add support of "dirty-bitmap" sync mode for drive-backup John Snow
2015-04-22 16:33 ` Max Reitz
2015-04-22 22:11 ` Eric Blake
2015-04-23 13:47 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-17 23:49 ` [Qemu-devel] [PATCH v6 11/21] qmp: add block-dirty-bitmap-clear John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 12/21] qmp: Add dirty bitmap status field in query-block John Snow
2015-04-22 22:18 ` Eric Blake
2015-04-22 22:22 ` John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 13/21] block: add BdrvDirtyBitmap documentation John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 14/21] block: Ensure consistent bitmap function prototypes John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 15/21] block: Resize bitmaps on bdrv_truncate John Snow
2015-04-22 16:35 ` Max Reitz
2015-04-23 13:51 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 16/21] hbitmap: truncate tests John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 17/21] iotests: add invalid input incremental backup tests John Snow
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 18/21] iotests: add QMP event waiting queue John Snow
2015-04-22 16:50 ` Max Reitz
2015-04-23 14:24 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 19/21] iotests: add simple incremental backup case John Snow
2015-04-23 14:28 ` Stefan Hajnoczi
2015-05-22 15:02 ` Kevin Wolf
2015-05-22 15:29 ` John Snow
2015-05-22 15:37 ` Kevin Wolf
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 20/21] iotests: add incremental backup failure recovery test John Snow
2015-04-23 14:28 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-11-27 17:14 ` [Qemu-devel] " Kevin Wolf
2015-11-30 17:17 ` John Snow
2015-12-01 9:31 ` Kevin Wolf
2015-04-17 23:50 ` [Qemu-devel] [PATCH v6 21/21] iotests: add incremental backup granularity tests John Snow
2015-04-23 14:29 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi
2015-04-23 13:19 ` [Qemu-devel] [Qemu-block] [PATCH v6 00/21] block: transactionless incremental backup series Stefan Hajnoczi
2015-04-23 14:41 ` John Snow
2015-04-23 19:18 ` Eric Blake
2015-04-23 19:40 ` John Snow [this message]
2015-04-24 8:37 ` Stefan Hajnoczi
2015-04-24 14:02 ` [Qemu-devel] " Stefan Hajnoczi
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=55394A93.9020209@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=vsementsov@parallels.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.
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).