Date: Fri, 14 Oct 2016 08:31:57 -0400
From: Peter Todd <pete@petertodd.org>
To: Daniel Robinson <danrobinson010@gmail.com>
Message-ID: <20161014123157.GB8499@fedora-21-dvm>
References: <CAKzdR-oaqUicPhCjfbyX92odVs9LOzvhUOY6nyd9K2RdC_9b_g@mail.gmail.com>
	<20161014105757.GA8049@fedora-21-dvm>
	<CAD438HswfYG6MZ_4cWVNgCL8HwKWhMs+JvhVUFCnDu0+Hu-D-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk"
Content-Disposition: inline
In-Reply-To: <CAD438HswfYG6MZ_4cWVNgCL8HwKWhMs+JvhVUFCnDu0+Hu-D-g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
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
Precedence: list


--R3G7APHDIzY6R/pk
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
>=20
> Agreed. Also worth noting that it has a potential advantage over unilater=
al
> 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 ap=
ply
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=E2=80=94similar to Linux's Open Invention Network=E2=80=94tha=
t 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.
>=20
>=20
> 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 protoco=
l.
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 du=
al
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=E2=80=94so basically a copyright "soft-for=
k"). 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 LGPLv=
2 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 f=
or
dilligently respecting the new license.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--R3G7APHDIzY6R/pk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYANA6AAoJEGOZARBE6K+yLo4H/2YtorAcnmfFi2hCX6u5vOt9
5DSXICCs8PkCnDxEC/uOuECGMlqI8C3ONw9nrcKgBbpaj2Q6/h3beixJWGTqkf2a
B1mfXO0kzDG64uRlnsBqZyGGK28BBJNiV+akoBl3ukWibHOL4OmfDRmiim6yeH/E
zjWZmMn8k5lAdQ0p4KnYNnbhwprTuHvvYXo2Pj5GUuXzB2Vr3npcs7yi9Rk7Uoxn
zgbPIhfq4w/hzJhdeP6LOKUlKI8GEDc6ZoKtbqTq7DDgyK1GiKigICqKePFeHZkg
RpqYEQ7UUc9w9x4+dcgnrOKc1wyeI/j5zM5jCZ6NuaPCS7mTRsuRUGlbHgmRanw=
=TIgi
-----END PGP SIGNATURE-----

--R3G7APHDIzY6R/pk--