ISC considering a change to the BIND open source license

[Robert Edmonds]

Victoria Risk wrote:
> Hi Robert,
> 
> > I don't think the MPL-2.0 has a "pay for an exception" clause, so this
> > would seem to imply that you plan to dual license BIND, or license BIND
> > under a modified license based on the MPL-2.0. Is that correct?
> 
> You are correct. We expect that some of the commercial vendors, many of whom who have invested years in BIND modifications, will not be able or willing to open source all their modifications, so we plan to negotiate a dual license with those that want this. I think it was Richard Stallman who coined the term ‘license exception’, maybe it is not a precise legal characterization.

Hi, Vicky:

Thanks for clarifying this. I actually think that the move to dual
licensing is bigger news than the move from ISCL to another FLOSS
license.

> We don’t have a model for what this license might look like yet. We did get some suggestions along those lines while we were soliciting comments, including one creative suggestion that we try to extract patches with a promise that we will delay incorporating them.  (which some would say is an awful lot like what we do already!)
> 
> The general idea is, helping to support a core maintainer can be as useful to the project as submitting patches, or more useful.  We end up substantially re-writing quite a few of the patches we receive, often because they don’t work under every OS we support. The commercial vendors in particular tend to optimize for a single OS.

Incidentally, and unrelated to the licensing discussion, is there an
official list of operating systems that ISC supports? There is a list of
“recent reports” in the BIND README file, but it's somewhat dated.

> > Can you clarify what "...that you intend to relinquish exclusive
> > copyright" means? This sounds vaguely like an implicit contributor
> > license agreement.
> 
> I did not write that, I think probably Evan did. Yes, I think it is intended as an implicit contributor agreement.
> 
> We did get a number of explicit requests that we not require contributors to sign a form before submitting a patch, so I think what we will have to do is have a more thorough ‘implicit contributor agreement’ and do a better job of ensuring submitters actually see it.  The contributor information on our web site is in a half-and-half state, kind of like beta right now.  I just whacked in that sentence about having different licenses for different versions as a starting place, we are not done yet.

The only contributor contributor agreement that I know of that doesn't
requiring executing a legal document is the Developer's Certificate of
Origin:

    http://developercertificate.org/

It's used in the Linux kernel project where all patches must be
explicitly marked with a "Signed-off-by" line to indicate acceptance of
the DCO. There is a good article on LWN about it here:

    https://lwn.net/Articles/592503/

But the kernel project is an extremely liberal project: contributors
retain their own copyright, and only certify (via the DCO) that their
contribution is made under a license compatible with the kernel's
licensing status.

I'm not aware of any open source projects that employ multi-licensing
without requiring the execution of some sort of legal agreement. The DCO
(or a DCO-like mechanism) is probably not appropriate for a project that
wants to employ multi-licensing.

> > I'm also confused as to how you plan to not require a contributor
> > agreement, while still being able to sell exceptions to the restrictions
> > in the MPL-2.0. E.g., suppose an external contributor writes 1000 lines
> > of new code, and licenses it under MPL-2.0 by putting a copyright notice
> > and license grant at the top:
> 
> We don’t have all the answers.
> A 1000-line contribution would be an exceptional one for BIND.  Most of the contributions I have seen are more like 20 lines.  In the case of Kea, where we were offered a large contribution, we agreed that their contribution could be their copyright and under a different (Apache) license as the contribution could also be in a separate file. (I am not sure whether that is what they did, however, they were going to check with their business people).  It will be messy to have different licenses on different files, but it is possible.

I used the "1000 lines" part only to indicate what would be an
unambiguously substantial contribution. Does 20 lines of code count as a
substantial contribution? (You probably don't want to risk it, given a
recent court battle between two giant software companies over the status
of 9 lines of code.)

BTW, if you haven't seen it before, I recommend reading this document
from the Software Freedom Law Center:

    https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html

> Clearly we are going to need a more extensive ‘implicit contributor agreement’.  Once we have a repo where people can submit pull requests for their patches, we will also have a much better way to ensure that contributors are aware of how their patches will be licensed at the time they are making the contribution.  I hope we can have our patch contribution site up by the 9.11 final and have our contributor guidelines updated by then.

If you are planning to use GitHub (or an open source-ish clone like
GitLab that supports hooks), one practice I've seen is a bot that tracks
whether contributors have agreed to contribute changes under an
agreement, and nags them if they haven't. E.g., here's an example from
Google's protobuf project:

    https://github.com/google/protobuf/pull/1713

In Google's case, it's a traditional CLA that must be signed, although
they permit e-signing.

> > /*
> > * Copyright © 2017 James Hacker
> > *
> > * This Source Code Form is subject to the terms of the Mozilla Public
> > * License, v. 2.0. If a copy of the MPL was not distributed with this
> > * file, You can obtain one at http://mozilla.org/MPL/2.0/.
> > */
> > 
> > How does ISC then both a) Merge this contribution into the BIND
> > mainline, and b) Sell a "pay for exception" version of BIND containing
> > this contribution?
> 
> If you are asking about the legality, I am going to have to wait for Jeff and Brian, who are both in Helsinki at ICANN, to comment on this.  Other projects do this (I think MySQL is the typical example) so it is evidently possible.  Obviously we need to communicate clearly to prospective contributors that a dual license is a possibility.  For years their contributions have formed the basis for a number of closed source commercial products, so the possibility of a commercial use won’t be too surprising.

My original question was under the assumption that you weren't dual
licensing (in which case a+b seems impossible). So now my question
shifts to how you obtain appropriate consent for contributors to have
their contributions re-licensed :-)

> Earlier contributions will remain available under the ISC license in earlier versions (including the 9.11.0 alpha releases).  We do have some pending patches that were submitted before this change that have not been integrated. I don’t think any of those are significant, but perhaps we should not integrate them unless/until we confirm that they are ok with the new license and the likelihood of exceptions or dual licensing.

Given that the ISCL is incredibly permissive and permits
proprietarization, I don't see much point in worrying about moving those
pending patches to the new license, unless you have some concern over
patents (which the ISCL doesn't cover at all). IANAL, TINLA, YMMV, HTH,
HAND, etc.

-- 
Robert Edmonds