It's definitely a case of people not reading, but honestly: who does read the full terms of a license? Most people just don't know which have requirements to a

It's definitely a case of people not reading, but honestly: who does read the full terms of a license? Most people just don't know which have requirements to attribute the work or redistribute license files or which provide the company they work for with certain advantages/disadvantages. They just "heard about" MIT or Apache 2 or whatever are safe to use and there are some license types that are unsafe to use. I've led several product management teams in my career and many engineers, executives, and customers I've talked to have this impression that if they put some bit of software under AGPL, then its nature is such that it's super viral: that potentially the entire product would necessitate becoming AGPL if the AGPL code is used in any fashion in the product. This has been primarily perpetuated from Google's statement on it: https://opensource.google/documentation/reference/using/agpl-policy https://opensource.google/documentation/reference/using/agpl... and engineers that now there's a lot of lore around AGPL generally causing so much fear in any of big-tech company potentially needing to open source their entire service that it's treated as "companies wouldn't dare include our AGPL software in a competitive offering because then they'd have to open source their entire hosting stack, and nobody is going to be willing to do that." My understanding that I heard through the grapevine is that this fear was what MongoDB was relying on for so many years and they found out that one of the big tech companies was about to offer a competitive MongoDB-as-a-service, which caused them to make their shift away from AGPL. Other (mostly database) OSS vendors caught wind of it as well through their networks, and that's why various OSS database products didn't go to AGPL but instead to proprietary licenses.