Curious as to why GNU and not something else, such as BSD?
This page makes a pretty compelling case for just picking Plain Old GPL:
- GPL-incompatible licenses risk lack of support (GPL most popular)
- Other projects show GPL compatibility important
- GPL is very well understood legally by now
Remember virtually every other forum software either costs money (is not 100% open source) or sucks, or both.
Mostly, I’d say we are doing GPL because:
WordPress is our spirit guide, and they do it. Our elevator pitch is basically that we aim to be the WordPress of forums. Do you see WordPress failing or not getting adoption because of GPL? I don’t. Quite the opposite.
We do want to incentivize people to contribute back to make it better. We give fantastic forum software to you for free, and in return, you contribute any cool stuff you did with it back to the project so it gets better and raises the level of Civilized Discourse on the Internet for everyone. Quid pro quo, Clarice. Quid pro quo.
We need to retain an original license to any contributed code via a CLA so we can sell “enterprisey” versions. In addition to hosting one-click forum instances here at discourse.org for $49 - $199 a month, we also plan to sell the software to big companies for big bucks. That’s how we hope to pay our salaries in 2 years’ time.
What specific problem does choosing GPL cause, other than “personally, I prefer a different license?” Tons of GPL software out there doing great – WordPress and to some extent Drupal are close relations of ours, and both are GPL. It’s a very well understood and extremely popular license. Can you point to any other vaguely-related-to-forums GPL software that were harmed as a result of choosing GPL?
Why would Discourse's business model work when Stack Exchange v1's failed?
Thanks for the thorough response. I personally have no opposition to GPL, or preference for BSD, or anything like that. Simply curious as to the reasons that made the choice for you in the end.
Are there any license rules about the name “Discourse”? Can my derived product be called “Discourse” or “Discourse XYZ”? How about the logo/artwork?
As someone who has toiled in a startup producing an open source application, I can attest that the GPL is often an attractive choice in this situation.
Specifically w.r.t. point (3) Jeff posted above. There’s a definite feeling that using a “free-er” licence (BSD / MIT / X / Apache / …) might leave you exposed to the risk of a competitor picking up your code and recommercialising it. Whether it’s true that the GPL provides better protection against this (or that the others provide less) I can’t really say, but it’s definitely the case that the bean counters sleep better if you use the GPL.
However, I don’t know if I’d list GPL compatibility as an advantage of the GPL; that’s a bit topsy-turvy. GPL compatibility is only an issue because the GPL is so very complicated and hence such a bastard to be compatible with in the first place.
[quote=“codinghorror, post:2, topic:2531”] 2. We do want to incentivize people to contribute back to make it
better. We give fantastic forum software to you for free, and in
return, you contribute any cool stuff you did with it back to the
project so it gets better and raises the level of Civilized
Discourse on the Internet for everyone. Quid pro quo, Clarice. Quid
Does this mean we won’t be able to modify Discourse for our own needs and that any modifications we do make must always be contributed back?
I’m pretty sure that’s not the case but just want to check.
@AstonJ: I’m pretty sure that would only be the case if it was AGPL-licensed.
Typically no unless they specifically allow it. There is still a copyright on the name and logo, it might be under the same Creative Commons license as the rest of their website but I would assume not unless you are told otherwise by a dev.
Many open source projects will require that you use your own name, logo, and other branding in order to differentiate your derived work as it would not actually be quite the same as Discourse and you’ll trick people into thinking it is even if that’s not your intent.
I think the GPL seriously discourages outside contribution. Just look at most GNU projects today. Most new open source projects are permissively licensed, said one analysis. That said, I personally wouldn’t mind abiding by its rules if I wanted to develop my own version (which won’t be happening anytime soon, hehe).
Anyway, I don’t think the license choice matters much, as long as it is FSF and OSI-approved, as well as GPL-compatible to be able to use GPL’d libraries and frameworks (Ember.js, for instance, is GPL’d).
The best license is WTF Public License, or WTFPL. It has no copy-left features so it’s the freest license.
Btw. the code/software does not necessarily have to stay under GPL forever. All contributors have to sign the CLA which basically makes Discourse the owner of the code. So if they ever decide to change the license or have it dual-licensed, they can.
But there are really no direct reasons to be against GPL in this software. GPL brings some trouble with statically linked libraries, publishing to proprietary App Store, etc., but not here. You can embed the forum into your website without having to publish the code for it.
And why not AGPL instead of GPL? It seems better suited for website softwares.
This isn’t true for software that runs on a server, right? The GPL only forces you to give the source to users who are actually running your software. So I guess Discourse being GPL might force people running publicly-accessible modified instances to give back contributions to the JS code at best (it runs on the user’s machine), but not the server code. That would require AGPL. Is the JS part the original reasoning behind choosing GPL? Because otherwise it’s basically the same as choosing an MIT license.
How is Discourse going to make money?
Ouch. Yikes. Eww. If WordPress is your poster child for GPL you hadn’t seen that much into its community and business ecosystem.
web CMS plus third party plugins/themes is anything but clear legally. Swamp of opinions with zilch remotely relevant legal precedents. WP have been on the brink of suing businesses over related issues for years.
GPL comes with “spirit” baggage, which in WordPress resulted in aggressive lobby for extra-GPL restrictions to satisfy “spirit” rather than “letter” of license.
GPL is headache for making use of open source components, namely GPLv2 incompatibility to Apache License 2.0 and general incompatibility with Creative Commons licenses.
all of the above results in never ending WP holy war which explodes with fresh scandal about once a year.
I sincerely hope that GPL works out for your project and its community extremely differently from how it worked out for WordPress. At least you have CLA failsafe.
Not quite (if I understand correctly). Choosing AGPL would prevent people from hosting modified Discourse instances without releasing the code; choosing GPL would prevent people from distributing modified Discourse instances without releasing the code.
This way, anyone can run their own Discourse install, even for profit, but they can’t sell black box solutions to businesses that need the software hosted on their servers.
If I’m misinformed about any of this, I’d appreciate being corrected.
That’s true. You could sell a solution for companies to host on their own servers, but you would have to provide them with the code.
But that only stops would-be Discourse resellers, not its enterprise use.
AGPL is indeed there to close the ASP loophole, trouble with AGPL is mainly sociological. People are very very allergic to it. GPLv2 on the other hand is much more commonplace so we preferred it even though we are at some risk.
I also do
One thing to keep in mind is that our attitude is somewhat different to hard core GPL fanatics. We are completely open to extracting common MIT bits out of the Discourse code base for the greater good, stuff like the message bus, oneboxing, rails multi site, markdown pipeline and so on.
In researching a bit on Wordpress and GPL, there seems to be one major controversy over the Thesis theme, with no legal jurisprudence to clarify the situation.
The Wordpress team’s position is that any theme that you can make for Wordpress is a derivative work of Wordpress itself, and therefore subject to the GPL’s restrictions and must be GPL licensed itself.
One of the major theme maker’s argument is that a theme wholly created by them (meaning no copied lines from Wordpress code) is their own work and merely interacts with Wordpress, and is not a derivative work of Wordpress itself.
Having read some of the back and forth, this really seems to be a gray area where reasonable people can disagree. That’s one of the reasons I personally avoid the GPL (I use Apache 2.0), but then again, I’m not saying that’s the right thing for anyone else, especially since I don’t run a business off my OSS.
I don’t envy you guys for having to had to make and justify the call for which license you want to use. Following in the footsteps of another project as a spirit guide might smack a bit of abdication, I hope that’s not the case.
Questions like this might be a good opportunity to make use contacts your board’s network brings you. There’s no substitute for firsthand entrepreneurial experience.
Yes, they’ll run into the same theme conflicts, but I believe discourse the company is going to treat themes as separate, and plugins as derivative. So you can’t develop a plugin that isn’t GPL, but you could make themes, as long as they don’t modify th operation of the forums underlying mechanism, ie a plugin.
There’s going to be a lot of back and forth about what is and isn’t under the GPL.
Still, there’s a case to be made that if the API is well documented, and no code was derived from discourse, then an independently developed, but inter-operating plugin could be distributed under a different license. The end user would be responsible for combining the two, and using them, and as long as they didn’t distribute the resulting combination, they’d still be in compliance with both the GPL discourse, and the proprietary licensed plugin. One could probably come up with a legally binding license for the plugin that would prevent further distribution, and thus tie the hands of the person that integrates it with their own copy of discourse.
It’s all very hand wavy, but certainly an interesting exercise in software licensing schemes.