1:33 a.m.
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
11:23 a.m.
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
11:39 a.m.
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
1:21 p.m.
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.
4:36 a.m.
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
1:17 p.m.
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.
9:59 p.m.
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
2837
days inactive
2846
days old
6 comments
4 participants
participants (4)
-
Florian Weimer -
Patrick マルタインアンドレアス Uiterwijk -
Ralf Senderek -
Richard Fontana