6 ms·
What's the risk for businesses in a dual-license situation? The public can use the AGPL, or the business can get a private license with no viral stipulations at
by oddevan 2y ago
What's the risk for businesses in a dual-license situation? The public can use the AGPL, or the business can get a private license with no viral stipulations at all. Is it just the FUD around a GPL-like license?
(Serious question, as this is the business model I'm pursuing.)
- nickpsecurity 2y agoPart of the problem is: “what can I do with the commercial source?” The open-source code lets you modify and distribute. There’s either no risk (permissive) or well-understood. Proprietary licenses often don’t allow freedoms like that. So, some of the new licenses are addressing modification and redistribution of source-available, proprietary code. Far as AGPL, it’s very unpopular even among FOSS users. Just using it almost guarantees less adoption of your code. Whether that’s fair or not, I’m just saying it’s a reality that you might be limiting the impact of FOSS code if it’s AGPL.
- meiraleal 2y ago> Far as AGPL, it’s very unpopular even among FOSS users Citation, please. I would say this is very untrue but would like to see the sources of this claim. I hope you are not calling Big tech employees "FOSS users".
- nickpsecurity 2y agoOnly thing I could find very quickly was a GitHub analysis of license use: https://github.blog/open-source/open-source-license-usage-on-github-com/ https://github.blog/open-source/open-source-license-usage-on... AGPL-licensed projects are almost non-existent compared to many others.
- meiraleal 2y agoSo you are talking bullocks as I suspected. Thanks. What I see is the opposite, actually: FOSS users (aka free software developers) prefer the GPL family of licenses and the ones that know and understand AGPL also prefer it.
- SpicyLemonZest 2y agoI wouldn't really say there's a risk. It's just inferior to an open core model in most cases. The private license deters independent contributions, the AGPL license prevents small businesses who can't yet afford your system from using it, and large corporations don't care at all that your full source code is publicly available.
- ezekg 2y agoI would argue that fair core is, in a lot of cases (not all ofc), superior in the long run to open core, because under fair core, the entire code base eventually becomes open source, unlike open core where commercial features remain proprietary/closed indefinitely. There are pros and cons of both that need to be weighed ofc, but I personally really like fair core. (Disclaimer: I contributed to the FCL: https://fcl.dev https://fcl.dev)
- SpicyLemonZest 2y agoI like the idea in principle after reading through it - it lines up with a lot of conventional wisdom about how fast software becomes commoditized. But there's a lot of practical aspects of commercial development that I'm not sure really work when your commits go out to the public. How would an FCL codebase, for example: * Merge a bad change which makes the project worse, because it'll unblock a contract that stands to make your company a lot of money. * Iterate on support for a proprietary workload from one of your customers, who has not licensed that workload publicly and indeed may consider it a trade secret.
- wmf 2y ago1. Just do it and don't apologize to freeloaders. 2. Don't name customers in commits.
- deleted 2y ago[deleted]
- davidgerard 2y ago> AGPL license prevents small businesses who can't yet afford your system from using it what? This sentence appears to be literally untrue. In what way?
- max-privatevoid 2y agoI think the idea that businesses can't use GPL- or AGPL-licensed code is absolutely ridiculous. This false premise seems to be omnipresent in every license discussion.
- Zambyte 2y agoI think this is where that premise originated: https://opensource.google/documentation/reference/using/agpl-policy https://opensource.google/documentation/reference/using/agpl... While businesses can obviously use AGPL licensed software, some (like Google) explicitly choose not to.