I thought’d I might contribute a perspective from a user/site builder/low level developer.
tl:dr this is about plugins, not core development Apologies if deemed a thread jack, as references to plugins came up in the discussion. Feel free to split off.
Some background: my experience with WordPress and Drupal stretch back more than a decade. I almost excessively work on not-for-profit community sites (I never touch, or fork, core).
I am building a couple Discourse sites (with and without WordPress integration at the moment (alongside a couple other WordPress and Drupal sites). With WordPress, the abundance of low quality paid plugins — and it is time consuming/can be very difficult to determine their usefulness and quality — is a challenge (I mostly write my own functions where I can). That so many of the plugins (even themes) are poor hacks is similarly an issue (very poor usability outcomes).
Drupal, which has a much steeper learning curve, does have plugins that are similar of lower quality, thought these are quickly displaced by other through a community of developers. Closed source — like the WordPress marketplace fosters — actively prevents this to a substantial level. This is not to say Drupal’s approach to contributed models is without issue.
My experience with Discourse counts in months. In looking at the architecture of a community site, funding ongoing expenses came up in discussions. I searched for options and came across the PayPal plugins built by @dmitry_fedyuk — initially considering they might be an option. However the closed approach inhibits an ability to assess their quality without first paying for them. It also brought to mind the ‘plugin wasteland’ of WordPress and how painful it is.
I see such a model as fundamentally against what I understand/understood Discourse to be, and why I have looked at it as a (potential) solution for some community groups.
In short, crowd-contributing to/funding plugins, rather than a licensing model, is more what I was expecting-hoping for based on past experiences — and is what I thought was in the spirit of how discourse was envisaged and developed.
Your comment here does worry me a bit, we have kind of “looked the other way” a bit with @dmitry_fedyuk’s plugins. All of us (core devs + key community figures) know that what is going on here is not Kosher, but kind of looked the other way.
His effort to turn Discourse into a product with a Drupal like market place is very unique and not endorsed.
As it stands every plugin except for his plugins are free as in beer and free as in freedom.
I do feel that us, “looking the other way”, is starting to hurt us as a community and we should probably take a proper stand here. I banned him for one week cause he has been aggressive towards community members earlier this week.
I do wonder if we should be even linking to his work, it sends a stinky message out there.
I’ve bought one of his plugins (tables editor). It works well, and was updated quickly when I suggested a new feature. But the pricing is outrageous and I can’t imagine it helps make many sales. I’d much rather chuck a few coins in the jar and do my (limited) bit to improve a plugin in public for the benefit of all.
Before doing that, a more light-handed measure would be to require plugins listed in the plugins/marketplace categories to clearly state their license.
I think that’s the point we were discussing months ago. If it’s derived from GPL code, which Discourse is, and no alternate license is provided, then it’s also subject to the GPL.
The discussion previously suggested that he could offer it under a different license, but if he has neglected to include any license then it’s surely GPL by default? The trigger for the GPL is distribution, the code isn’t being kept within a single private organisation.
No, if you don’t provide a license with your copyrighted work (e.g. a plugin) then it is “all rights reserved” by default. If your plugin needs to be released under GPL (or a compatible license) but you don’t, then you’ve simply violated the license between the original “parent” GPL’d software’s copyright holder and you. The remedy for such a scenario is the parent work’s copyright holder enforcing the license they granted you as a plugin author.
If that’s the case, then why do projects such as WordPress and Drupal explicitly state that all derivative works are themselves bound by the GPL?
That’s nice and all, but the FSF is also the source of:
The license under which the WordPress software is released is the GPLv2 (or later) from the Free Software Foundation. A copy of the license is included with every copy of WordPress, but you can also read the text of the license here.
Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license. Drupal, which has the same GPL license as WordPress, has an excellent page on licensing as it applies to themes and modules (their word for plugins).
There is some legal grey area regarding what is considered a derivative work, but we feel strongly that plugins and themes are derivative work and thus inherit the GPL license. If you disagree, you might want to consider a non-GPL platform such as Serendipity (BSD license) or Habari (Apache license) instead.
8: If I write a module or theme, do I have to give it away to everyone?
No. The GPL requires that if you make a derivative work of Drupal and distribute it to someone else, you must provide that person with the source code under the terms of the GPL so that they may modify and redistribute it under the terms of the GPL as well. However, you are under no obligation to distribute the code to anyone else. If you do not distribute the code but use it only within your organization, then you are not required to distribute it to anyone at all.
However, if your module is of general use then it is often a good idea to contribute it back to the community anyway. You can get feedback, bug reports, and new feature patches from others who find it useful.
This goes into the legal nitty picky details now. Because none of you is actually wrong, but it is in nuances in between:
the GPL as a licence discusses the distribution of work
all work by default is under “all rights reserved” (no licence given)
whether something falls under the GPL is bound to two factors:
does it directly link to the work
the distribution
And 3.2 is where this becomes complicated. All my plugins for e.g. are under MIT. And that is totally fine. Even though the work itself is useless (as in “it can’t run”) without discourse, as I don’t distribute them together, I am free to choose whatever licence I want. I chose to publish my work – non linked – under MIT.
If you were now to bundle a discourse installation with any of my plugins, however, you as that distributor would be bound to give the entire source code to whoever you gave the binary blob too, as well as a copy of the GPL stating they are allowed to redistribute as they please, too. This is only possible because my MIT license is actually permissive enough to work with the GPL – others even aren’t. And anyone writing a plugin could use any of those licences, making a distribution after bundling impossible (this is where the partly non-free part of distros comes into play). Which is kind of what has happened here: without any permissive licence, this work by itself isn’t allowed to be redistributed. Even though you are allowed to use it with your discourse (implied licence), you aren’t allowed to distribute it to others as the licence you have directly strikes against the GPL.
Or to put short, you can licence your work whatever the f* you want, but you aren’t allowed to distribute it bound to DC in any other licence than GPL (or you bought a different licence from the core team). @dmitry_fedyuk just gave you his work (a plugin). The copyright and licence you are given for it is: this is his work, you aren’t allowed to distribute. GPL or not.
Bear in mind that the GPL was built to protect you against having only binary blob libraries linking to code you can’t possibly understand and is quite unclear about how this applies for interpreter languages (like Ruby, PHP or Python) and work coming out of that. This is also exactly what the Wordpress refers to when they say
To my knowledge there hasn’t been any court cases discussing this specific issue yet and this matter stays unresolved until then. But if you were to release his code, he’d quite frankly be able to sue you for copyright infringements – and you’d have an uphill battle to proof that it had been covered by the GPL. I’d strongly advice against that.
This is only the legal stand point of course. What the core team allows to be market here and on other official places, is of course a question of social conduct and rules outside of copyright law.
For the record, I have no intention of distributing the code I paid for, and I wouldn’t encourage anyone else to do so.
However, I do think it would be better for the discourse community if this code was open source, and the author used one of the compatible ways of getting paid for his work.
When there’s active discussion about sponsored third parties contributing to core, I can’t help but think that the ransom approach is unnecessary.
Most of this discussion began when one developer chucked his rattle out of the pram, and tried to suggest Discourse should become Magneto. Until then the prospect of enhancing the core product was pretty attractive.
I personally have nothing against charging money for plugins. In the long term I want Discourse to become an ecosystem that can support many different types of sites and people working on it. I’m not sure if a plugin could pay the bills, but I don’t mind people experimenting with it.
I do strongly object to advertising a plugin here on meta that does not include a license. I feel it should be an official rule that if you want to use our site to let people know about your plugin, the license needs to be up front.
Paid or even Free (not that I think it matters, as most Free ones will include a GPL or similar license). Call it curiosity.
I’ve been sort of sitting in the background just reading the impeding discussion and I’ve yet to really make my mind up. On the one hand, I know I’ll likely never charge for any plugin I create, just too much hassle with that and I have a full time job that pays the bills, so eh.
On the other, it shocks and surprises me that someone who wants payment for a plugin, doesn’t have a license for their work. I thought that was business 101, even development 101 when you get to freelancing, but again, to each their own.
I do see how the lack of a license can be harming to an ecosystem, but I would have thought it would be much more harmful to the plugin that lacks it. Sure it creates gray questionable areas for those who use it, but it is the plugins author who then has to deal with the outcome of their paying customers lack of ability to process the underlying intent.
So far, I must say that I’ve really enjoyed reading this topic (and some of the semi-related ones).
