Consider switching to AGPL-3.0 for true open source licensing

[jjhaggar]

Hi Bruno, and thank you for developing and sharing 3D Gen Studio! ^_^

I noticed that 3D Gen Studio is currently released under a custom Community License. I think I understand the intent: keeping the project usable by the community while preventing someone from taking the app, closing it, and offering it as a commercial hosted service or bundle without contributing back.

The downside is that the current license makes the project source-available rather than open source. That can reduce trust, adoption, packaging, contributions, and integrations from developers who specifically look for OSI-approved licenses.

I think AGPL-3.0 (or later) could be a good fit here. It would make 3D Gen Studio genuinely open source, while still protecting the project against the main risk: if someone modifies it and offers it over a network, they must provide the corresponding source code to users of that service.

That seems well aligned with this project, since 3D Gen Studio is a web-based production tool that could realistically be hosted as a service.

A possible model would be:

• Community edition: AGPL-3.0-or-later
• Commercial license: available for companies that want to embed or offer proprietary hosted versions

This would give the project stronger open source credibility without giving up a path to monetization.

That's just my two cents, though. And again, thank you for your work! :)

[visualbruno]

Thanks for the thoughtful feedback — you've described the intent of the project well, and your point about source-available licenses reducing trust and adoption is fair and something I've taken seriously.

After thinking it through, though, AGPL-3.0 isn't the right fit here. The reason is that my core intent is for the software itself to never be sold — anyone can use it for free, run it on their own infrastructure, and freely monetize whatever they generate with it, but I don't want someone repackaging or hosting the app as a paid product. That restriction is fundamentally incompatible with any OSI-approved license, since the freedom to sell the software is a defining requirement of open source. So no open license (AGPL included) would actually preserve the one protection the project's license exists to provide.

What I'm very open to is your underlying concern: a custom license creates uncertainty. So rather than an OSI license, I'm considering moving from my homemade license to a standardized, well-drafted source-available one (e.g. Apache 2.0 + Commons Clause, or a PolyForm license) that keeps the "not for resale" intent but is a known, vetted quantity that's easier for developers to reason about.

That won't satisfy everyone who filters strictly for OSI-approved licenses, and I understand if that's a dealbreaker for some — but it's a deliberate trade-off given the goals of the project. Appreciate you raising it; happy to keep discussing if you have thoughts on which standardized source-available license would be cleanest.

[jjhaggar]

Thanks for the detailed reply!

Given that "no resale / no paid hosted version of the app itself" is a hard requirement for the project, I agree that AGPL would not preserve that. In that case, I think the important thing is exactly what you said: being explicit that the project is source-available rather than open source.

Regarding standardized licenses, Apache 2.0 + Commons Clause seems closer to your intent than a broad non-commercial license, because you clearly want to allow internal commercial use of the tool and commercial monetization of generated outputs, while restricting resale/repackaging/paid hosting of the app itself.

I would just be careful to present it clearly as source-available, not as Apache/open source, since Commons Clause changes the nature of the resulting license.

I’m not a licensing expert, but I do think using a standardized source-available license would make the project easier to understand and evaluate than a custom one.

Thanks again for taking the concern seriously :)