* [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.
@ 2016-09-24 0:21 Gregory Maxwell
2016-09-26 18:41 ` Peter Todd
0 siblings, 1 reply; 4+ messages in thread
From: Gregory Maxwell @ 2016-09-24 0:21 UTC (permalink / raw)
To: 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.
2016-09-24 0:21 [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option Gregory Maxwell
@ 2016-09-26 18:41 ` Peter Todd
2016-09-27 9:51 ` Tom
0 siblings, 1 reply; 4+ messages in thread
From: Peter Todd @ 2016-09-26 18:41 UTC (permalink / raw)
To: Gregory Maxwell, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.
2016-09-26 18:41 ` Peter Todd
@ 2016-09-27 9:51 ` Tom
2016-09-27 19:17 ` Peter Todd
0 siblings, 1 reply; 4+ messages in thread
From: Tom @ 2016-09-27 9:51 UTC (permalink / raw)
To: bitcoin-dev
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!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option.
2016-09-27 9:51 ` Tom
@ 2016-09-27 19:17 ` Peter Todd
0 siblings, 0 replies; 4+ messages in thread
From: Peter Todd @ 2016-09-27 19:17 UTC (permalink / raw)
To: Tom, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-09-27 19:17 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-24 0:21 [bitcoin-dev] Proposed BIP-1 change removing OPL licensing option Gregory Maxwell
2016-09-26 18:41 ` Peter Todd
2016-09-27 9:51 ` Tom
2016-09-27 19:17 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox