Addon licensing now required to be GPL2-compatible
Linc
Admin
As of now, new & updated addons distributed on this site must be distributed under a GPL2-compatible license. Preferrably, one of:
- GNU GPL2
- MIT
- BSD
- GNU LGPL
- Mozilla Public License (MPL) v2
A notice has been added to the addon upload pages to make this clear. The GNU GPL2 will be used as the default if no license is declared from now on.
Why are we changing this?
The addons directory should be a safe learning & sharing resource, and a collaborative effort for improving Vanilla. Putting proprietary addons in the directory puts other users at risk of inadvertently infringing their license or copyright. Even using a single line of code from a proprietary plugin can put you at risk. Worse, even looking at a proprietary addon "for ideas" can cause you to infringe their license by coding something similar. It really is that scary. The directory shouldn't be a minefield.
Does that mean I can't release a proprietary Vanilla addon now?
Absolutely not. We just ask you to not upload it to this site. You can link to a GitHub repo in a discussion, for instance. If you do share an addon in another way, please still include licensing information explicitly.
What about my proprietary addon that is already uploaded?
They are grandfathered under the old rules. Any updates will trigger the new rules. At some point, we may start cleaning out non-compatibly-licensed addons. We will not retroactively re-license a plugin without explicit permission from the author.
What if I wish to withdraw my addon from the directory?
Send a private message to @linc with deletion requests.
What licensing does Vanilla use?
We use the GNU GPL2 and MIT licenses. We use the former for most of our core product & addons, and the latter for separate framework-like projects (e.g. the new Garden project & Minion). The MIT license is extremely liberal. We recommend one of these two licenses if you aren't sure what to use.
What about the GNU GPL3?
GNU GPL3 will be an exception to the grandfather clause: you may continue updating GPL3 addons and keep it under the GPL3 if you wish. However, we strongly recommend changing the licensing to be GPL2-compatible, and ask that new addons not use it. It's complicated, but the short version is GPL3 code cannot be brought into GPL2 code so it turns into a headache really fast.
I have some other open source license I want to use, like Apache
Send a message to @linc outlining your rationale and we might allow it on a one-off basis. Really, I can't think of a valid reason for that besides a complicated business scenario, but I'm willing to talk about it.
Licensing sounds confusing
It really is. I'm happy to answer questions about licensing issues to the best of my ability. Note I am not a legal professional so please don't construe it as anything more than opinions and guidance for doing your own research.
Comments
I am calling the GPL3 grandfathering The @Kasper Clause.
I've been kind of lazy with this. Should a license file be included in new plugins / new versions of plugins now, or will it be sufficient to update the description on vanillaforums.org?
My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations
VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS
I do like me some GPLv3
Kasper Kronborg Isager (kasperisager) | Freelance Developer @Vanilla | Hit me up: Google Mail or Vanilla Mail | Find me on GitHub
@Bleistivt The easiest thing to do is add a
'License' => 'GNU GPL2',line to the plugin definition array. Updating the description is fine, but we'll probably add programming to detect the license from the definition and display it.Technically, you should also distribute a license file with the plugin in its folder, but that's up to you. Really I just want to clarify intentions.
I am happy with this. I generally MIT unless I have to GPL such as a derivative work.
I use
LICENSE.txtTechnically you are using your discretion, as I researched if you don't explicitly state, all addon could be deem in court to would fall under GPL-2 anyway, as they make use of core functions (hooks). Libraries on the other had which work the other way can be distributed separately.
grep is your friend.
Apache licences are not compatible for libraries, I’m not sure about this way round.
grep is your friend.
Sorry I should be clearer, anything which has functions that will be set up or registered to be called by a GPL software (e.g. uses hooks), that originator needs to use discretion for licence, and is treated differently than libraries.
grep is your friend.
Good move. You went to WordPress way, I like it!
No the wordpress way, is it has to be GPL, they don't accept MIT, BSD or any others.
The wordpress way is not so cool, also their court cases set worrying precedents.
grep is your friend.
Sowwy...
Not true.
I will say we are coming at it from very different philosophical perspectives, tho. WordPress has taken the strong stance that ALL plugins & themes are derivative works and therefore must be GPL compatible.
Our stance is that we want this, specific directory to be free of proprietary land mines for new users, so we ask that code uploaded here conform to those licenses. We do not care if you want to sell your proprietary addons elsewhere.
But like I said GPL compatibility for libraries is allows MIT, BSD, as when you bundle them in comes under GPL together. GPL for plugins only allows GPL, except when discretion is offered. This information comes from GPL HQ, I have posted the link before.
It was a subject of a wordpress suit that the consider all plugin as part of the core. I'm not saying the person was right, just I question the strategy. The way I see it was a simple copyright issue, and should have been dealt with that way.
I have never heard, explicit discretion from wordpress on this. I wouldn't trust them.
Wordpress on the one had tolerates proprietary licences, as it they do exist, and they leave them be. But when they feel like it, they sue.
They are many wordpress related plugins out there that aren't really GPL compatible, some quite big companies too, from merchant system, to theming engines. It is not as if Wordpress would be unaware of them. They are not listed on their site, but some of them are well known.
grep is your friend.
One common thing is theme engines that licence the code (gpl), but the rest of the theme as something else. But the law suit was to do with a themer.
grep is your friend.
I think you are misunderstanding GPL compatibility. You can absolutely write a MIT-licensed plugin for WordPress, because it can be freely incorporated into the rest of the GPL'd code without issue, and could be re-released as GPL if anyone desired. There would be no point whatsoever in outlawing a license that is even more liberal than GPL.
@x00 is there a link to the lawsuit anywhere? I never knew any of those Wordpress things ever made it to court. I thought nothing made it past community pressure. Just interested.
Yes, I would like to know too.
@Todd said:
Actually you are right it was settled out of court
http://www.blogherald.com/2010/07/15/inevitable-wordpress-to-sue-thesis-founder/
grep is your friend.
Well anyway I'm happy with Vanilla's approach on this.
I have never released a addon for Garden that is not MIT, or GPL. I only ever wanted to provide permissive licences where I can.
grep is your friend.
Perhaps I was misunderstanding GPLs infectiousness. Is using hooks enough to infect a an MIT plugin on its own or is to only a case where it is distributed together? Is using garden's method enough to infect? Are theme views enough to infect, probably unless they are completely rewritten. What about extending a core class?
grep is your friend.
I don't think you were, only that an even more liberal, compatible license fulfills the same requirement as actually using the GPL.