PGP is a bunch of use cases glommed together; for most/all of them there is a better tool https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
Here's a good quote from the article at the top of this chain:
> Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which is not great. Every well-known bad cryptosystem eventually sprouts an RFC extension that supports curves or AEAD, so that its proponents can claim on message boards that they support modern cryptography. RFC’s don’t matter: only the installed base does. We’ve understood authenticated encryption for 2 decades, and PGP is old enough to buy me drinks; enough excuses.
> You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both.
HTTP, javascript and TLS have also shown that a sufficiently motivated set of actors can move the ecosystem forward. True, organizing the ecosystem is not the same job as actually building stuff, but it's still beneficial to all of us.
Absolutely. PGP could be decent. Unfortunately efail and sks[1] show it's actors aren't sufficiently motivated.
[1] https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54...
As a developer, you have a choice to make when you encounter GPL bashing: jump on the bandwagon, or rebut. If you choose the bandwagon, don't come crying when you can't make a living building honest software that treats users with respect because you have to compete with large companies who ~~take~~ steal agnostic software and subsidize their products with user disrespect and line their pockets selling ad profiles.
As a user, demand honest software and new companies will rise to meet your demands. Instead of ads, pay $30 and support a project that puts your interests first. Subscribe for $3/mo when you find a product that brings you continuous value.
As a technical leader and someone in a position to make impactful technical decisions at your small company, educate yourself on the license landscape, examine your core product and target market. If you're targeting open source adoption by big companies and expect them to eventually pay for a proprietary overlay, probably avoid the GPL. If you're building a product for _users_, consider enshrining that position in your license terms and simultaneously defending their freedom while deterring predatory abuse by large companies.
It runs contrary to the FSF guidance, but I'd also suggest, out of practicality, patenting your (software) inventions. Ultimately it gives you flexibility and defense in the event that somebody else tries to assert their own patents. It also protects your GPL users because you explicitly license them to use your patented work, and it allows you to license that technology regardless of any software you've written to companies who may not find the GPL palatable but still would like to use your invention. Win win win.