Recently this has been my thought... that my future projects should be AGPL from day one.
To the existing ones, especially the successful one... if it does get too much for me, I shall relicense.
Recently this has been my thought... that my future projects should be AGPL from day one.
To the existing ones, especially the successful one... if it does get too much for me, I shall relicense.
> Recently this has been my thought... that my future projects should be AGPL from day one.
If that means that companies can't use it, because that would mean, if they use it they would be required to open-source their managed SaaS solution ... that's a feature?
It prevents corps running their own version without sharing those changes back, and it forces corps to think carefully about whether they are willing to invest (their time and effort) in the OSS projects that they consume.
I doubt it would mean that they have to OSS their SaaS offerings. Most likely things are all implemented as little services and the boundary of what they'd have to OSS at most is one of those. More it forces them to be a better and more mindful consumer of OSS.
Some developers at $BIGCORP may think they’d be fine using an AGPL library/utility in one spot, but legal gets nervous, so they recommend management shut it down to avoid lawsuits.
https://www.theregister.com/2017/05/13/gnu_gpl_enforceable_c...
BTW, the AGPL network clause triggers on modification, not on distribution (which the AGPL has the same provisions for as the GPL) or public performance or something else.
If something is a derivative work for the purposes of the AGPL, then it's also a derivative work for the purposes of the GPL, or any other copyright license.