From: Peter Todd <pete@petertodd•org>
To: Daniel Robinson <danrobinson010@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users
Date: Fri, 14 Oct 2016 08:31:57 -0400 [thread overview]
Message-ID: <20161014123157.GB8499@fedora-21-dvm> (raw)
In-Reply-To: <CAD438HswfYG6MZ_4cWVNgCL8HwKWhMs+JvhVUFCnDu0+Hu-D-g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]
On Fri, Oct 14, 2016 at 04:51:01AM -0700, Daniel Robinson wrote:
> >
> > Because if not, the DPL is still better than the status quo.
>
>
> Agreed. Also worth noting that it has a potential advantage over unilateral
> patent disarmament, analogous to the advantage of copyleft licenses over
> MIT/BSD: it provides an incentive (at least a theoretical one) for other
> companies to adopt it too.
Agreed. That's also one of the reasons (lesser) reasons why I didn't adopt a
patent pledge like blockstream has done. Though frankly the main reason is I'm
unlikely to be able to afford to get any patents anytime soon anyway, so it's
all symbolic and I'd rather spend as little as possible on lawyers. :) Also, my
standard contract that I use with clients prohibits me from getting patents on
work I do (and imposes financial penalties on clients who in turn try to apply
for patents on work derived from mine).
> As many people have proposed, the best option, though one that would
> require a lot of work, might be a dedicated Bitcoin-related defensive
> patent pool—similar to Linux's Open Invention Network—that could
> strategically deploy patent licenses to incentivize cooperation and punish
> aggressors.
Agreed.
> Along those lines, it'd be reasonable to consider changing the Bitcoin
> > Core license to something like an Apache2/LGPL3 dual license to ensure the
> > copyright license also has anti-patent protections.
>
>
> I think Apache 2.0 would be a great license for Bitcoin Core. It not only
> contains an explicit patent license grant (rather than MIT's implicit one),
> but terminates that license if the licensee asserts a claim alleging that
> the covered work infringes a patent. That might be an effective deterrent
> against bringing patent claims based on alleged infringement in Bitcoin
> Core.
Indeed. For a codebase that is in large part both a reference implementation
and the very definition of the Bitcoin protocol, we do want a permissive
license to ensure that commercial users are able to use the Bitcoin protocol.
However there is no reason to extend that permissivity to allowing others to
attempt to restrict others' rights to use the Bitcoin protocol via patents.
> (I'm not sure I see a good reason to dual-license under the LGPL3,
> but am curious to hear more.)
Ah, actually I think I misremembered: it'd be Apache2.0/LGPL_v2_ where a dual
license would make sense; Apache2.0 is compatibile with (L)GPL3:
http://www.dwheeler.com/essays/floss-license-slide.html
https://www.apache.org/licenses/GPL-compatibility
(L)GPLv2 doesn't have the patent protections that (L)GPLv3 does, so my
suggestion is wrong; Apache2.0 by itself is perfectly good.
> It would probably be feasible to upgrade to the Apache license for new
> releases and contributions (leaving already-existing code and previous
> releases under the MIT license—so basically a copyright "soft-fork"). Has
> this been discussed before? Are there any obstacles or objections?
Yup, that'd be perfectly possible to do. Basically new contributions would be
licensed under the new, MIT-compatible, licenses. I did that myself with
python-bitcoinlib, as part of the codebase was licensed MIT, and part LGPLv2 or
later; to comply with the latter I changed the license for all new work to
LGPLv3 or later. Interestingly, this has lead to the Bitcoin Core unit tests
using an older version of python-bitcoinlib; kudo's goes to Suhas Daftuar for
dilligently respecting the new license.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-10-14 12:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-14 10:38 Sergio Demian Lerner
2016-10-14 10:57 ` Peter Todd
2016-10-14 11:51 ` Daniel Robinson
2016-10-14 12:31 ` Peter Todd [this message]
2016-10-15 10:01 ` Tom Zander
2016-10-14 18:10 ` Sergio Demian Lerner
2016-10-14 19:01 ` Nick ODell
2016-10-14 21:07 ` Daniel Robinson
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=20161014123157.GB8499@fedora-21-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=danrobinson010@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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