Discussion:
[bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.
Gregory Maxwell via bitcoin-dev
2016-09-24 00:21:16 UTC
Permalink
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.
Peter Todd via bitcoin-dev
2016-09-26 18:41:36 UTC
Permalink
Post by Gregory Maxwell via bitcoin-dev
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
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Tom via bitcoin-dev
2016-09-27 09:51:40 UTC
Permalink
Post by Peter Todd via bitcoin-dev
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!
Peter Todd via bitcoin-dev
2016-09-27 19:17:07 UTC
Permalink
Post by Tom via bitcoin-dev
Post by Peter Todd via bitcoin-dev
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.
Post by Tom via bitcoin-dev
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
Loading...