qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: qemu-devel@nongnu.org, allen.m.kay@intel.com, kraxel@redhat.com,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH v6 8/8] vfio/pci: Add IGD documentation
Date: Wed, 18 May 2016 13:28:37 -0600	[thread overview]
Message-ID: <573CC265.7050701@redhat.com> (raw)
In-Reply-To: <20160518123504.78d8ee35@t450s.home>

[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]

On 05/18/2016 12:35 PM, Alex Williamson wrote:

>> Without an explicit copyright notice and license, your documentation
>> defaults to GPLv2+, per the top level COPYING.  If you want something
>> else, it may be worth explicitly calling it out.
>>
>> Otherwise, it was a good read.
> 
> 
> Thanks for reviewing, Eric.  Surveying existing docs, I see a mix of a
> few with explicit GPLv2+, some PROMELA code under WTFPL/public domain,
> and one lone file under FreeBSD documentation license.  The vast
> majority don't set an explicit license.  I don't have a strong feeling
> about this and the documentation is certainly no opus.  Should I have a
> strong feeling about this?  Thanks,

My personal opinion:

I can see arguments for two different camps:

1. Will this document ever be useful to someone implementing a parallel
code base to the same thing? If so, does a GPLv2+ document taint their
implementation to also have to be GPLv2+ compatible? I'm not a lawyer,
so I have NO IDEA if someone can legally claim that an independent
implementation of code based on a GPLv2+ specification is constrained by
the license of the doc it was implementing.  If it were me answering,
I'd say that there is no tainting involved (GPL applies to source code
in its preferred original form; and how would you justify documentation
to be a preferred original form?).  But precisely because it is a fuzzy
question, being explicit makes the solution easier to reason about:
giving an explicit license looser than GPL means that no one can argue
that the documentation is forcing a particular license on implementations.

2. Why bother? I like GPLv2+ because of its strong copyleft, and want to
make life harder for anyone that doesn't believe in the same way.
Meanwhile, sticking an explicit copyright blurb in the doc makes the doc
harder to read (you have to scroll to get to the real meat),
particularly if I'm just fine with the project-default license, so
omitting the text is okay.  Of course, once a copyright blurb is
omitted, if qemu ever changes its own license (such as to GPLv3+ [hah,
we know that won't happen without a rewrite of all the GPLv2-only
stuff]), then my document follows that change in lockstep, so explicitly
stating GPLv2+ cements my intention regardless of external context.

So at the end of the day, it boils down to how comfortable are you with
the license you've chosen, how likely do you think your doc will be
important to someone writing parallel code, and how much do you care.
I'm perfectly okay with no change, and was merely pointing it out in
case you have a stronger opinion than me.  As you rightly noted, we have
a number of interesting precedents in the directory, so there is no real
common standard, so much as personal preference, although I do prefer
that if you use an explicit license, pick one already in use rather than
adding yet another license to the overall mix of qemu.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2016-05-18 19:28 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-17 20:19 [Qemu-devel] [PATCH v6 0/8] Series short description Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 1/8] vfio: Enable sparse mmap capability Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 2/8] vfio: Create device specific region info helper Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 3/8] vfio/pci: Fix return of vfio_populate_vga() Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 4/8] vfio/pci: Consolidate VGA setup Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 5/8] vfio/pci: Setup BAR quirks after capabilities probing Alex Williamson
2016-05-17 20:19 ` [Qemu-devel] [PATCH v6 6/8] vfio/pci: Intel graphics legacy mode assignment Alex Williamson
2016-05-18 14:21   ` Gerd Hoffmann
2016-05-18 16:50     ` Alex Williamson
2016-05-17 20:20 ` [Qemu-devel] [PATCH v6 7/8] vfio/pci: Add a separate option for IGD OpRegion support Alex Williamson
2016-05-17 20:20 ` [Qemu-devel] [PATCH v6 8/8] vfio/pci: Add IGD documentation Alex Williamson
2016-05-18  2:23   ` Eric Blake
2016-05-18 18:35     ` Alex Williamson
2016-05-18 19:28       ` Eric Blake [this message]
2016-05-17 20:42 ` [Qemu-devel] vfio IGD assignment (was Re: [PATCH v6 0/8] Series short description) Alex Williamson
2016-05-18 14:24   ` Gerd Hoffmann
2016-05-18 18:45     ` Alex Williamson
2016-05-19  9:00       ` Gerd Hoffmann
2016-05-20 12:19       ` Gerd Hoffmann
2016-05-20 15:08         ` Alex Williamson
2016-05-23 13:34           ` Gerd Hoffmann

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=573CC265.7050701@redhat.com \
    --to=eblake@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=allen.m.kay@intel.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.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).