Proposed BIP-1 change removing OPL licensing option.

I've proposed a revision to BIP-1 that removes the option to license the work under the OPL: https://github.com/bitcoin/bips/pull/446

The OPL contains troublesome terms where the licensor can elect to prohibit print publication of the work as well as the creation of modified versions without their approval.

"Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder." "Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder."

Additionally, even without these optional clauses the specific construction of this licenses' attribution requirements are restrictive enough that Debian does not consider it acceptable for works included in their distribution (https://lists.debian.org/debian-legal/2004/03/msg00226.html).

I can't find any discussion that indicates anyone involved with the project was aware of these clauses at the time this text was added... and I believe they are strongly incompatible with having a transparent, public, collaborative process for the development of standard for interoperablity. I certainly wasn't aware of it, and would have argued against it if I was.

Moreover, the project that created this license has recommended people use creative commons licenses instead since 2007.

The only BIPs that have availed themselves of this are BIP145 (which is dual licensed under the permissive 2-clause BSD, which I wouldn't object to adding as an option-- and which doesn't active the objectionable clauses) and the recently assigned BIP134.

On Sat, Sep 24, 2016 at 12:21:16AM +0000, Gregory Maxwell via bitcoin-dev wrote:

> I've proposed a revision to BIP-1 that removes the option to license
> the work under the OPL:  https://github.com/bitcoin/bips/pull/446
>
> The OPL contains troublesome terms where the licensor can elect to
> prohibit print publication of the work as well as the creation of
> modified versions without their approval.
>
> "Distribution of substantively modified versions of this document is
> prohibited without the explicit permission of the copyright holder."
> "Distribution of the work or derivative of the work in any standard
> (paper) book form is prohibited unless prior permission is obtained
> from the copyright holder."
>
> Additionally, even without these optional clauses the specific
> construction of this licenses' attribution requirements are
> restrictive enough that Debian does not consider it acceptable for
> works included in their distribution
> (https://lists.debian.org/debian-legal/2004/03/msg00226.html).
>
> I can't find any discussion that indicates anyone involved with the
> project was aware of these clauses at the time this text was added...
> and I believe they are strongly incompatible with having a
> transparent, public, collaborative process for the development of
> standard for interoperablity. I certainly wasn't aware of it, and
> would have argued against it if I was.
>
> Moreover, the project that created this license has recommended people
> use creative commons licenses instead since 2007.
>
> The only BIPs that have availed themselves of this are BIP145 (which
> is dual licensed under the permissive 2-clause BSD, which I wouldn't
> object to adding as an option-- and which doesn't active the
> objectionable clauses) and the recently assigned BIP134.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

ACK

Note how the OPL is significantly more restrictive than the Bitcoin Core license; not good if we can't ship documentation with the code.

On Monday 26 Sep 2016 14:41:36 Peter Todd via bitcoin-dev wrote:

> Note how the OPL is significantly more restrictive than the Bitcoin Core
> license; not good if we can't ship documentation with the code.

Documentation and code can have different licenses, the sole existence of various documentation licenses attests to that point. Shipping your docs under a separate licence has never been a problem before, so you don't have to worry that you can't ship documentation with code.

That said, I wrote my suggestion in reply to Luke's BIP2 revival which is a more formal suggestion of a solution. Maybe you can ACK that one instead?

Last, in preparation of acceptance of BIP2 I changed the licence of my BIP to be dual-licensed. Now its also available under a Creative Commons license.

Have a nice day!

On Tue, Sep 27, 2016 at 11:51:40AM +0200, Tom via bitcoin-dev wrote:

> On Monday 26 Sep 2016 14:41:36 Peter Todd via bitcoin-dev wrote:
> > Note how the OPL is significantly more restrictive than the Bitcoin Core
> > license; not good if we can't ship documentation with the code.
>
> Documentation and code can have different licenses, the sole existence of
> various documentation licenses attests to that point.
> Shipping your docs under a separate licence has never been a problem before,
> so you don't have to worry that you can't ship documentation with code.

The issue isn't that the licenses are different, it's that the OPL is significantly more restrictive (with the additional clauses that you opted into).

Indeed, using a different license for documentation is common advise, although if the documentation also includes example code you may want to dual-license the documentation with a code-oriented license as well if the documentation license isn't maximally permissive.

> That said, I wrote my suggestion in reply to Luke's BIP2 revival which is a
> more formal suggestion of a solution. Maybe you can ACK that one instead?
>
> Last, in preparation of acceptance of BIP2 I changed the licence of my BIP to
> be dual-licensed.  Now its also available under a Creative Commons license.

Thanks, CC-BY-SA is a perfectly good license for that purpose.