3 ms·

The reasoning also does not make sense at all to me. Making secure email popular is hard enough without restrictive licensing. At this point almost no-one cares

The reasoning also does not make sense at all to me. Making secure email popular is hard enough without restrictive licensing. At this point almost no-one cares about this problem and even fewer about this solution. I donated money to the project and considering the goal behind the project is to make e-mail secure, allowing liberal reuse of components in commercial projects seems very desirable as a way to spread the concept. However, they just made this impossible by choosing AGPLv3.

wtallis 11y ago
Which of the license restrictions actually poses a challenge to anyone who is trying to further the goals of the mailpile project? The emphasis on security and not trusting the server or service providers already precludes integrating it into a closed-source product.
- asabjorn 11y ago
  It hinders growth paths and stops reuse that would lower the bar for spreading secure e-mail support. AGPLv3 has license restrictions that are unacceptable to many or maybe even most companies, and secure company e-mail would be a great first growth application. Even for personal use easy 3rd-party deployment by hosting providers would be desirable, but AGPLv3 may be of concerns for these hosts for a fringe-application. AGPLv3 also prohibits code-reuse in most contexts, so it makes surprising reuse of sub-components less likely. Stopping this reuse is a shame since it could have reduced the bar for implementing secure email support in more e-mail clients.
  - zanny 11y ago
    In email clients with either more permissive or even proprietary licenses, where those Mailpile most wants not to use their source (evesdropper backend email services like gmail) can then use their work to enhance their user experience without providing their users the software freedoms they enjoyed when modifying mailpile or a permissive fork of a permissive piece of it.
    - Sanddancer 11y ago
      Who needs an evesdropper backend when you can just watch the network traffic? The messages back and forth are just data, and an MITM proxy is invisible. The end result being that the company has a face of providing privacy, but knows every little thing about you.

wtallis 11y ago

Which of the license restrictions actually poses a challenge to anyone who is trying to further the goals of the mailpile project? The emphasis on security and not trusting the server or service providers already precludes integrating it into a closed-source product.

asabjorn 11y ago
It hinders growth paths and stops reuse that would lower the bar for spreading secure e-mail support. AGPLv3 has license restrictions that are unacceptable to many or maybe even most companies, and secure company e-mail would be a great first growth application. Even for personal use easy 3rd-party deployment by hosting providers would be desirable, but AGPLv3 may be of concerns for these hosts for a fringe-application. AGPLv3 also prohibits code-reuse in most contexts, so it makes surprising reuse of sub-components less likely. Stopping this reuse is a shame since it could have reduced the bar for implementing secure email support in more e-mail clients.
- zanny 11y ago
  In email clients with either more permissive or even proprietary licenses, where those Mailpile most wants not to use their source (evesdropper backend email services like gmail) can then use their work to enhance their user experience without providing their users the software freedoms they enjoyed when modifying mailpile or a permissive fork of a permissive piece of it.
  - Sanddancer 11y ago
    Who needs an evesdropper backend when you can just watch the network traffic? The messages back and forth are just data, and an MITM proxy is invisible. The end result being that the company has a face of providing privacy, but knows every little thing about you.