[bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

[Peter Todd]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161014/079c7104/attachment.sig>