ISC considering a change to the BIND open source license

Victoria Risk vicky at isc.org
Tue Jun 28 16:08:31 UTC 2016


Hi Robert,

> It looks like this was announced today:
> 
> https://www.isc.org/blogs/bind9-adopts-the-mpl-2-0-license-with-bind-9-11-0/
> 
>> The MPL license requires that anyone redistributing the code who has changed it must publish their changes (or pay for an exception to the license). It doesn’t impact anyone who is using the software without redistributing it, nor anyone redistributing it without changes – so most users will not see any change.
> 
> Can you clarify what "or pay for an exception to the license" means?
> I also see a similar statement in these slides:
> 
> https://ripe72.ripe.net/presentations/150-Relicensing-BIND.pdf
> 
>    • Probably Mozilla (MPL 2.0), possibly adding hosting clause
>      • Contribute changes or pay for exception license
>      • Not commercial software, just charging for exception
> 
> 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.  

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.   

> There is also this statement in your blog post:
> 
>    In addition, we will be updating our contributor guidelines so
>    technical contributors are aware of how their contributions will be
>    licensed.  We are considering other changes to the way people
>    contribute code changes.  We do not plan to add a contributor
>    agreement, based on the significant feedback we received against it.
> 
> Your contributor guidelines now read:
> 
>    https://www.isc.org/git/guidelines/
> 
>    ISC does not require an explicit copyright assignment for patch
>    contributions. However, by submitting a patch to ISC, you implicitly
>    certify that you are the author of the code, that you intend to
>    reliquish exclusive copyright, and that you grant permission to
>    publish your work under whichever is the standard license agreement
>    for the project you are submitting it for. (The license agreement
>    depends on the project and also the version, since we have changed
>    two projects from the ISC license to the Mozilla Public License 2.0)
> 
> It looks like that paragraph formerly read:
> 
>    https://web.archive.org/web/20160329142948/https://www.isc.org/git/guidelines/
> 
>    ISC does not require an explicit copyright assignment for patch
>    contributions. However, by submitting a patch to ISC, you implicitly
>    certify that you are the author of the code, that you intend to
>    reliquish exclusive copyright, and that you grant permission to
>    publish your work under the ISC license.
> 
> 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.

> 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.

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.  

> /*
> * 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.

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.  

Vicky




More information about the bind-users mailing list