Agenda for Feb 11th 2010 dev chat
- Quick update on the menu management progress – Jane
- Quick discussion on the best way for plugins to be explicit about which licence they are under – Peter
- Update on improvements to Extend for plugins – Peter
- Update on schedule compliance
KnxDT, 
Auditing WordPress Plugins for License Disclosure - WordPress Tavern Forum 10:48 pm on February 10, 2010 Permalink
[...] just like that, some discussion is generated – by Westi, for tomorrow's Dev Chat! @chip_bennett | chipbennett.net (est. 2000) | WordPress user since May, 2005 | Linux (Kubuntu) [...]
Chip Bennett 10:56 pm on February 10, 2010 Permalink
For background on explicit license disclosure in plugins: http://bit.ly/cjfJU1
+1 to Westi’s suggestion to use “License” and “LicenseURI” slugs in the plugin header!
Matt 3:07 am on February 11, 2010 Permalink
If there is nothing explicit it’s GPLv2. We don’t need a million duplicate txt files in the repo.
Chip Bennett 3:12 am on February 11, 2010 Permalink
I’d be fine with that – except we have the plugin repository moderator telling plugin developers “not including the declaration will get [your plugin] removed” (see my link above).
So, we need clarification one way or another.
Personally, I think that, since the plugin is a derivative extension of WordPress, the license.txt file in WordPress itself should be sufficient to meet the “must include the full text of the license” requirement of the GPL (provided, of course, that the plugin uses the same GPLv2).
Matt 3:13 am on February 11, 2010 Permalink
Whoever added that should update it. It was probably in response to lame spammers or something.
Chip Bennett 3:19 am on February 11, 2010 Permalink
Not a “lame spammer”, just someone who didn’t understand the GPL requirements/impact, but who immediately modified his plugin to conform once he understood.
Alex M. 3:25 am on February 11, 2010 Permalink
As I mentioned on Twitter, in my opinion anyone who goes to the trouble of making their plugin output a link to their site and then obfuscates the code with base 64 encode doesn’t have good intentions and is a lame spammer.
That’s just my personal opinion though.
Chip Bennett 3:32 am on February 11, 2010 Permalink
Even when that same person goes to the trouble of removing the obfuscation, doing everything possible to comply with the GPL and with the repository guidelines?
I really, really dislike the default inclination to allege, try, and convict as a “dirty spammer” everyone who fails to adhere to those requirements. Sometimes people make mistakes, and sometimes people are just ignorant of those requirements.
In this case, the person in question made every possible effort to rectify the situation (and apparently, Mark R. agreed, since he subsequently approved the plugin in question).
He wasn’t trying to spam anyone; he just didn’t understand that the GPL didn’t allow him to prevent users from removing or changing his attribution link. Once it was pointed out to him, he expressed understanding for why base64-encoding that link was unacceptable, and immediately un-encoded it.
The guy is (much like me) new to developing plugins for WordPress. Sometimes giving the benefit of the doubt is the right approach.
Jeffro 3:41 am on February 11, 2010 Permalink
This is in reply to Alex. First off, not everyone who does that is evil and has bad intentions. This situation with this plugin author proves that. They simply didn’t know better and in fact, after being informed on proper guidelines and such, they modified their plugins to be in line with the repository. If this was a legitimate spammer, I don’t think they would have removed that stuff because quite frankly, why would they.
I hope this attitude and mentality is not close to the vest of the WordPress project. It may be true that those who obfuscate code have bad intentions but sometimes, those intentions may be misaligned. Each situation should be dealt with on a case by case basis without stereotyping.
Look at what happened in this situation when a group of people that cared worked with an individual that was in the wrong and steered him into the right. He learned and is now a happier person within the community.
Ryan 5:27 am on February 11, 2010 Permalink
@Jeffro = +1
AFAIK the GPL states that the license needs to be included with the download. It’s possible I’m wrong, but I don’t think I am.
Matt 6:48 am on February 11, 2010 Permalink
The GPL doesn’t say you can’t base64 your plugin, it’s just lame to and we don’t want you in the directory if you do.
Chip Bennett 1:03 pm on February 11, 2010 Permalink
@Matt, did you actually *read* the background information? The drive-by one-liners lead me to believe that you haven’t.
Also, nobody is questioning that the wordpress.org plugin repository can or should have more strict rules than mere GPLv2 compatibility. That’s not the issue.
The issue is the enforcement of unwritten guidelines, that should be clarified:
1) Explicit declaration of license. MarkR says that if it’s not declared, the plugin will be removed from the repo (which is why I wrote my post, to show the selective enforcement of). Then, here, you say that if it isn’t explicitly declared then it is assumed to be GPLv2 compatible.
2) Base64 encoding. It’s almost always – if not always – bad. It shouldn’t be used in repository-hosted plugins. But it’s not indicated as such anywhere in the repository guidelines. Simple resolution? Add it to the repository guidelines.
But, the issue of unwritten guidelines is rather out-of-scope from Westi’s discussion point above, so I’ll leave it at that.
Jeffro 3:23 pm on February 11, 2010 Permalink
Something else that can be brought up in a future developer chat. The guidelines tell plugin authors what they have to do in order to be hosted but there are no guidelines for what it will take to have a plugin removed. From what I’ve seen, based on the circumstances, it’s a one strike and you’re out rule. Which is dumb. Especially when all the information about acceptance and grounds for removal are not public within the guidelines page. Just a couple of pointers that inform plugin authors that if their plugin does so and so, it will be removed. This would be a good place to put in the no-obfuscated code guideline.
The way you make it sound Matt is that all plugin authors, especially new ones have a clear idea as to what is acceptable and unacceptable. It’s pretty bad that a new plugin author can come into the fold, screw up based on lack of knowledge or experience in the WordPress world and before they even had a chance, they get shunned away and banned. Cmon. The system has to be better than that.
Ryan 10:00 pm on February 11, 2010 Permalink
+1 again on Jeffro’s comment
These guidelines definitely tightened up a little. I don’t have time to go to the dev. chat, but if someone would like us to sort out a draft writeup of some guidelines I’d be more than happy to organise for a bunch of us to get something together and submit it as a suggested set of guidelines. I’m sure Chip and a few others would be keen to help out with it. There’s not a lot to be cleared up, but these are real problems which are affecting people in a negative way so it would be nice to sort it out.
Joseph Scott 11:06 pm on February 10, 2010 Permalink
Should we specifically say GPL v2 compatible instead of just “GPL compatible”? The WordPress license (GPL v2 without ‘or later version’ clause) is not compatible with GPL v3 so this could clear up some confusion.
vanderzanden1 11:38 pm on February 10, 2010 Permalink
That doesn’t seem relevant here. There’s information about what license to use in the authors instructions. And users can specify whatever license they want anyway. What you are suggesting would only be for released plugins I assume.
I’d have thought just enforcing the existing GPL rules in the plugin repository would make sense. Chip has an interesting list of stats over on the Tavern … http://www.wptavern.com/forum/plugins-hacks/1303-auditing-wordpress-plugins-license-disclosure.html
Jeffro 2:36 am on February 11, 2010 Permalink
I was told that the plugin repository license is different from the license that WordPress has. Two totally different things. The plugin repository can host GPLv3 plugins due to the difference. However, I would like to see more clarification of some sort as when I looked at the license of WordPress, I thought because of it, GPLv3 plugins would be incompatible and thus, could not be hosted.
Alex M. 2:37 am on February 11, 2010 Permalink
Plugins are derrivative work and therefore must fall under a compatible license with WordPress.
See that post Matt put up a while back on the dev blog about themes. It applies to plugins too.
sc0ttkclark 2:46 am on February 11, 2010 Permalink
This is going to be a juicy discussion!
Unwritten Guidelines Suck 2:40 am on February 11, 2010 Permalink
[...] specific topic has been added to the WordPress Developer meeting for February 11th, 2010. If you are interested in attending to voice your thoughts, visit the WordPress development [...]
KnxDT 4:52 am on February 11, 2010 Permalink
Hi, I didn’t know that the obfuscation was a problem, I did it because other “bloggers” changed (only) that credit lines with their own link. To prevent that situation, the credits were encoded. Then my friends from wp-tavern forum explained me that this situation was normal because the license is GPL, so I decoded the line and I added a option to deactivate it. I’m not the devil, I’m not a “lame spammer”, I’m just a newbie learning about PHP and WP
But I still having some doubts about the GPL file. Do we need a gpl header message in the plugin code? Do we need a txt GPL file? Both? Thank you very much
Chip Bennett 4:14 pm on February 11, 2010 Permalink
Personally, I think you are owed an apology by a few people who speciously accused you of being a “dirty spammer” (and “lame spammer” et al) – but I don’t believe this is the appropriate forum to pursue that.
Auditing WordPress Plugins for License Disclosure - Page 3 - WordPress Tavern Forum 5:44 am on February 11, 2010 Permalink
[...] I'm a little sad with this situation. Now I'm like the devil. I just wanted to learn and understand some new things related with GPL and [...]
Andreas Nurbo 7:19 am on February 11, 2010 Permalink
Alex M
Generally yes but not always. You can make plugins that can work without WP. I got a few of those.
I also think there should be some written explanation about the use of non gpl libraries and if that is ok or not ok to be in the repository.
Peter Westwood 7:40 am on February 11, 2010 Permalink
My understanding is that in this case at least the wrapper code you write to integrate with WP is a deriverative work and needs to be GPL2 compatibly licenced. After that it becomes a grey area.
Rarst 7:53 am on February 11, 2010 Permalink
Example – I make plain PHP class to handle something and add WP plugin header to it so I can conveniently include it there. Plugin makes no calls to WP functions and in no way dependent on WP code. There are just few extra comment lines so WP recognizes it.
Is it derivative?
Andreas Nurbo 2:40 pm on February 11, 2010 Permalink
I think this really should be on the agenda. It goes hand in hand with the rest of the plugin update stuff.
Chip Bennett 3:20 pm on February 11, 2010 Permalink
Just to separate the two lines of discussion:
1) Prohibiting the use of encoded (e.g. base64) content
2) Requiring that any public-facing attribution link have a user-configurable option to disable
3) Any other requirements currently being enforced
(Please note: I’m not objecting to any such guidelines; rather, I’m just requesting that the official guidelines be revised to include them, so that future confusion/issues might be avoided.)
Jeffro 3:26 pm on February 11, 2010 Permalink
The guidelines should be written in such a way that when they are violated, MarkR can just copy and paste the guideline that was broken to the plugin author with a short explanation as to how to fix it. MarkR should not be telling plugin authors they are breaking the guidelines when the guideline doesn’t exist in the public’s eye.
If this had been done in the first place, we wouldn’t need to have this conversation.
Joseph Scott 4:59 pm on February 11, 2010 Permalink
“Requiring that any public-facing attribution link have a user-configurable option to disable” – I think you have the reversed. No plugin should inject attribution links by default. If they want they can have a user option to enable the link, defaulting to off.
I appreciate that frustration from not having a list of every possible thing that would be prohibited in plugins, though it’s a much harder task than you are making it out to be. There needs to be some open source common sense involved. Using schemes that try to hide/mask/confuse things like credit links should be an obvious no-no. Does that mean the plugin directory rules need to specify every single possible way that plugin authors might try to hide/mask/confuse code? I don’t think so.
Can we do better? Sure, let’s find things that are helpful and work. Do I think plugin authors should be able to complain because their exact method for hiding/masking/confusing code wasn’t spelled out in perfect detail in the FAQ? No, we’ve got better things to do and should move on.
Chip Bennett 5:11 pm on February 11, 2010 Permalink
Except, the way that I phrased it is the way it is currently being enforced.
I don’t have a preference either way – but your response perfectly illustrates why such a guideline needs to be stated explicitly.
Not every method *needs* to be spelled out. A straight-forward guideline prohibiting obfuscating code (e.g. base64 encoding) should be sufficient.
BTW, “open source” is not referenced anywhere in the guidelines or in the WordPress philosophy, but rather “software freedom”. The two do not mean the same thing.
While I agree that free-software common sense should be the guiding principle, not everyone is well-versed enough in either the GPL itself or free-software philosophy in general – particularly developers who may be new to WordPress development.
If the guidelines need to be kept at a certain high level, then we need to develop an FAQ that addresses the more specific situations/questions. Right now, new developers have *nowhere* to turn.
KnxDT 8:33 pm on February 11, 2010 Permalink
Credit link disabled by default.
KnxDT 8:56 pm on February 11, 2010 Permalink
Even better: I removed even the credit link to my site. The credit link (disabled by default) is now linked to the oficial repository plugins page.
I still having the doubt about the GPL license so I changed the 3.0 GPL txt to 2.0 GPL.
Jeffro2pt0 9:02 pm on February 11, 2010 Permalink
As was just discussed in the meeting, this is probably a good thing regarding the change.
Ryan 10:04 pm on February 11, 2010 Permalink
I also used GPL3 in the beginning, albeit only because I figured using the latest version was the smart thing to do. But in retrospect it does make more sense to use the same license as WordPress itself.
Good luck with the plugin now that you have got all these problems sorted out
KnxDT 10:16 pm on February 11, 2010 Permalink
To avoid problems… I removed any kind of link. Thank you, Ryan.