OpenSSL and GPL incompatibility

[skittleys]

The OpenSSL and GPL licences are incompatible. Because of this conflict, offlineimap cannot be included in the next stable release of Debian.

The solution is fairly simple: you can add a special exemption. Other solutions include changing the licence (not recommended) or finding a way to not use OpenSSL.

Further reading:

• The Debian bug filed against the offlineimap package
• More detail about the conflicting clauses
• A usage example (scroll down a bit, or search for OpenSSL)
• Another usage example (GPL-3 specific)

[Bankq]

Wow, never knew before that one can include exception in GPL.

[Bankq]

Wow, never knew before that one can include exception in GPL.

[xnox]

OpenSSL exceptions for GPL code is quite common, as a copyright owner one can license things as one desires. However, for us to grant an exception we'd require to collect agreement from all copyright holders.

[xnox]

OpenSSL exceptions for GPL code is quite common, as a copyright owner one can license things as one desires. However, for us to grant an exception we'd require to collect agreement from all copyright holders.

[skittleys]

Your last message leaves the outcome of this issue unclear. Are you saying you won't relicense, or merely pointing out the effort involved? Has any action been taken?

At this point, offlineimap cannot be included in the next stable release of Debian. Testing will freeze on November 5th.

[skittleys]

Your last message leaves the outcome of this issue unclear. Are you saying you won't relicense, or merely pointing out the effort involved? Has any action been taken?

At this point, offlineimap cannot be included in the next stable release of Debian. Testing will freeze on November 5th.

[chris001]

How about this solution. Change imaplib2.py to use a new thin
SSL-abstraction layer object, which wraps all ssl-related calls, and
calls into either openssl, or gnutls, depending on user preference via
the .offlineimaprc config file setting (defaulting to gnutls when no
setting present).

Also, imaplibutils.py (our code) would need a couple of lines changed to
use the thin SSL-abstraction layer object (the import hashlib and the
call to hashlib.sha1() which directly uses openssl).

On 9/13/2014 8:57 AM, skittleys wrote:

Your last message leaves the outcome of this issue unclear. Are you
saying you won't relicense, or merely pointing out the effort
involved? Has any action been taken?

At this point, offlineimap cannot be included in the next stable
release of Debian. Testing will freeze on November 5th.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[chris001]

How about this solution. Change imaplib2.py to use a new thin
SSL-abstraction layer object, which wraps all ssl-related calls, and
calls into either openssl, or gnutls, depending on user preference via
the .offlineimaprc config file setting (defaulting to gnutls when no
setting present).

Also, imaplibutils.py (our code) would need a couple of lines changed to
use the thin SSL-abstraction layer object (the import hashlib and the
call to hashlib.sha1() which directly uses openssl).

On 9/13/2014 8:57 AM, skittleys wrote:

Your last message leaves the outcome of this issue unclear. Are you
saying you won't relicense, or merely pointing out the effort
involved? Has any action been taken?

At this point, offlineimap cannot be included in the next stable
release of Debian. Testing will freeze on November 5th.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[spaetz]

Thing is, offlineimap does not directly use openssl. We bundle the imaplib library by Piers Lauder(?). This has to be relicensed or needs to grant the exception, and we don't have copyright on that lib.

[spaetz]

Thing is, offlineimap does not directly use openssl. We bundle the imaplib library by Piers Lauder(?). This has to be relicensed or needs to grant the exception, and we don't have copyright on that lib.

[spaetz]

Actually, imaplib2.py which we bundle already has the python license, so that is fine. Someone needs tto makeba concertated effort to receive all contributors OK, for an openssl exception.

[spaetz]

Actually, imaplib2.py which we bundle already has the python license, so that is fine. Someone needs tto makeba concertated effort to receive all contributors OK, for an openssl exception.

[chris001]

How about a sign up form - for all contributors to grant an openssl
exception - form can be hosted on the offlineimap site - and offer
electronic signature - fully paperless.

On 9/18/2014 8:31 AM, Sebastian Spaeth wrote:

Actually, imaplib2.py which we bundle already has the python license,
so that is fine. Someone needs tto makeba concertated effort to
receive all contributors OK, for an openssl exception.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[chris001]

How about a sign up form - for all contributors to grant an openssl
exception - form can be hosted on the offlineimap site - and offer
electronic signature - fully paperless.

On 9/18/2014 8:31 AM, Sebastian Spaeth wrote:

Actually, imaplib2.py which we bundle already has the python license,
so that is fine. Someone needs tto makeba concertated effort to
receive all contributors OK, for an openssl exception.

—
Reply to this email directly or view it on GitHub
#104 (comment).

[spaetz]

On 18. September 2014 16:58:14 MESZ, Chris Coleman notifications@github.com wrote:

How about a sign up form - for all contributors to grant an openssl
exception - form can be hosted on the offlineimap site - and offer
electronic signature - fully paperless.

On 9/18/2014 8:31 AM, Sebastian Spaeth wrote:

Actually, imaplib2.py which we bundle already has the python license,

so that is fine. Someone needs tto makeba concertated effort to
receive all contributors OK, for an openssl exception.

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

Sure, just someone would have to do organize and do that.

Sebastian

Sent from mobile phone. Please excuse brevity

[spaetz]

On 18. September 2014 16:58:14 MESZ, Chris Coleman notifications@github.com wrote:

How about a sign up form - for all contributors to grant an openssl
exception - form can be hosted on the offlineimap site - and offer
electronic signature - fully paperless.

On 9/18/2014 8:31 AM, Sebastian Spaeth wrote:

Actually, imaplib2.py which we bundle already has the python license,

so that is fine. Someone needs tto makeba concertated effort to
receive all contributors OK, for an openssl exception.

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

Sure, just someone would have to do organize and do that.

Sebastian

Sent from mobile phone. Please excuse brevity

[spaetz]

P.s. it could be a Google sheet, no need to host it on offlineimap.org even.

Sent from mobile phone. Please excuse brevity

[spaetz]

P.s. it could be a Google sheet, no need to host it on offlineimap.org even.

Sent from mobile phone. Please excuse brevity

[chris001]

Is there available an updated, complete list of contributors, with names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub
#104 (comment).

[chris001]

Is there available an updated, complete list of contributors, with names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub
#104 (comment).

[spaetz]

On 20. September 2014 13:16:13 MESZ, Chris Coleman notifications@github.com wrote:

Is there available an updated, complete list of contributors, with
names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on
offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

No, somebody needs to extract it from the git log. :-(

Sent from mobile phone. Please excuse brevity

[spaetz]

On 20. September 2014 13:16:13 MESZ, Chris Coleman notifications@github.com wrote:

Is there available an updated, complete list of contributors, with
names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on
offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

No, somebody needs to extract it from the git log. :-(

Sent from mobile phone. Please excuse brevity

[chris001]

Sebastian, we might be able to escape the work of extracting
contributors' names and emails from the git logs, the following page
seems like it might be a rather complete list of 50 of our
contributors... except it has glaringly omitted at least one user,
nicolas33 !

https://github.com/offlineimap/offlineimap/graphs/contributors

Is there an administrative function in github to "send email message to
all contributors" ??
If yes... an email could be sent with a link to a page for GPL
exception, to accept each contributor's digital signature.
If no... will be necessary to manually grep git log for all 51+
contributor emails, then manually send email to all 51+ contributors
with link to page for GPL exception digital signature collection...

On 9/22/2014 11:34 AM, Sebastian Spaeth wrote:

On 20. September 2014 13:16:13 MESZ, Chris Coleman
notifications@github.com wrote:

Is there available an updated, complete list of contributors, with
names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on
offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

No, somebody needs to extract it from the git log. :-(

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub
#104 (comment).

[chris001]

Sebastian, we might be able to escape the work of extracting
contributors' names and emails from the git logs, the following page
seems like it might be a rather complete list of 50 of our
contributors... except it has glaringly omitted at least one user,
nicolas33 !

https://github.com/offlineimap/offlineimap/graphs/contributors

Is there an administrative function in github to "send email message to
all contributors" ??
If yes... an email could be sent with a link to a page for GPL
exception, to accept each contributor's digital signature.
If no... will be necessary to manually grep git log for all 51+
contributor emails, then manually send email to all 51+ contributors
with link to page for GPL exception digital signature collection...

On 9/22/2014 11:34 AM, Sebastian Spaeth wrote:

On 20. September 2014 13:16:13 MESZ, Chris Coleman
notifications@github.com wrote:

Is there available an updated, complete list of contributors, with
names
and current email addresses ?

On 9/20/2014 2:36 AM, Sebastian Spaeth wrote:

P.s. it could be a Google sheet, no need to host it on
offlineimap.org

even.

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub

#104 (comment).

---

Reply to this email directly or view it on GitHub:
#104 (comment)

No, somebody needs to extract it from the git log. :-(

Sent from mobile phone. Please excuse brevity

—
Reply to this email directly or view it on GitHub
#104 (comment).

[spaetz]

Cool, pretty sure there is no "email all users" button. The list would need some checkin for pre-git contributors, I guess.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[spaetz]

Cool, pretty sure there is no "email all users" button. The list would need some checkin for pre-git contributors, I guess.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[tohojo]

As one of the people who just received said email (thanks!), could someone clarify (or link to) an explanation of how a piece of software using features of the language standard library can be said to be affected by the license of said features? Or is that not the issue here?

Not trying to be obnoxious or anything (and am not necessarily opposed to adding the exception), I'm just trying to understand the issue better... :)

[tohojo]

As one of the people who just received said email (thanks!), could someone clarify (or link to) an explanation of how a piece of software using features of the language standard library can be said to be affected by the license of said features? Or is that not the issue here?

Not trying to be obnoxious or anything (and am not necessarily opposed to adding the exception), I'm just trying to understand the issue better... :)

[spaetz]

tohojo: As just send to the mailing list. Here my opinion:

1. I am no lawyer .

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

3. Even using python-licensed abstractions inbetween, I do believe there
   is some leeway to argue that offlineimap needs to adhere to the openssl
   terms (e.g. the advertising clause), making it inherently incompatible
   with python-based end user applications under the GNU GPL. Is this a
   problem that would apply to all python-based apps using openssl?
   Yes...,. I'd rather be better safe than sorry here.

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough, we
   need to be quick.

5. Better safe than sorry, and we have managed to get consent for more
   than 80% of our code contributions within 24hours.

6. Fun Fact: I am still waiting for Steve Hanson from the OpenSSL
   foundation to grant us an OpenSSL execption on his contribution .

I would be curious to find other python-based cases that were GNU GPL'd
apps got told off for sing openssl, or some discussion around the legal
stance, so if you have some, chime in.

For my part, would not have started this initiative if there had not
been specific action been taken against us (bugs filed), but now that I
started this, I believe adding the openssl exception won't hurt, so we
should pull it through.

Am I making sense?

[spaetz]

tohojo: As just send to the mailing list. Here my opinion:

1. I am no lawyer .

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

3. Even using python-licensed abstractions inbetween, I do believe there
   is some leeway to argue that offlineimap needs to adhere to the openssl
   terms (e.g. the advertising clause), making it inherently incompatible
   with python-based end user applications under the GNU GPL. Is this a
   problem that would apply to all python-based apps using openssl?
   Yes...,. I'd rather be better safe than sorry here.

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough, we
   need to be quick.

5. Better safe than sorry, and we have managed to get consent for more
   than 80% of our code contributions within 24hours.

6. Fun Fact: I am still waiting for Steve Hanson from the OpenSSL
   foundation to grant us an OpenSSL execption on his contribution .

I would be curious to find other python-based cases that were GNU GPL'd
apps got told off for sing openssl, or some discussion around the legal
stance, so if you have some, chime in.

For my part, would not have started this initiative if there had not
been specific action been taken against us (bugs filed), but now that I
started this, I believe adding the openssl exception won't hurt, so we
should pull it through.

Am I making sense?

[spaetz]

Linking to a mail by Steve Langasek explaining on how Debian does not consider openssl to be a system library (which would be permitted by the GNU GPL), as long as OfflineImap is shipped from the same repositories as openssl.
So downloading OfflineImap via PIP would presumably be OK to debian, but including OfflineImap into their standard repo no. https://lists.debian.org/debian-legal/2002/10/msg00113.html

[spaetz]

Linking to a mail by Steve Langasek explaining on how Debian does not consider openssl to be a system library (which would be permitted by the GNU GPL), as long as OfflineImap is shipped from the same repositories as openssl.
So downloading OfflineImap via PIP would presumably be OK to debian, but including OfflineImap into their standard repo no. https://lists.debian.org/debian-legal/2002/10/msg00113.html

[spaetz]

Another discussion on the python list dscussing the legalities of GNU GPL code:
https://mail.python.org/pipermail/python-dev/2011-March/109032.html (see other mails in this thread).
With differing opinions.

[spaetz]

Another discussion on the python list dscussing the legalities of GNU GPL code:
https://mail.python.org/pipermail/python-dev/2011-March/109032.html (see other mails in this thread).
With differing opinions.

[chris001]

Correction to typo in #6!
It's "Dr. Stephen Henson" from the OpenSSL Foundation.
Source: https://www.openssl.org/about/

On 9/24/2014 3:34 AM, Sebastian Spaeth wrote:

tohojo: As just send to the mailing list. Here my opinion:

1. I am no lawyer .

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

3. Even using python-licensed abstractions inbetween, I do believe there
   is some leeway to argue that offlineimap needs to adhere to the openssl
   terms (e.g. the advertising clause), making it inherently incompatible
   with python-based end user applications under the GNU GPL. Is this a
   problem that would apply to all python-based apps using openssl?
   Yes...,. I'd rather be better safe than sorry here.

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough, we
   need to be quick.

5. Better safe than sorry, and we have managed to get consent for more
   than 80% of our code contributions within 24hours.

6. Fun Fact: I am still waiting for Steve Hanson from the OpenSSL
   foundation to grant us an OpenSSL execption on his contribution .

I would be curious to find other python-based cases that were GNU GPL'd
apps got told off for sing openssl, or some discussion around the legal
stance, so if you have some, chime in.

For my part, would not have started this initiative if there had not
been specific action been taken against us (bugs filed), but now that I
started this, I believe adding the openssl exception won't hurt, so we
should pull it through.

Am I making sense?

—
Reply to this email directly or view it on GitHub
#104 (comment).

[chris001]

Correction to typo in #6!
It's "Dr. Stephen Henson" from the OpenSSL Foundation.
Source: https://www.openssl.org/about/

On 9/24/2014 3:34 AM, Sebastian Spaeth wrote:

tohojo: As just send to the mailing list. Here my opinion:

1. I am no lawyer .

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

3. Even using python-licensed abstractions inbetween, I do believe there
   is some leeway to argue that offlineimap needs to adhere to the openssl
   terms (e.g. the advertising clause), making it inherently incompatible
   with python-based end user applications under the GNU GPL. Is this a
   problem that would apply to all python-based apps using openssl?
   Yes...,. I'd rather be better safe than sorry here.

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough, we
   need to be quick.

5. Better safe than sorry, and we have managed to get consent for more
   than 80% of our code contributions within 24hours.

6. Fun Fact: I am still waiting for Steve Hanson from the OpenSSL
   foundation to grant us an OpenSSL execption on his contribution .

I would be curious to find other python-based cases that were GNU GPL'd
apps got told off for sing openssl, or some discussion around the legal
stance, so if you have some, chime in.

For my part, would not have started this initiative if there had not
been specific action been taken against us (bugs filed), but now that I
started this, I believe adding the openssl exception won't hurt, so we
should pull it through.

Am I making sense?

—
Reply to this email directly or view it on GitHub
#104 (comment).

[spaetz]

Oops, my apologies, I might have caught the wrong person then (I do mean a Steve Hanson which used to work at Redhat).

[spaetz]

Oops, my apologies, I might have caught the wrong person then (I do mean a Steve Hanson which used to work at Redhat).

[tohojo]

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

Right, I'll go ask on the Debian list.

3. Even using python-licensed abstractions inbetween, I do believe
   there is some leeway to argue that offlineimap needs to adhere to the
   openssl terms (e.g. the advertising clause), making it inherently
   incompatible with python-based end user applications under the GNU
   GPL. Is this a problem that would apply to all python-based apps using
   openssl? Yes...,. I'd rather be better safe than sorry here.

I'm just really puzzled by the fact that using a feature of a language
runtime can affect the licensing of the project. I mean, offlineimap
could presumably run on a different python interpreter (let's call it
$XPYTHON) which implemented it's ssl module using a different SSL
library and this wouldn't be an issue?

I can see how the Python interpreter itself needs this clause (as indeed
it has). Of course it may be that I'm just being hopelessly naive. In
which case I'd like someone to point me to a good explanation somewhere :)

If you can't write a GPL-licensed application in Python without
requiring a license exception, I'd consider that a bug (in Python, I
suppose)...

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough,
   we need to be quick.

Sure, I can recognise the pressure, and as I said I'm not opposed as
such; I just want to use this opportunity to understand the issue a bit
better...

-Toke

[tohojo]

2. There is a debian bug filed against offlineimap detailing specifics.
   If you believe you are right, I would think, we should argue there.

Right, I'll go ask on the Debian list.

3. Even using python-licensed abstractions inbetween, I do believe
   there is some leeway to argue that offlineimap needs to adhere to the
   openssl terms (e.g. the advertising clause), making it inherently
   incompatible with python-based end user applications under the GNU
   GPL. Is this a problem that would apply to all python-based apps using
   openssl? Yes...,. I'd rather be better safe than sorry here.

I'm just really puzzled by the fact that using a feature of a language
runtime can affect the licensing of the project. I mean, offlineimap
could presumably run on a different python interpreter (let's call it
$XPYTHON) which implemented it's ssl module using a different SSL
library and this wouldn't be an issue?

I can see how the Python interpreter itself needs this clause (as indeed
it has). Of course it may be that I'm just being hopelessly naive. In
which case I'd like someone to point me to a good explanation somewhere :)

If you can't write a GPL-licensed application in Python without
requiring a license exception, I'd consider that a bug (in Python, I
suppose)...

4. I have only started this initiative when people stated that
   offlineimap would be potentially withdrawn from debian and the freeze
   for the coming release is in November, so in case debian plays tough,
   we need to be quick.

Sure, I can recognise the pressure, and as I said I'm not opposed as
such; I just want to use this opportunity to understand the issue a bit
better...

-Toke

[tohojo]

Sebastian Spaeth notifications@github.com writes:

Another discussion on the python list dscussing the legalities of GNU
GPL code:
https://mail.python.org/pipermail/python-dev/2011-March/109032.html
(see other mails in this thread). With differing opinions.

Hmm, this thread was a somewhat illuminating read. Still not sure I'm
entirely convinced that 'import ssl' automatically requires a python
program to abide by the openssl license, but if Debian is going to be
pedantic I don't suppose there's any harm in adding the exception...

Thanks for the links and patience :)

-Toke

[tohojo]

Sebastian Spaeth notifications@github.com writes:

Another discussion on the python list dscussing the legalities of GNU
GPL code:
https://mail.python.org/pipermail/python-dev/2011-March/109032.html
(see other mails in this thread). With differing opinions.

Hmm, this thread was a somewhat illuminating read. Still not sure I'm
entirely convinced that 'import ssl' automatically requires a python
program to abide by the openssl license, but if Debian is going to be
pedantic I don't suppose there's any harm in adding the exception...

Thanks for the links and patience :)

-Toke

[chris001]

Instead of getting digital signatures from all contributors, there's a way to slightly modify our code to satisfy this strict debian requirement of no linking to copyrighted code without an openssl exception.

Move the few functions that use openssl directly (via "import ssl"), into imaplib2.py (imaplib2 library by piers morgan, it already has an openssl exception) - the functions would obviously need to have any dependencies on offlineimap removed, and we would need to fork and do pull requests to piers can pull these added functions into imaplib2.py

The only places where offlineimap links to openssl:

1. offlineimap/imaplibutil.py:
   import ssl
   (My IDE says it's unused.)
2. offlineimap/imapserver.py:
   from ssl import SSLError, cert_time_to_seconds

Taking a closer look at these.

1. SSLError is used one time to handle the case of "unknown protocol" for example when connecting via SSL to non-SSL service.
   The fix: change imaplib2.py to return its own "secure connection exception" object, instead of an instance of SSLError which belongs to openssl.
2. cert_time_to_seconds is used one time by __verifycert() to compute if the SSL certificate of the mail server is expired.
   So, to move __verifycert() into imaplib2.py, and just call it from our code. It'd be useful for other projects, that link to imaplib2, and help them avoid needing an openssl exception, just to check whether the SSL cert of the imap server is expired/revoked.

Which way is preferred? Get signatures and add an exception in the license, or modify a small part of the code?

[chris001]

Instead of getting digital signatures from all contributors, there's a way to slightly modify our code to satisfy this strict debian requirement of no linking to copyrighted code without an openssl exception.

Move the few functions that use openssl directly (via "import ssl"), into imaplib2.py (imaplib2 library by piers morgan, it already has an openssl exception) - the functions would obviously need to have any dependencies on offlineimap removed, and we would need to fork and do pull requests to piers can pull these added functions into imaplib2.py

The only places where offlineimap links to openssl:

1. offlineimap/imaplibutil.py:
   import ssl
   (My IDE says it's unused.)
2. offlineimap/imapserver.py:
   from ssl import SSLError, cert_time_to_seconds

Taking a closer look at these.

1. SSLError is used one time to handle the case of "unknown protocol" for example when connecting via SSL to non-SSL service.
   The fix: change imaplib2.py to return its own "secure connection exception" object, instead of an instance of SSLError which belongs to openssl.
2. cert_time_to_seconds is used one time by __verifycert() to compute if the SSL certificate of the mail server is expired.
   So, to move __verifycert() into imaplib2.py, and just call it from our code. It'd be useful for other projects, that link to imaplib2, and help them avoid needing an openssl exception, just to check whether the SSL cert of the imap server is expired/revoked.

Which way is preferred? Get signatures and add an exception in the license, or modify a small part of the code?

[xnox]

Moving OpenSSL functionality into imaplib2 does not help, we'd still need exception in our code to use impalib2. Or e.g. give up verification of SSL certificates. I viable option is to add python-gnutls support to imaplib2 and allow that to use either OpenSSL or GnuTLS. And then in Debian, offlineimap can be packaged to use GnuTLS only. The logic used in debian is that python interpret is a compiled binary that does dlopen on the shared library _ssl.so which is linked against OpenSSL. And the trigger to do that dlopen is relied upon by our project (offlineimap) irrespective whether it's "import ssl" in our py-files or in the imaplib2.py or elsewhere in our dependencies.

[xnox]

Moving OpenSSL functionality into imaplib2 does not help, we'd still need exception in our code to use impalib2. Or e.g. give up verification of SSL certificates. I viable option is to add python-gnutls support to imaplib2 and allow that to use either OpenSSL or GnuTLS. And then in Debian, offlineimap can be packaged to use GnuTLS only. The logic used in debian is that python interpret is a compiled binary that does dlopen on the shared library _ssl.so which is linked against OpenSSL. And the trigger to do that dlopen is relied upon by our project (offlineimap) irrespective whether it's "import ssl" in our py-files or in the imaplib2.py or elsewhere in our dependencies.

[chris001]

How easily could we provide versions of imaplib2.py and other py-files, which currently use python-openssl, that could be switched to use python-gnutls with a packaging option...?

[chris001]

How easily could we provide versions of imaplib2.py and other py-files, which currently use python-openssl, that could be switched to use python-gnutls with a packaging option...?

[xnox]

I've looked at it briefly, and the API is different. I didn't have time to
validate how easily it is to port to gnutls and work with it at runtime.
However, I just went through non-trivial SSL debugging, which ended up
tracing down that older gnutls versions (2.12.x as using in Ubuntu 14.04
LTS and elsewhere) reject out of order certificate chains, which was a pain
to track down.

On 25 September 2014 01:11, Chris Coleman notifications@github.com wrote:

How easily could we provide versions of imaplib2.py and other py-files,
which currently use python-openssl, that could be switched to use
python-gnutls with a packaging option...?

—
Reply to this email directly or view it on GitHub
#104 (comment)
.

Regards,

Dimitri.

[xnox]

I've looked at it briefly, and the API is different. I didn't have time to
validate how easily it is to port to gnutls and work with it at runtime.
However, I just went through non-trivial SSL debugging, which ended up
tracing down that older gnutls versions (2.12.x as using in Ubuntu 14.04
LTS and elsewhere) reject out of order certificate chains, which was a pain
to track down.

On 25 September 2014 01:11, Chris Coleman notifications@github.com wrote:

How easily could we provide versions of imaplib2.py and other py-files,
which currently use python-openssl, that could be switched to use
python-gnutls with a packaging option...?

—
Reply to this email directly or view it on GitHub
#104 (comment)
.

Regards,

Dimitri.

[spaetz]

1. I have been sick a few days and will update the openssl exception page this evening. I guess we might have enough consent to merge the openssl exception. This is the super safe and conservative action, and it will make at least Debian happy, so this is my preferred option. If someone wants to argue with(in) Debian for our case, all the better.

2. @chris001: Even if we push all OpenSSL related things into imaplib2.py that doesn't change a thing. a) We bundle the imaplib2.py library in our source code package, so it needs to adhere to our GPL license for sure. b) The problem is not ours (we can legally offer offlineimap via download or Pypi) but for Linux distributions which do not consider OpenSSL to by a base system library (and thus being excempt). Pushing all of OpenSSL into imaplib2 does not change the situation for Debian in the slightest. I would suggest, we add the OpenSSl exception and move on with more productive things that we can do.

[spaetz]

1. I have been sick a few days and will update the openssl exception page this evening. I guess we might have enough consent to merge the openssl exception. This is the super safe and conservative action, and it will make at least Debian happy, so this is my preferred option. If someone wants to argue with(in) Debian for our case, all the better.

2. @chris001: Even if we push all OpenSSL related things into imaplib2.py that doesn't change a thing. a) We bundle the imaplib2.py library in our source code package, so it needs to adhere to our GPL license for sure. b) The problem is not ours (we can legally offer offlineimap via download or Pypi) but for Linux distributions which do not consider OpenSSL to by a base system library (and thus being excempt). Pushing all of OpenSSL into imaplib2 does not change the situation for Debian in the slightest. I would suggest, we add the OpenSSl exception and move on with more productive things that we can do.

[nicolas33]

Unless I'm confused, this one is done. :-)

[nicolas33]

Unless I'm confused, this one is done. :-)