Bug 1352406

I forgot that cryptlib is not actually licensed under the Sleepycat license, but a variant of it:

https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/4V2FNAH47BGZKKMP35U3NUWAWURUW2UO/

The actual license is similar in effect to the AGPL because it seems to require redistribution of source code to users who interact with the library (and the applications which use it) over the network.

I agree that the Cryptlib license is not equivalent to the Sleepycat license. The Cryptlib license has not yet been determined to meet Fedora's legal requirements.

(In reply to Florian Weimer from comment #0)
> Parts of cryptlib derive from OpenSSL and use the OpenSSL.  Some of the
> cryptographic routines use different licenses still.  Please update the
> License tag to reflect reality more closely.

OK, if changing the license tag to "Sleepycat and OpenSSL" covers everything I can update this in the next release.

(In reply to Richard Fontana from comment #2)
> I agree that the Cryptlib license is not equivalent to the Sleepycat
> license. The Cryptlib license has not yet been determined to meet Fedora's
> legal requirements.

This is not true. Sleepycat is listed under "good licenses" in the Fedora Software License list.

https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses

(In reply to Ralf Senderek from comment #4)
> (In reply to Richard Fontana from comment #2)
> > I agree that the Cryptlib license is not equivalent to the Sleepycat
> > license. The Cryptlib license has not yet been determined to meet Fedora's
> > legal requirements.
> 
> This is not true. Sleepycat is listed under "good licenses" in the Fedora
> Software License list.
> 
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#SoftwareLicenses

Ralf, please see the discussion referenced in comment 1.  The overall license terms of cryptlib are unclear at this point.

(In reply to Florian Weimer from comment #1)
> I forgot that cryptlib is not actually licensed under the Sleepycat license,
> but a variant of it:
> 
> https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/
> thread/4V2FNAH47BGZKKMP35U3NUWAWURUW2UO/
> 
> The actual license is similar in effect to the AGPL because it seems to
> require redistribution of source code to users who interact with the library
> (and the applications which use it) over the network.

The only difference between the cryptlib license and the original Sleepycat
license is a clarification in paragraph 3, which reads:

     "Note that decoupling the software from the user, for example by running
      in a SaaS configuration, does not exempt you from these requirements."

And "these requirements" refer to the provision of source code to the user.
This additional clarification does not impose a use restriction but makes it
clear that there is no exception from providing source code to the user. 
A use case where it is not possible to provide source code is of course not
suitable for free software.

(In reply to Florian Weimer from comment #5)
> (In reply to Ralf Senderek from comment #4)
 
> Ralf, please see the discussion referenced in comment 1.  The overall
> license terms of cryptlib are unclear at this point.

The discussion in comment 1 is (at least partly) based on a confusion between the commercial license for cryptlib and the separate GPL-compatible license for cryptlib. Cryptlib is dual-licensed, so the commercial license is irrelevant because it is not used in Fedora.

(In reply to Ralf Senderek from comment #6)
> The only difference between the cryptlib license and the original Sleepycat
> license is a clarification in paragraph 3, which reads:
> 
>      "Note that decoupling the software from the user, for example by running
>       in a SaaS configuration, does not exempt you from these requirements."
> 
> And "these requirements" refer to the provision of source code to the user.
> This additional clarification does not impose a use restriction but makes it
> clear that there is no exception from providing source code to the user.

But the Sleepycat license has generally been understood as *not* embodying such an "exception", which is reasonable given that there is nothing in the text of the Sleepycat license that would support the interpretation suggested by the "clarification" added in the Cryptlib license. Therefore the Cryptlib license is potentially as different from the Sleepycat license as AGPLv3 is from GPLv3. So I believe the Cryptlib license should have received a degree of review that I don't think it got given that it was assumed to be equivalent to the Sleepycat license.

(In reply to Richard Fontana from comment #8)
> (In reply to Ralf Senderek from comment #6)

> > And "these requirements" refer to the provision of source code to the user.
> > This additional clarification does not impose a use restriction but makes it
> > clear that there is no exception from providing source code to the user.
> 
> But the Sleepycat license has generally been understood as *not* embodying
> such an "exception",

Correct, the Sleepycat license does not allow any exception from providing source code to the user. And that's why stating that you must provide source code to the user in a SaaS configuration or a similar situation does not change
anything in the original Sleepycat license.

> which is reasonable given that there is nothing in the
> text of the Sleepycat license that would support the interpretation
> suggested by the "clarification" added in the Cryptlib license.

Of course there is. The paragraph 3 starts with 
   "3. Redistributions in any form must be accompanied by information on how to
     obtain complete source code for the cryptlib software and any accompanying
     software that uses the cryptlib software."

This requirement has to be met by "any form of redistribution", especially in 
a SaaS configuration and any other use case.

The rest of paragraph 3 reads:
    
    "The source code must either be
     included in the distribution or be available for no more than the cost of
     distribution, and must be freely redistributable under reasonable
     conditions.  For an executable file, complete source code means the source
     code for all modules it contains or uses.  It does not include source code
     for modules or files that typically accompany the major components of the
     operating system on which the executable file runs."

The following additional note (see comment #6) ,which is the cause of all this
confusion, refers to the fact, that in a SaaS (or equivalent) environment every
executable file that uses cryptlib to provide the service triggers the
requirement to provide full source code to the user. 
This can be done by making the source code "available for no more than the
cost of [the] distribution", i.e. on the service providers website.
The additional sentence does not change anything in the original license in
any way.


> So I believe the Cryptlib license should have
> received a degree of review that I don't think it got given that it was
> assumed to be equivalent to the Sleepycat license.

I'm sure that some people have reviewed this license very carefully.

(In reply to Ralf Senderek from comment #9)
> (In reply to Richard Fontana from comment #8)
 
> > But the Sleepycat license has generally been understood as *not* embodying
> > such an "exception",
> 
> Correct, the Sleepycat license does not allow any exception from providing
> source code to the user. 

Sorry, I was confused there because it is odd to speak of 'exceptions' in this case. I mean: the Sleepycat license (like other free software licenses speaking of (re)distribution without defining the term), I contend, is generally understood not to require providing source code to a notional user in situations not involving conventional distribution of the code in question. So it is not a matter of "exceptions" but rather the standard view of what distribution is.

Your interpretation of "(re)distribute" would have far-reaching implications for other free software licenses that have distribution-triggered conditions, such as GPLv2, GPLv3, the 3-clause BSD license (on which the Sleepycat license is based), and the Apache License 2.0. If we were to encounter, say, a modified version of GPLv2 with a "SAAS configuration" clause added to it we'd have to examine it very closely to make sure it was a free software license and to assess GPL compatibility. We couldn't simply assume that because GPLv2 is acceptable, an altered version of GPLv2 that purportedly clarifies the meaning of GPLv2 would be acceptable.

This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

To summarize the objections that have been expressed
by Richard Fontana and others against the Cryptlib license,
as far as I am aware of:

A) The Cryptlib software relies on code that is taken
   from the OpenSSL project which is distributed together
   with the Cryptlib software.

B) The Cryptlib license is not equivalent to the Sleepycat
   license because it contains an additional sentence that
   is seen as an "additional (SaaS) restriction".

C) Special use cases, like SaaS, are generally understood
   to not be a case of "(re)distribution", so the requirement
   to provide source code does, in this view, not apply.
   To mention such a use case in the license text may
   invalidate the "acceptance" of the license. (comment #10)

D) The Cryptlib license is not acceptable for Fedora
   because of "unclear" terms on the open-source website.
   (https://www.cs.auckland.ac.nz/~pgut001/cryptlib/download.html)

E) The open-source website contains conditions that are
   effectively rewriting the (otherwise acceptable) Sleepycat
   license.


Based on my current knowledge, I'd like to respond to these
concerns.

Re A) This is true, so the license tag for the Cryptlib
      package is changed to "Sleepycat and OpenSSL" from
      release 3.4.3-8.

Re B) Peter Gutmann has removed this sentence from the 
      body of the license text making it 100 percent
      Sleepycat equivalent.
      
Re C) The SaaS-sentence is no longer a part of the license
      text. The license text starts with the words
      "Copyright 1992-2016 Peter Gutmann." and ends with
      the disclaimer.

Re D) The COPYING file has very clear words directly after
      the Sleepycat license text, it reads:

         "If you're unable to comply with the above license
         then the following, alternate usage conditions apply:"

      Usually, if you cannot comply with the requirements
      of a license (i.e GPL or Sleepycat or whatever) you
      don't have a license and you cannot use the software.

      For Cryptlib, in this case, it is possible to use Cryptlib
      under a different, commercial license. But whatever
      alternative usage terms are set out under the commercial
      license, they only apply, if the terms of the Sleepycat
      licensed cannot (or deliberately will not) be adhered to.
      This is by no means unclear.

Re E)  Let's have a look at all of these:

      1) "If you use cryptlib, you must give the authors credit
          in your software and/or documentation."
         
	 This is not rewriting the Sleepycat license, but results
	 from the fact that any use of Cryptlib has to adhere to
	 the terms of the OpenSSL license that require to mention
	 John Young and others as the authors of code Cryptlib
	 relies on.

      2) " ... you can't distribute cryptlib (or any modified form
           of it) as your own encryption product."

         This is neither rewriting Sleepycat nor an additional
	 license condition, because both Sleepycat and OpenSSL
	 forbid to remove copyright notices from the software.
	 Distributing Cryptlib "as your own encryption product",
	 saying that "you" have written this encryption product,
	 would require such illegal software modification or
	 not providing source code at all, which is forbidden
	 by Sleepycat. This is just stating the obvious, which
	 historically wasn't that obvious for a multibillion
	 dollar company.

     3)  "Any large-scale commercial use of cryptlib requires
          a license."	 

         This does clearly only apply, "If you're unable to
	 comply with the above [Sleepycat] license ... "

         Unlimited commercial use of Cryptlib is of course allowed
	 if all 3 conditions of the Sleepycat liceses are adhered
	 to, which includes publication of a company's own source
	 code that uses Cryptlib.
	 If a company does now want to provide their own source
	 code when distributing or using Cryptlib, they cannot
	 use Sleepycat and must apply for a different license to
	 the author. Nothing unclear about that.

     All in all, nothing on the open-source website can be seen as
     an additional restriction to Sleepycat that would justify
     the exclusion of Cryptlib as a legitimate (and maybe welcome)
     package for Fedora.

Richard, may I ask you to remove the block "FE-LEGAL" from this bug.

cryptlib-3.4.3-8.f25

http://koji.fedoraproject.org/koji/taskinfo?taskID=15025598

(In reply to Ralf Senderek from comment #12)
 
> D) The Cryptlib license is not acceptable for Fedora
>    because of "unclear" terms on the open-source website.
>    (https://www.cs.auckland.ac.nz/~pgut001/cryptlib/download.html)
[...] 
> Re D) The COPYING file has very clear words directly after
>       the Sleepycat license text, it reads:
> 
>          "If you're unable to comply with the above license
>          then the following, alternate usage conditions apply:"
> 
>       Usually, if you cannot comply with the requirements
>       of a license (i.e GPL or Sleepycat or whatever) you
>       don't have a license and you cannot use the software.
> 
>       For Cryptlib, in this case, it is possible to use Cryptlib
>       under a different, commercial license. But whatever
>       alternative usage terms are set out under the commercial
>       license, they only apply, if the terms of the Sleepycat
>       licensed cannot (or deliberately will not) be adhered to.
>       This is by no means unclear.

The idea that you have a choice of two or more licenses is itself clear. The concern was that the commentary from the author relating to the author's views on when one is unable to comply with the putative open source license created a general atmosphere of confusion surrounding how to interpret that putative open source license.

(In reply to Ralf Senderek from comment #12)
 
> E) The open-source website contains conditions that are
>    effectively rewriting the (otherwise acceptable) Sleepycat
>    license.
[...]  
> Re E)  Let's have a look at all of these:
> 
>       1) "If you use cryptlib, you must give the authors credit
>           in your software and/or documentation."
>          
> 	 This is not rewriting the Sleepycat license, but results
> 	 from the fact that any use of Cryptlib has to adhere to
> 	 the terms of the OpenSSL license that require to mention
> 	 John Young and others as the authors of code Cryptlib
> 	 relies on.

I don't think it is likely that the cryptlib author meant to refer to the OpenSSL license there. 

>       2) " ... you can't distribute cryptlib (or any modified form
>            of it) as your own encryption product."
> 
>          This is neither rewriting Sleepycat nor an additional
> 	 license condition, because both Sleepycat and OpenSSL
> 	 forbid to remove copyright notices from the software.
> 	 Distributing Cryptlib "as your own encryption product",
> 	 saying that "you" have written this encryption product,
> 	 would require such illegal software modification or
> 	 not providing source code at all, which is forbidden
> 	 by Sleepycat. This is just stating the obvious, which
> 	 historically wasn't that obvious for a multibillion
> 	 dollar company.

"Distributing [something] as your own encryption product" does not obviously mean the same thing as "removing all upstream copyright notices". I ought to be able to distribute a modified form of cryptlib as "richardlib" -- as my own encryption product, with my own name and branding -- so long as I comply with the requirements of the license we are assuming is equivalent to the Sleepycat license. 

> Richard, may I ask you to remove the block "FE-LEGAL" from this bug.

I've had some correspondence with the upstream author and need to catch up on that. It is possible that the issues I've been concerned about are all or nearly all resolved by the most recent response from the author. Thank you for your patience; your interest in having Fedora distribute cryptlib is certainly appreciated.

For all who are still (pretending to be) confused, this is the LOGIC of the licensing behind Cryptlib:

IF (means: only if) (you comply with the OpenSSL license):

      # you have to mention John Young etc. in your binary or source

      IF (you comply with all 3 paragraphs of Sleepycat):

            # you have to mention Peter Gutmann's copyright in your docs
	    # you have to provide the disclaimer
	    # you have to provide source code of your own code that
	    # uses Cryptlib

            -> you can use Cryptlib under two open-source licenses 
	       (OpenSSL and Sleepycat)
	       (that is what Fedora does)
               Note, this includes unlimited commercial use!


      ELSE:
            # maybe you don't want to provide source code (paragraph 3)
	    # or you want to remove the copyright notice  (paragraph 1,2)
	    # or the disclaimer

            IF (using Cryptlib generates more than USD 5000):
	          -> you can use Cryptlib with a license you pay for
	    ELSE:
	          -> you can use Cryptlib free of charge under a 
		     commercial license

ELSE:
      -> you cannot use Cryptlib (at all)

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.