It's not a stupid question, but often times open sourcing something involves one or more of the following:

1. Documenting everything so it's actually usable. At a minimum, "here is how to install the dumb thing" should probably be documented.

2. Often times there are hard-coded values that would need to be extracted out for security reasons or to simply allow someone to install it on a system not quite like yours.

3. Often times there are other dependences that would also have to be open sources such as modifications to libraries, internal libraries released, shell scrips, cron jobs, messaging queues, delayed job worker tasks, etc that the system may rely on. These all need to be packaged up, documented and/or released.

In short it is a ton of work to take something that is running in our way on our hardware and generalize it enough that anyone else can run it.

On the other hand, you wouldn't need their service to give you the protections they offered. Essentially, encrypted email storage. You can get that mostly off the shelf using any linux distro if you run your own mail service.

He probably wants to see how the case works out in court first. if all else fails, and he cannot reopen his business, he could do that as a big FU.

They have already described the significant part:

http://wayback.archive.org/web/20130530023856/http://lavabit...

As far as I can tell it is a service that suffers from many of the same things as other services, especially concerning email that is sent to a recipient in clear text:

  1) The email can be intercepted in clear text
  2) If the service is compromised; a plain text copy can be made
  3) If the service is compromised; a copy of the session key can be stored
  4) If the service is compromised; a predictable/insecure session key can be used
  5) They store a copy of the secret key; if the service is compromised - all session keys can be recovered when the user logs in (provides the password).

I've thought about engineering a similar system; but one based around GPG -- have users upload/associate a public key with their account, and if they receive unencrypted email encrypt it to them using their public key. 1,2,3 and 4) remain though -- and 4) may be the worst as it is almost impossible to detect/defend against AFAIK.

An alternative would be to set up a service that detects whether or not incoming mail is encrypted, and rejects it if it is not (along with information of where/how to install and set up GPG).

As others have mentioned this would not help with the who talks to who meta-data problem.