3 ms·

Why? My understanding of AGPL is that you only need to publish changes if you modify the project and open it up to the internet. A company could self host sr.ht

Why? My understanding of AGPL is that you only need to publish changes if you modify the project and open it up to the internet. A company could self host sr.ht internally, and they wouldn't have to open source anything. A company could also take sr.ht, provide it as a service, and charge for maintenance. AGPL would stop a company from taking sr.ht, changing it, hosting it as a service, and refusing to publish the changes. That's my understanding of the license anyway.

oneplane 8y ago
That is indeed what it does, and as such also bans partial contribution. Most of the models I've seen where time and money is spent on FOSS contributions are the kind where not all changes are upstreamed because they are kept internal or secret. Say for example GitLab was AGPL, their model of having a Community Edition and an Enterprise Edition would no longer be possible, because the EE directly links to and consumes software from the CE code. Having a EE and CE version of a product is one of the few remaining models that still enable fruitful enterprise and FOSS combinations. The support-only or maintenance-only models are very rarely successful. The former isn't possible with the AGPL and the latter is, but is simply bound to so much risk and so few successes that it's basically bleeding to death or an existing enterprise, with nothing in between.
- helen___keller 8y ago
  Right, and to add on that this is really the perfect case for AGPL in that the company isn't a rocket-ship trajectory startup or anything, it's a single developer who maintains it as a side project and aims to bootstrap & operate at a profit (I think he recently transitioned to working on FOSS full-time so technically not a side project anymore). In other words, the risk is closer to the risk of a side project failing than the risk of a giant corporation failing, and the need for flexibility to pivot to different funding models is lower or nonexistent. There's no venture capitalists to appease. Presumably, if the founder decided he could only profitably run sr.ht by turning it into "open core" like gitlab or proprietary like github, he would have simply given up the project.
  - oneplane 8y ago
    While in it's current incarnation it might indeed be a good case, I wonder why it must also exclude all future options right at the start. I don't think AGPL is inherently bad, but for projects of this kind it seems a bit future-limiting.
- chriswarbo 8y ago
  > Having a EE and CE version of a product is one of the few remaining models that still enable fruitful enterprise and FOSS combinations. The support-only or maintenance-only models are very rarely successful. There's also the dual-licensing model, where non-free licenses can be purchased which allow things that the FOSS license doesn't, like non/partial-contribution. AGPL seems even better suited to this than GPL, precisely because many companies would rather purchase such a license than expose the custom elements of their network services. IIRC that's precisely why Affero came up with this license for their software (in collaboration with the FSF, to ensure GPL compatability).

oneplane 8y ago

That is indeed what it does, and as such also bans partial contribution. Most of the models I've seen where time and money is spent on FOSS contributions are the kind where not all changes are upstreamed because they are kept internal or secret. Say for example GitLab was AGPL, their model of having a Community Edition and an Enterprise Edition would no longer be possible, because the EE directly links to and consumes software from the CE code. Having a EE and CE version of a product is one of the few remaining models that still enable fruitful enterprise and FOSS combinations. The support-only or maintenance-only models are very rarely successful. The former isn't possible with the AGPL and the latter is, but is simply bound to so much risk and so few successes that it's basically bleeding to death or an existing enterprise, with nothing in between.

helen___keller 8y ago
Right, and to add on that this is really the perfect case for AGPL in that the company isn't a rocket-ship trajectory startup or anything, it's a single developer who maintains it as a side project and aims to bootstrap & operate at a profit (I think he recently transitioned to working on FOSS full-time so technically not a side project anymore). In other words, the risk is closer to the risk of a side project failing than the risk of a giant corporation failing, and the need for flexibility to pivot to different funding models is lower or nonexistent. There's no venture capitalists to appease. Presumably, if the founder decided he could only profitably run sr.ht by turning it into "open core" like gitlab or proprietary like github, he would have simply given up the project.
- oneplane 8y ago
  While in it's current incarnation it might indeed be a good case, I wonder why it must also exclude all future options right at the start. I don't think AGPL is inherently bad, but for projects of this kind it seems a bit future-limiting.
chriswarbo 8y ago
> Having a EE and CE version of a product is one of the few remaining models that still enable fruitful enterprise and FOSS combinations. The support-only or maintenance-only models are very rarely successful. There's also the dual-licensing model, where non-free licenses can be purchased which allow things that the FOSS license doesn't, like non/partial-contribution. AGPL seems even better suited to this than GPL, precisely because many companies would rather purchase such a license than expose the custom elements of their network services. IIRC that's precisely why Affero came up with this license for their software (in collaboration with the FSF, to ensure GPL compatability).