choosing a standard OS license for Crypto++

[Wei Dai]

Thanks to some prodding from Zooko, I've decided that the main reasons for
Crypto++ having its own license no longer applies, so I might as well choose
a standard open source license for it. The Boost Software License (see
http://www.opensource.org/licenses/bsl1.0 and
http://www.boost.org/users/license.html), with an added disclaimer that the
library is only copyrighted as a compilation, seems suitable since like the
current Crypto++ license it doesn’t require the copyright notice and
license to be included in object code distributions. Does anyone have any
other suggestions or comments?

[Marshall Clow]

On Jul 10, 2012, at 8:07 PM, Wei Dai wrote:

> Thanks to some prodding from Zooko, I've decided that the main reasons for Crypto++ having its own license no longer applies, so I might as well choose a standard open source license for it. The Boost Software License (see http://www.opensource.org/licenses/bsl1.0 and http://www.boost.org/users/license.html), with an added disclaimer that the library is only copyrighted as a compilation, seems suitable since like the current Crypto++ license it doesn’t require the copyright notice and license to be included in object code distributions. Does anyone have any other suggestions or comments?

I've released a lot of code (Boost, ASL and others) under the BSL (hrm, need more acronyms), and haven't had any problems nor complaints.

If there's anything left in crypto++ that I have committed, you have my permission to relicense it under the BSL (not that you need it)

-- Marshall

Marshall Clow Idio Software <mailto:mclow...@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
-- Yu Suzuki

[Geoff Beier]

I'd be very curious to hear the reasoning behind the change in a little more detail, but really only as another datapoint to inform my own release decisions later. I like this specific choice because every single piece of software I've ever used crypto++ in has also used boost. So this change does not add anything new to explain to other stakeholders; I already had to explain the BSL anyway.

Geoff

On Tuesday, July 10, 2012, Wei Dai wrote:

Thanks to some prodding from Zooko, I've decided that the main reasons for Crypto++ having its own license no longer applies, so I might as well choose a standard open source license for it. The Boost Software License (see http://www.opensource.org/licenses/bsl1.0 and http://www.boost.org/users/license.html), with an added disclaimer that the library is only copyrighted as a compilation, seems suitable since like the current Crypto++ license it doesn’t require the copyright notice and license to be included in object code distributions. Does anyone have any other suggestions or comments?

--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.

[Zooko Wilcox-O'Hearn]

Dear Wei Dai:

Great! Thank you!

On the Twisted issue ticket, Glyph made a good suggestion:

"""
Just one note (since I'm not on that mailing list): there's really no
need to put the "only copyrighted as a compilation" thing into the
license itself. It can be an informative note somewhere else in the
code or on the website, since the license by definition only applies
to the copyrighted material. (Putting anything into the license itself
can have weird knock-on effects. For example, let's say someone wants
to release a crypto++ enhancement that is open source, but cannot be
not public domain for some reason. Now, their enhancement is
copyrighted as an individual file and as a compilation. But one of the
requirements of the license is to distribute the license verbatim. Can
they do that? One thing is for sure: they'll have to ask a lawyer.)
""" -- Glyph

http://twistedmatrix.com/trac/ticket/4633#comment:27


A technique that I've used to make things easier for downstream users
is to make software available under multiple licences, at the user's
discretion. This "multi-licensing" technique was used prominently by
Mozilla a few years back, when they started distributing Firefox under
your choice of GPL, LGPL, or Mozilla Public Licence.

For example, you could publish Crypto++ under the receipient's choice
of MIT, Boost, or the original Crypto++ licence. This is redundant and
meaningless for most people, because all of those licences give them
more or less the same options, but it might help if some open source
project A (or some lawyers in Company A) require all licences to be
Boost and some open source project B (or some lawyers in Company B)
require all licences to be MIT.

Regards,

Zooko

[Wei Dai]

Thanks for everyone's comments. Since there weren't any objections, please
consider Crypto++ Library version 5.6.1 to be dual licensed under the
current Crypto++ license and the Boost Software License. The next version
will probably be licensed under BSL only, unless someone has an argument
against that.

[Zooko Wilcox-O'Hearn]

It would simplify matter for me as maintainer of pycryptopp, which
includes a copy of Crypto++, as well as for downstream packagers of
pycryptopp in systems such as Debian, if you would license Crypto++ as
"either BSL or MIT licence at your option". This is because the next
version of pycryptopp will be "either GPLv2+, TGPPLv1+, SPL, or MIT
licence at your option". This is because Twisted Python is under MIT.
Once all three of these packages have a licence in common among them,
then downstream users can opt to use all three packages under that
licence, thus simplifying the documentation that they have to write
about licensing.

Regards,

Zooko