cryptlib is licensed under the Sleepycat license with a SaaS restriction:
“Note that decoupling the software from the user, for example by running in a SaaS configuration, does not exempt you from these requirements.”
(Full text attached.)
This was not part of the original Sleepycat license, so a new license tag is required.
Maybe this license is not even free; this additional clause seems to be a restriction on use. But perhaps it is not so different from the AGPL.
Thanks, Florian
On Mon, Jul 04, 2016 at 08:33:02AM +0200, Florian Weimer wrote:
cryptlib is licensed under the Sleepycat license with a SaaS restriction:
“Note that decoupling the software from the user, for example by running in a SaaS configuration, does not exempt you from these requirements.”
(Full text attached.)
This was not part of the original Sleepycat license, so a new license tag is required.
Maybe this license is not even free; this additional clause seems to be a restriction on use. But perhaps it is not so different from the AGPL.
It's not really clear how the additional sentence modifies "these requirements". I suppose it suggests that the author equates "running in a SaaS configuration" as equivalent to "redistribution". This degree of restrictiveness is difficult to reconcile with either GPLv2 or GPLv3.
I am also mindful of the interpretive principle I used to occasionally espouse, essentially that we should scrutinize especially closely the conditions of any bespoke copyleft license (or standard copyleft license apparently supplemented by bespoke informal restrictive interpretive statements), where the business model of the licensor is some variant of 'proprietary relicensing', as (it seems) here.
So, overall I'm inclined to say this license (which is not equivalent to the Sleepycat license) is free but should be treated as incompatible with GPLv2 and GPLv3, despite the author's effort to benefit from the traditional understanding of GPL compatibility of the original Sleepycat license, and despite my earlier comment.
Separately, I am going to notify Patrick Masson of the Open Source Initiative that cryptlib appears to be improperly claiming OSI certification based on the use of a license that is not OSI-approved.
Richard
On Mon, Jul 04, 2016 at 12:23:00PM -0400, Richard Fontana wrote:
I am also mindful of the interpretive principle I used to occasionally espouse, essentially that we should scrutinize especially closely the conditions of any bespoke copyleft license (or standard copyleft license apparently supplemented by bespoke informal restrictive interpretive statements), where the business model of the licensor is some variant of 'proprietary relicensing', as (it seems) here.
So, overall I'm inclined to say this license (which is not equivalent to the Sleepycat license) is free but should be treated as incompatible with GPLv2 and GPLv3,
I have a couple of additional concerns, though, regarding "informal restrictive interpretive statements":
In the FAQ for Cryptlib, it is said that "All commercial users must obtain a commercial license" [1], and separately [2] it is said that
"Any software you create with this code may not be merely a set or subset of cryptlib, with or without minor added functionality or a different interface. In particular you can’t distribute cryptlib (or any modified form of it) as your own encryption or security product. This is to stop users adding their own wrappers and selling it as “their” software product."
which I confess I don't quite understand if it is not a blanket prohibition on creating derivative works or a prohibition on rebranding of derivative works.
On the same page the author says "Any and all large-scale commercial use of cryptlib requires a license." which I now take to mean "a license other than my bespoke version of the Sleepycat license".
So, my revised view is that this license is sufficiently concerning that it should be treated as nonfree pending some adequate clarifications from the author. (If I were to reach a different conclusion I think I'd then be acting inconsistently with my past views on such things as the notorious iText license.)
[1]http://www.cryptlib.com/security-faq [2]http://www.cryptlib.com/security-software/licensing
On Mon, Jul 04, 2016 at 12:23:00PM -0400, Richard Fontana wrote:
I have a couple of additional concerns, though, regarding "informal restrictive interpretive statements":
In the FAQ for Cryptlib, it is said that "All commercial users must obtain a commercial license" [1], and separately [2] it is said that
If you go to the commercial cryptlib web site it is no wonder that you read everything about the COMMERCIAL license and nothing about the GPL-compatible license which is used in Fedora.
So please make a distinction between both licenses and don't confuse objections you may have with the one in question.
If you go to the commercial cryptlib web site it is no wonder that you read everything about the COMMERCIAL license and nothing about the GPL-compatible license which is used in Fedora.
Well, looking in the COPYING file in Fedora, it says:
This file contains the usage terms for cryptlib. The full details of cryptlib usage are provided on the cryptlib home page; although this file and the information on the web page should be identical, in case of any dispute the web page takes precedence. This file is included because some distributions require the presence of a COPYING file.
So, I'm not sure if it's invalid to look at the website for the current license. (note that I'm not a lawyer, so I have no idea whatsoever whether this kind of statement is even effective).
So please make a distinction between both licenses and don't confuse objections you may have with the one in question.
Regards, Patrick Uiterwijk
On Mon, Jul 04, 2016 at 08:33:02AM +0200, Florian Weimer wrote:
It's not really clear how the additional sentence modifies "these requirements".
It does not modify "these requirements" at all. It states, that there are no exceptions to providing source code to the user in every case. (SaaS is only one example)
I suppose it suggests that the author equates "running in a SaaS configuration" as equivalent to "redistribution". This degree of restrictiveness is difficult to reconcile with either GPLv2 or GPLv3.
There is no restrictiveness with respect to using the software, if source code is provided to the user.
I am also mindful of the interpretive principle I used to occasionally espouse, essentially that we should scrutinize especially closely the conditions of any bespoke copyleft license (or standard copyleft license apparently supplemented by bespoke informal restrictive interpretive statements), where the business model of the licensor is some variant of 'proprietary relicensing', as (it seems) here.
Cryptlib is dual-licensed. Only the GPL-compatible license is used not the commercial one, which is independent from the license used for cryptlib in Fedora.
On Mon, Jul 04, 2016 at 06:17:18PM -0000, Ralf Senderek wrote:
It's not really clear how the additional sentence modifies "these requirements".
It does not modify "these requirements" at all. It states, that there are no exceptions to providing source code to the user in every case. (SaaS is only one example)
The "requirements" are said to be about "redistribution" so it seems to be a clarification about what "redistribution" means.
It would be helpful to know what other than conventional redistribution and "running in a SaaS configuration" would trigger the source code requirement.
I suppose it suggests that the author equates "running in a SaaS configuration" as equivalent to "redistribution". This degree of restrictiveness is difficult to reconcile with either GPLv2 or GPLv3.
There is no restrictiveness with respect to using the software, if source code is provided to the user.
Possibly, but even if the license is free it might still be GPL-incompatible.
Richard
-
Florian Weimer -
Patrick マルタインアンドレアス Uiterwijk -
Ralf Senderek -
Richard Fontana