Opened 14 years ago
Closed 13 years ago
#16898 closed feature request (fixed)
Fix plugins about page license requirement
Reported by: | scribu | Owned by: | |
---|---|---|---|
Milestone: | WordPress.org | Priority: | normal |
Severity: | normal | Version: | |
Component: | WordPress.org Site | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
The plugins about page requires plugins to be GPLv2 compatible:
http://wordpress.org/extend/plugins/about/
WordPress is licensensed under GPLv2 or later:
http://wordpress.org/about/license/
The Clarification in Licensing Language also states GPLv2 or later.
The plugins about page should be updated to also read GPLv2 or later.
Change History (53)
#3
@
14 years ago
- Cc chip@… added
Note also that the Theme Repository currently accepts GPLv3 Themes. The only requirement for the Theme Repository is that Themes must be 100% GPL-compatible, with no version specification.
Shouldn't Plugins be considered likewise?
#5
follow-up:
↓ 48
@
13 years ago
- Type changed from defect (bug) to feature request
This isn't a bug, so changing it to feature request.
Feel free to argue why we should allow GPLv3 plugins on the wp-hackers list. I'll give you the pros and cons real quick:
Cons:
- It makes integrating code/idea from plugins into core impossible if the plugin is GPLv3.
- Some people will not use or work on GPLv3 code. It's incompatible with too many things.
Pros:
- Let me know if you find any. I don't know one.
#6
follow-up:
↓ 7
@
13 years ago
We've already had this discussion on wp-hackers. Here's the link again:
http://lists.automattic.com/pipermail/wp-hackers/2011-March/038343.html
#7
in reply to:
↑ 6
;
follow-up:
↓ 10
@
13 years ago
Replying to scribu:
We've already had this discussion on wp-hackers. Here's the link again:
http://lists.automattic.com/pipermail/wp-hackers/2011-March/038343.html
Yes, and while markjaquith was himself considering loosening the restriction, he did not fully commit in that direction, and no one else did, either.
I spend a decent amount of my time reading through code in the plugins directory. I would hate for a plugin we like for core to be licensed in an incompatible way. I would also hate for me to pick up code or an idea from a plugin that is licensed in an incompatible way and then end up using that in core, thereby doing quite a bit of damage.
Are either of these going to cause practical problems in our work on core? Probably not, no. It does bother me enough to second-guess it, all for the sake of including Apache 2.0 or GPLv3 code.
I'd vote keep the themes directory even with WordPress and the plugins directory, but it's not like the chances are high that we would borrow code or an idea from a theme for core, so I don't care too much, and I declined to suggest to the core team to change what the theme reviewers reasonably chose.
Of course, the case could be made that if there are plugins we want to integrate, we could simply ask the author to re-license, and if the author is not bound by an external library (or is not long gone), then this would be fine. (And, if they are reliant on an incompatible library, it's not like we'd be able to use the code under any other circumstances.)
The reverse case could be made that a plugin author could choose a core-incompatible license to avoid ever getting merged into core. While some authors like contributing back, others would not like seeing their work be absorbed, just as some do not like seeing their work made obsolete by a core feature. Is such a hostile acquisition ever going to play out? No, I don't imagine so. WordPress's core contributors are highly capable to work around unforeseen issues such as these, and as has been pointed out, not many plugins find their way into core. (I would certainly suggest far more than 10, though.)
Just some thoughts.
#8
follow-up:
↓ 9
@
13 years ago
Disclaimer - I don't have any issue whatsoever licensing my own code under GPLv2 or compatible. We don't have such issue at work either.
However - there is plenty of code out there that is meant to be used by developers as libraries/components, that is not compatible to GPLv2 (typical case is Apache License).
Just from personal experience:
- I had to use inferior JavaScript solution for charting, because my first choice was under Apache License;
- I had to write from scratch PHPDoc parser because best fitting ready-made library I found moved on from GPLv2 to GPLv3;
- I need to upgrade library to accommodate Google API changes and I can't use official Google's library which is under Apache License.
And another issue is - this rule is not respected de-facto. There are hundreds of files in repository licensed under Apache (just google "Apache License" inurl:trunk site:http://plugins.svn.wordpress.org/
). Probably as many GPLv3 only and others. I've seen as bad as "all rights reserved - do not copy without permission".
Developers trying to follow rules are forced to use inferior libraries or invent the wheel.
Developers who don't give a damn about rules (or ignorant of them) just go on filling repo with incompatible code, because this rule is paper tiger.
For the inclusion in core argument it would probably be easier to not get into trouble by assuming that anything in repository is not compatible and needs checking. Because in current situation just seems more likely to get one into trouble by assuming that everything there is GPLv2 - it isn't.
#9
in reply to:
↑ 8
;
follow-up:
↓ 11
@
13 years ago
Replying to Rarst:
Disclaimer - I don't have any issue whatsoever licensing my own code under GPLv2 or compatible. We don't have such issue at work either.
However - there is plenty of code out there that is meant to be used by developers as libraries/components, that is not compatible to GPLv2 (typical case is Apache License).
Yes, and none of them are usable. Licensing isn't a game, man. If somebody uses an incompatible license, then they don't want you using their code.
Developers who don't give a damn about rules (or ignorant of them) just go on filling repo with incompatible code, because this rule is paper tiger.
No, it's not. Email plugins@… about license issues, and plugins with incompatible licenses will be removed from the directory.
Just because we haven't found it and removed it yet doesn't mean it's not a hard and fast rule. Non-GPLv2 compatible plugins *will* be removed from the directory when discovered.
#10
in reply to:
↑ 7
@
13 years ago
Replying to nacin:
I would hate for a plugin we like for core to be licensed in an incompatible way. I would also hate for me to pick up code or an idea from a plugin that is licensed in an incompatible way and then end up using that in core, thereby doing quite a bit of damage.
Likewise.
it's not like the chances are high that we would borrow code or an idea from a theme for core
We did with menus. As more themes throw things into the functions file instead of creating a separate plugin for features, I don't think this is a safe assumption.
I would think we would want everything on wordpress.org to have consistent and compatible licensing. If we've moved away from that, is Matt aware of it? (I wasn't.) He's always said in the past that anything promoted (including being hosted) on wordpress.org needs to be 100% GPL, and said that no one should ever have to wonder what they can/can't do with something we host, because the license would be the same/compatible. If the theme reviewers team has instituted a policy that changes that intent, we should make sure Matt is aware of it in case he has objections.
#11
in reply to:
↑ 9
;
follow-up:
↓ 12
@
13 years ago
Replying to Otto42:
Yes, and none of them are usable. Licensing isn't a game, man. If somebody uses an incompatible license, then they don't want you using their code.
There is no issue with using such code. GPLv3 and Apache License are perfectly compatible with WP.
This is issue with repository rules seemingly serving edge case (including code in core) and for such forbidding combination of code that is fine from licensing point of view.
#12
in reply to:
↑ 11
;
follow-up:
↓ 13
@
13 years ago
Replying to Rarst:
There is no issue with using such code. GPLv3 and Apache License are perfectly compatible with WP.
No, neither the GPLv3 or Apache License 2.0 is compatible with the GPLv2.
#13
in reply to:
↑ 12
@
13 years ago
Replying to Otto42:
Replying to Rarst:
There is no issue with using such code. GPLv3 and Apache License are perfectly compatible with WP.
No, neither the GPLv3 or Apache License 2.0 is compatible with the GPLv2.
With GPLv2 only. But WP is not GPLv2 strict.
license.txt
WordPress - Web publishing software
Copyright 2011 by the contributors
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
GPLv3 (and so Apache) is compatible with "GPLv2 or any later version".
#14
follow-up:
↓ 16
@
13 years ago
GPLv3 (and so Apache) is compatible with "GPLv2 or any later version".
It's one-way compatibility. A GPLv2 or later project cannot use code that is GPLv3, as the code is not licensable under GPLv2.
#16
in reply to:
↑ 14
@
13 years ago
Replying to nacin:
GPLv3 (and so Apache) is compatible with "GPLv2 or any later version".
It's one-way compatibility. A GPLv2 or later project cannot use code that is GPLv3, as the code is not licensable under GPLv2.
Let's put it like this - there is no licensing reasons WordPress plugin or theme cannot be licensed under GPLv3 or Apache License 2.0, correct?
There is organizational reason that plugin or theme under GPLv2-compatible license are easier to assimilate in core. Which is currently put in writing as repository rule.
My points are, that rule is:
- Inconsistent (theme repository allows GPLv3).
- Serves extreme edge case (amount of plugins ever assimilated in core seems to be put at two digits, total amount of plugin in repository at five digits).
- Detrimental for plugins quality by cutting off use of open source components.
- De-facto ignored by developers and repository personnel (my subjective impression that I will try to backup in near future by some numbers).
#17
follow-up:
↓ 18
@
13 years ago
To quote GNU on this one:
Apache's outright no.
Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in the older version. These include certain patent termination and indemnification provisions.
GPLv3 and GPLv2 are more complicated.
Please note that GPLv3 is not compatible with GPLv2 by itself. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well. When this is the case, you can use the code under GPLv3 to make the desired combination.
Which leads you to http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
and http://www.gnu.org/licenses/gpl-faq.html#v2v3Compatibility
Is GPLv3 compatible with GPLv2? (#v2v3Compatibility)
No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.
However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits.
So clearly GPLv3 can use GPLv2-or-later code, but GPLv2 cannot use GPLv3. Not backwards compatible if that makes sense.
And that also gives us:
If you have the ability to release the project under GPLv2 or any later version, you can choose to release it under GPLv3 or any later version—and once you do that, you'll be able to incorporate the code released under GPLv3.
So ... Basically you'd have to CONVERT GPLv2 to GPLv3 in order to truly release as that. Which we can't do for core (sign off from every dev to change the license, ain't realistic), and we already know that plugins have to be compatible with GPLv2 since they use WP functions etc.
The reason themes are okay is that they can be dual licensed, I suspect. The WP specific code is GPLv2, where as the non WP stuff is not. So Akismet, for example, is GPLv2 for what's in the repo, but it's service stuff on it's own servers doesn't need to be. Themes don't phone home and must be self contained so they're handled differently.
#18
in reply to:
↑ 17
@
13 years ago
Replying to Ipstenu:
And that also gives us:
If you have the ability to release the project under GPLv2 or any later version, you can choose to release it under GPLv3 or any later version—and once you do that, you'll be able to incorporate the code released under GPLv3.
So ... Basically you'd have to CONVERT GPLv2 to GPLv3 in order to truly release as that. Which we can't do for core (sign off from every dev to change the license, ain't realistic)...
WP is currently released under "either version 2 of the License, or (at your option) any later version". As far as I remember it was relicensed as such from earlier state - GPL of unspecified version.
#19
@
13 years ago
Which IIUC means you can use it in your GPLv3 licensed stuff, but you can't fold back the GPLv3 into GPLv2 (or later) and integrate it into core. Yes, I know how weird that sounds.
#20
@
13 years ago
Replying to Ipstenu:
To quote GNU on this one:
...
None of that matters, because none of the Plugins are being distributed with WordPress. They're simply being distributed, stand-alone. Any use, combination, or compilation is taking place by the user. So, Rarst is right: there is absolutely no licensing reason that the repository can't host GPLv3 Plugins.
I also tend to agree with Rarst that the risk of rolling a GPLv3 repository-hosted Plugin into core is insignificantly trivial. And if it were ever truly an issue, the Plugin developer could be requested to release the code under GPLv2; problem solved.
The repository policy is what it is, because the owners of the repository want it to be that way. And there's nothing wrong with that. But such policy decision should not be conflated with non-existent licensing requirements.
The reason themes are okay is that they can be dual licensed, I suspect. The WP specific code is GPLv2, where as the non WP stuff is not.
Not really. Note that the guidelines simply stat GPL compatible; no version of GPL is specified. 100% of code hosted in the Theme repository must be under a GPL-compatible license - not just PHP, but everything. You will find no split-licensed code in the repository. But by the same token, we don't differentiate between GPL versions.
#21
follow-up:
↓ 22
@
13 years ago
None of that matters, because none of the Plugins are being distributed with WordPress. They're simply being distributed, stand-alone.
BY WORDPRESS.ORG though, yes? Thus they are pushed through the WordPress plugin installer, in a direct connection to the servers and your blog. Which ... Makes that a really shady thing since it's distribution. Murky grey. I'd get a lawyer, and an answer as to what the wordpress.org (not WordPress the app) was licensed as first.
Personally I don't have a horse in this race. I think that GPLv2 for plugins is fine, and that they should come to some sort of level with plugins vs themes.
The repository policy is what it is, because the owners of the repository want it to be that way. And there's nothing wrong with that. But such policy decision should not be conflated with non-existent licensing requirements.
I didn't think it was. I was positing, since Rarst asked me directly, my view on why GPLv3 was no go with GPLv2.
It makes integrating code/idea from plugins into core impossible if the plugin is GPLv3.
That alone is a good reason, and it will keep any more legal/copyright issues from becoming murkier. Like the issues we have with a certain song.
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
13 years ago
Replying to Ipstenu:
None of that matters, because none of the Plugins are being distributed with WordPress. They're simply being distributed, stand-alone.
BY WORDPRESS.ORG though, yes? Thus they are pushed through the WordPress plugin installer, in a direct connection to the servers and your blog. Which ... Makes that a really shady thing since it's distribution. Murky grey. I'd get a lawyer, and an answer as to what the wordpress.org (not WordPress the app) was licensed as first.
I still see no licensing issues in that arrangement. It's all an end-user scenario. The end user searches, transfers, and installs Plugins, stand alone into his own instance of WordPress.
Personally I don't have a horse in this race. I think that GPLv2 for plugins is fine, and that they should come to some sort of level with plugins vs themes.
My primary horse in this race is avoiding more needless licensing drama. I would much rather WPORG simply state that, as a matter of Policy, hosted Plugins must be GPLv2 compatible; end of story. No need to delve into the finer points of derivative code and license inheritance, nor the nuances of inter-version compatibility of the GPL itself.
I stated an opinion in an earlier comment, but it won't be a big deal to me if that opinion is over-ruled. :) I think Jane, Nacin, et al have made compelling enough arguments to justify a policy decision that, in all honesty, needs no justification (even if some disagree with it, and ask that it be considered to be changed).
#23
in reply to:
↑ 22
;
follow-ups:
↓ 24
↓ 25
@
13 years ago
Replying to chipbennett:
My primary horse in this race is avoiding more needless licensing drama. I would much rather WPORG simply state that, as a matter of Policy, hosted Plugins must be GPLv2 compatible; end of story.
As stated in the original ticket:
It says this on: http://wordpress.org/extend/plugins/about/
There are only a few restrictions
- Your plugin must be GPLv2 Compatible.
That is the current policy. I don't know of any plans to change that.
#24
in reply to:
↑ 23
@
13 years ago
Replying to Otto42:
That is the current policy. I don't know of any plans to change that.
Awesome! So: close as wontfix, and move on?
(Honestly. You know I'm always down for a good licensing discussion. I just can't imagine how it would benefit anyone to have yet another one in this ticket. I only chimed in again because I get the sense that this ticket is headed there.)
#25
in reply to:
↑ 23
;
follow-up:
↓ 26
@
13 years ago
- Cc mikeschinkel@… added
Replying to Ipstenu:
So clearly GPLv3 can use GPLv2-or-later code, but GPLv2 cannot use GPLv3. Not backwards compatible if that makes sense.
So ... Basically you'd have to CONVERT GPLv2 to GPLv3 in order to truly release as that. Which we can't do for core (sign off from every dev to change the license, ain't realistic), and we already know that plugins have to be compatible with GPLv2 since they use WP functions etc.
Since plugins are not required to be destined for core then licensing plugins as GPLv3 should not be a problem, right?
The reason themes are okay is that they can be dual licensed, I suspect.
I'm pretty sure that Matt asserts that to be incorrect: http://wordpress.org/news/2009/07/themes-are-gpl-too/ (Matt please correct me if I misinterpreted.) My memory is that people have claimed stronger arguments for themes being GPL than for plugins so this requirement for plugins to only be GPLv2 and themes being able to be GPLv3 is a bit inconsistent.
Replying to Otto42:
There are only a few restrictions
- Your plugin must be GPLv2 Compatible.
That is the current policy. I don't know of any plans to change that.
We understand that.
However, rather than discuss abstract scenarios can we discuss specific use-cases as to why this becomes a real issue?
"Google's Official APIs Client Library for PHP" is licensed by Apache 2.0. And I'm pretty sure we'd consider Google's API to be less than insignificant in the world of web infrastructure.
Given that their library is rather complex and the fact that they've provided such a large library I'm pretty sure we're not going to see someone rewrite as a GPL-licensed library that could be used instead of Google's Official APIs Client Library for PHP let alone an alternate library that someone will also be motivated enough to maintain.
So effectively this policy disallows anyone to write a plugin that uses any of Google's APIs unless the write all the plugin developer writes all the code themselves to access the API, and if they do they guess what: we've created a situation where the chances are high that an end-user of said plugin will see bugs they would not see had we been allowed to use the official library.
Replying to Otto42:
If somebody uses an incompatible license, then they don't want you using their code.
I'm as close to 100% sure as I can be that your statement does not apply to Google's desire related to their Official APIs Client Library for PHP. Instead Google was almost certainly and ironically attempting to provide as much flexibility in use of their APIs as possible.
It is certainly possible that we could get Google to dual license it, but Google being as big as they are their bureaucracy to liable to make it difficult if not impossible to make that change.
So let me list several paths forward, one of which by definition the community must take:
1.) Simply allow GPLv3 plugins into the repository, just like for the themes repository. This would be the easiest and lowest friction approach and really doesn't have much downside.
2.) Whitelist selected Apache 2.0 libraries that can be used. Just like a court of law sometimes create a narrow ruling to keep from setting a precendent maybe the best plan would be to whitelist libraries based on an objective criteria? For example:
"Any library published by a vendor to allow access to it's own API and licensed using a GPLv3 compatible license such as Apache 2.0 could be used by a plugin developer to create a GPLv3 licensed plugin otherwise all plugins must be GPLv2."
This would resolve the issue of "But we might want the plugin in core" because thus far WordPress has only included API interaction with Automattic and WordPress Foundation APIs and my guess is there are not plans to expand that (right?)
3.) Remove existing plugins that use non-GPLv2 compatible licenses from the repository and ignore Google and other vendor's Apache 2.0 licenses and anyone who might need to use one of them. Although this could potentially create huge disruption for end-user who rely on those existing plugins, doing this would allow the WordPress core team to continue it's GPLv2-only position for plugins and maintain the moral high ground.
4.) Do nothing at all and both enable the violators and perpetuate a hypocrisy by allowing violating plugins to continue to exist in the repository while at the same time ensuring that those who strive to follow the rules are barred from doing the same thing that the violators are empowered to do.
That's about it; not sure if there is a 5th path.
So, assuming there is not a 5th path the core team must do one of the above with #4
being the default "do nothing" path. But the default path has far more downside IMO than #1
, so why not #1
(although IANAL doing #4
could potentially even create legal liability for the guardians of the repository as it induces people to claim GPLv2 license even when they legally cannot use GPLv2.)
Or at least do #2
?
#26
in reply to:
↑ 25
;
follow-up:
↓ 27
@
13 years ago
Replying to mikeschinkel:
I'm pretty sure that Matt asserts that to be incorrect: http://wordpress.org/news/2009/07/themes-are-gpl-too/ (Matt please correct me if I misinterpreted.) My memory is that people have claimed stronger arguments for themes being GPL than for plugins so this requirement for plugins to only be GPLv2 and themes being able to be GPLv3 is a bit inconsistent.
I agree. Therefore the correct action would be to eliminate all GPLv3 code from the themes repository and enforce the GPLv2-compatible licensing there as well.
However, rather than discuss abstract scenarios can we discuss specific use-cases as to why this becomes a real issue?
You can discuss them all you like, but here's the thing: You are not required to have your code in the WordPress.org repository. If the requirements are suitable for you and your code, then don't put it in the repository. Release it on your own website instead.
"Google's Official APIs Client Library for PHP" is licensed by Apache 2.0. And I'm pretty sure we'd consider Google's API to be less than insignificant in the world of web infrastructure.
Having used Google's code, and then reimplemented it without their library, I can say that being unable to use their libraries is truly the greatest gift to programmers everywhere.
I'd rather poke my own eyes out with a dull stick than try to use Google's libraries ever again. Seriously, awful.
I'm as close to 100% sure as I can be that your statement does not apply to Google's desire related to their Official APIs Client Library for PHP. Instead Google was almost certainly and ironically attempting to provide as much flexibility in use of their APIs as possible.
And yet they used an incompatible license. Ain't that a B?
I would suggest to Google that perhaps using a strongly restrictive license such as "Apache 2.0" might not be the best way to get their libraries widely used in other projects.
Of course, I don't know. Maybe that is their goal? Who can say for certain. Regardless, I wouldn't use their library code because of the restrictions the Apache 2.0 license places upon me as a developer.
3.) Remove existing plugins that use non-GPLv2 compatible licenses from the repository and ignore Google and other vendor's Apache 2.0 licenses and anyone who might need to use one of them.
We do this already. We do this *daily*, when we find plugins that have incompatible licensing.
This really isn't a new situation, by any means.
If you find a non-GPLv2-compatible plugin, then tell us, and it *will* be de-listed from the repository. The authors will be emailed and asked to fix it. If they do so, then it will be re-listed.
#27
in reply to:
↑ 26
;
follow-up:
↓ 28
@
13 years ago
Replying to Otto42:
I'm as close to 100% sure as I can be that your statement does not apply to Google's desire related to their Official APIs Client Library for PHP. Instead Google was almost certainly and ironically attempting to provide as much flexibility in use of their APIs as possible.
And yet they used an incompatible license. Ain't that a B?
Not incompatible with GPLv3.
I would suggest to Google that perhaps using a strongly restrictive license such as "Apache 2.0" might not be the best way to get their libraries widely used in other projects.
Restrictive? Apache 2.0 has fewer ''requirements'' of users than GPLv2; not sure how you see it as more restrictive than GPL. Maybe it's different restrictions, but certainly one is not objectively less restrictive than another.
Of course, I don't know. Maybe that is their goal? Who can say for certain. Regardless, I wouldn't use their library code because of the restrictions the Apache 2.0 license places upon me as a developer.
What restrictions would those be, specifically?
And is this about the WordPress plugin repository policies, or about Otto's personal preference? Or are they one and the same? If not, would you support a policy that you strongly dislike if it were in the best interest of the WordPress community at large, or fight for your preference? This is a serious rhetorical question.
3.) Remove existing plugins that use non-GPLv2 compatible licenses from the repository and ignore Google and other vendor's Apache 2.0 licenses and anyone who might need to use one of them.
We do this already. We do this *daily*, when we find plugins that have incompatible licensing.
This really isn't a new situation, by any means.
If you find a non-GPLv2-compatible plugin, then tell us, and it *will* be de-listed from the repository. The authors will be emailed and asked to fix it. If they do so, then it will be re-listed.
Then @Rarst and I will be compiling a list of plugins for you to remove. We'll get it to you as soon as we've compiled it.
#28
in reply to:
↑ 27
;
follow-ups:
↓ 29
↓ 33
@
13 years ago
Replying to mikeschinkel:
Not incompatible with GPLv3.
Which has it's own problems as well. IMO.
Restrictive? Apache 2.0 has fewer ''requirements'' of users than GPLv2; not sure how you see it as more restrictive than GPL. Maybe it's different restrictions, but certainly one is not objectively less restrictive than another.
What restrictions would those be, specifically?
In Apache 2.0 specifically, I object to the patent rights clause. While I do believe that software patents are evil/wrong/bad, I think that this is a political issue. I dislike the notion of having code I write or contribute to using its license as a means of pushing political ideology. More to the point, I think that this discourages innovation. I write and release code with the GPLv2 so that it can be used to benefit all parties. Adding terms like these discourage use of that code by parties which may have related patents. Requiring them to blanket grant the necessary rights doesn't benefit them, and if they use an alternate set of code then it doesn't benefit me either.
JMO, of course.
And is this about the WordPress plugin repository policies, or about Otto's personal preference?
I'm only arguing what I think and explaining how we currently handle things. If you want a change in policy decisions, then you're chatting with the wrong person.
Or are they one and the same? If not, would you support a policy that you strongly dislike if it were in the best interest of the WordPress community at large, or fight for your preference? This is a serious rhetorical question.
I do not currently believe that it is in the best interest of the community to allow non-GPLv2 compatible code into the repositories. I think that the GPLv3 and Apache 2.0 licenses are "less free", for the definition of "free" that applies to me specifically. I will not use this code myself because I object to the licensing.
Then @Rarst and I will be compiling a list of plugins for you to remove. We'll get it to you as soon as we've compiled it.
Fine with me. Sending me a text listing of the slugs-only would be the most helpful. I'm happy to send the affected authors an email to attempt to get them to change.
#29
in reply to:
↑ 28
@
13 years ago
Replying to Otto42:
In Apache 2.0 specifically, I object to the patent rights clause.
Fair point, but I think they were being pragmatists instead of ideologues. My understanding is that the goal wasn't to enable patents so much but rather explicitly recognize the reality of patents and to minimize their impact by the license termination upon lawsuit.
I know we rarely agree on anything, but I really do not see how Apache 2.0 is anything but positive regarding patents.
And is this about the WordPress plugin repository policies, or about Otto's personal preference?
I'm only arguing what I think and explaining how we currently handle things. If you want a change in policy decisions, then you're chatting with the wrong person.
The reality is that any discussion on trac that involves selected topics will always require chatting with you. Just sayin...
Then @Rarst and I will be compiling a list of plugins for you to remove. We'll get it to you as soon as we've compiled it.
Fine with me. Sending me a text listing of the slugs-only would be the most helpful. I'm happy to send the affected authors an email to attempt to get them to change.
We'll post the slugs to this ticket along with a note for each explaining what inclusion is infringing and which license they are using (assuming it's easy enough to pull that information with a script.)
#30
@
13 years ago
I have a question about GPLv2 compatibility as license choice for easy core integration.
Core is licensed under GPLv2+. This means it can be combined with GPLv3 if result is put under GPLv3.
But doesn't this also mean that if it is combined with GPLv2 code (without "or later" clause) then result must be under GPLv2 and cannot be under GPLv2+, since introducing GPLv2 strict code kills GPLv3 compatibility?
#31
follow-up:
↓ 32
@
13 years ago
@mikeschinkel - Thank you for the clarification. You're right :) Dual is not okay, I was wrong!
@Rarst - Perhaps this analogy will help: I can use v2 software on a v3 server, but not v3 software on a v2 server. The license is forward compatible, but not backwards.
Per this: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility you can go from GPLv2 to GPLv3 because you're permitted to go from GPLv2 to GPLv2 or later without issues.
You must follow the terms of GPLv2 when incorporating the code in this case. You cannot take advantage of terms in later versions of the GPL.
So as long as you don't violate GPLv2, you can use the code in GPLv3.
This is why people get headaches.
#32
in reply to:
↑ 31
@
13 years ago
Replying to Ipstenu:
Per this: http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility you can go from GPLv2 to GPLv3 because you're permitted to go from GPLv2 to GPLv2 or later without issues.
Thanks, missed that mattrix... Note that there is following footnote for incorporating GPLv2 code in GPLv2+ project (emphasis mine):
While you may release your project (either your original work and/or work that you received and modified) under GPLv2-or-later in this case, note that the other code you're using must remain under GPLv2 only. As long as your project depends on that code, you won't be able to upgrade the license of your project to GPLv3-or-later, and the work as a whole (any combination of both your project and the other code) can only be conveyed under the terms of GPLv2.
So you cannot use GPLv2 strict code and call combined work GPLv2+. In my opinion this completely kills the idea that GPLv2 is effortless to assimilate by core.
As I see it right now - the only GPL versions, that are effortless to combine with GPLv2+, are unversioned GPL or GPLv2+. Or any license that is compatible with all GPL versions, not just v2.
#33
in reply to:
↑ 28
;
follow-up:
↓ 52
@
13 years ago
Replying to Otto42:
Then @Rarst and I will be compiling a list of plugins for you to remove. We'll get it to you as soon as we've compiled it.
Fine with me. Sending me a text listing of the slugs-only would be the most helpful. I'm happy to send the affected authors an email to attempt to get them to change.
There are 663 plugins currently in the WordPress.org plugin repository that are somehow using a license that is violating GPLv2. I've included the list of slugs below.
You can find more detail in this Google Spreadsheet about how each of these plugins are violating, including a list of those plugins with incompatible license in header and those plugins that include embedded Apache 2.0 licensed libraries.
#34
follow-up:
↓ 35
@
13 years ago
You can find more detail in this Google Spreadsheet about how each of these plugins are violating, including a list of those plugins with incompatible license in header and those plugins that include embedded Apache 2.0 licensed libraries.
I edited out the long list Mike posted in his previous comment to keep this thread down. You can see the original list here or click through to his spreadsheet.
#35
in reply to:
↑ 34
;
follow-up:
↓ 36
@
13 years ago
Replying to nacin:
I edited out the long list Mike posted in his previous comment to keep this thread down. You can see the original list here or click through to his spreadsheet.
The point of the long list was so that people not paying very close attention would recognize the magnitude of the problem.
Just sayin...
#36
in reply to:
↑ 35
;
follow-up:
↓ 39
@
13 years ago
Replying to mikeschinkel:
The point of the long list was so that people not paying very close attention would recognize the magnitude of the problem.
Just sayin...
I understand.
The core team plans to discuss plugin directory licensing once none of us are sick or traveling. So, expect an update here in the next week or so.
The arguments have been laid out, so no need to continue to do so. Not trying to stifle discussion, but, you have all made your points.
#39
in reply to:
↑ 36
@
13 years ago
Replying to nacin:
The core team plans to discuss plugin directory licensing once none of us are sick or traveling. So, expect an update here in the next week or so.
The arguments have been laid out, so no need to continue to do so. Not trying to stifle discussion, but, you have all made your points.
Much appreciated. I can definitely relate to the "sick or traveling" concern. :)
#40
@
13 years ago
- Cc travis@… added
While licensing, etc., is not a joke, should be heavily considered, and a stance taken with its reasons, I do hope that along with the stance there is a known and published process of steps taken against violations (for violators and those who wish to report violators) along with a FAQ (e.g., Will my slug be reserved until I am able to change my licensing? Is there a probation period (even just a day) where I have the opportunity to change my license before any action (delisting, removal, etc.) is taken (with explanation)? etc.) and an appeal process (for re-listing/re-instating) that is quick and painless.
I say this because I know a few plugin authors who have created plugins using GPLv3 (purely accidentally) because:
(1) they 'knew' that WP requires plugins to be GPL (but didn't know the specifics for whatever reason),
(2) they may have also seen that WP requires a "GPLv2 or later" statement and have confused that statement to mean that GPLv3 is ok,
(3) they have copied the licensing of another plugin, which just happened to be a GPLv3 licensed plugin,
(4) they were given mis-information by another plugin developer who is also in violation unbeknown to them,
(5) they were a theme author who knew GPLv3 was ok there and didn't know that it wasn't ok for plugins in the WP Repo.
A newer plugin author or someone, who frankly doesn't care about licensing (because they don't care to know or it's too problematic), will make their GPLv3 without thinking (or thinking that the latest version is the best or for whatever reason). When I have mentioned this to a few authors I knew, they immediately changed the license of their plugin without a flinch or thinking twice. Since WP has such a good community that helps one another, I hope that WP would consider publishing a solid process to remove plugins and to have plugins re-instated so that plugins can quickly be re-instated without too much of a hiccup.
Nevertheless, there are some authors who won't budge on the licensing thing, which is perfectly fine and their prerogative. And if WP only wants to support a GPLv2 or later approach, that is perfectly fine (and their prerogative) as well. However, having a policy and not enforcing it is tragic and creates a de facto policy. Authors who know and have been notified (or attempted to be notified) and do not wish to comply even after a warning, etc., should be removed, if that's the policy. Just something to consider...
#42
follow-up:
↓ 43
@
13 years ago
Hey, whad'ya know, my Front-end Editor plugin can be added to Mike's spreadsheet, since it bundles Aloha Editor. Aloha Editor is licensed under the AGPL, which is compatible with GPL3, but not with GPL2.
#43
in reply to:
↑ 42
@
13 years ago
Replying to scribu:
Hey, whad'ya know, my Front-end Editor plugin can be added to Mike's spreadsheet, since it bundles Aloha Editor. Aloha Editor is licensed under the AGPL, which is compatible with GPL3, but not with GPL2.
AGPL might be one of the most problematic licenses that currently can be encountered in repository, because of much stronger demand for source disclosure. If developer installs your plugin and does small tweak on Aloha - suddenly that developer is on the hook for being obliged to proactively release that modified source.
Also it's not compatible with GPLv3 in a sense that you can move code between them, but in a sense that you can distribute combined work while parts will retain GPLv3 and AGPLv3 license respectively.
And one more point I want to bring up for consideration. Currently less than fourth of plugins I scanned has explicit License: declaration in header. I was surprised to see that line only very loosely mentioned in Codex. Lack of standard and enforced indication of plugin's license and in turn lack of ability to display it in all repository interfaces (wordpress.org site, WP admin interface) makes simple action of installing plugin from repository a licensing gambling.
I want to suggest that indication of license in header (or in other human and code accessible way) is considered to be enforced. That would at the very least make situation easier to audit both for wordpress.org and third parties.
#44
@
13 years ago
A moratorium is in place until the core team reviews and updates the guidelines. Plugins that violate the current guideline but are compatible with GPLv3 will not be de-listed. As I said earlier, you all made your (very valid) points, so there's no reason to suggest we're about to, say, purge 500 plugins from the repo or something along those lines.
I want to suggest that indication of license in header (or in other human and code accessible way) is considered to be enforced.
I agree.
Will my slug be reserved until I am able to change my licensing?
Yes. (Slugs are never reused.)
Is there a probation period (even just a day) where I have the opportunity to change my license before any action (delisting, removal, etc.) is taken (with explanation)? etc.
Yes. The author is given a chance to respond to the notification.
and an appeal process (for re-listing/re-instating) that is quick and painless.
Yes. Replying to a notification is enough to be off the hook.
#45
follow-up:
↓ 46
@
13 years ago
The prohibition on Apache/GPLv3 extend to the JavaScript libraries as per policy? I can't imagine it's a concern that a core developer may read non GPLv2 code from a JavaScript library marked with a GPLv2 incompatible license (but GPLv2 compatible license) and contaminate core with that JavaScript. Perhaps the prohibition should be that the non-library PHP code in the plugin should be "GPLv2" but the plugin as a whole can be "GPL compatible"? (I mean the concern is php code reuse right?)
Is there a Matrix of sorts (like http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ) that allows "GPLv2 or later" to contain "GPLv2 only" or "GPLv2 or later" PHP code, while using "GPLv2 or later," "GPLv3," or "Apache 2.0" licensed libraries? (I can't figure it out.)
I've would have to move my plugin to a "GPL3" or "GPLv3 or later" license if it's not valid to license the combined package of the "GPLv2" and "GPLv2 or later" PHP code with JavaScript libraries (licensed as "MIT" and "Apache 2.0") as a "GPLv2 or later" plugin. Up til now I've believed that I've licensed it correctly. (The addition of the Apache 2 licensed library is very recent.)
Judging from this ticket tho, I may have to hire a lawyer, remove the library, or switch to GPLv3 and stop hosting it on wordpress.org (which would suck).
(Alternatively, I could write the plugin in a way that remotely pulls in and possibly caches the less.js library so that it's external and doesn't impact licensing, but that's a hoop and a half ain't it...)
On a related note, I've spend many hours looking for tutorials on how to properly mark and license code all with no luck. Specifically, I'd like to know how to mark the php classes and functions that I've written from scratch as copyrighted and licensed one way, and the code I've borrowed from core as marked as appropriate, and a combined plugin copyright and license markup. I've not found any tutorials anywhere for this.
Why's this stuff gotta be so hard. Also, you shouldn't rely on the license header line (or any other self declaration) being correct as coders barely understand what to put there.
#46
in reply to:
↑ 45
;
follow-up:
↓ 47
@
13 years ago
Replying to WraithKenny:
The prohibition on Apache/GPLv3 extend to the JavaScript libraries as per policy?
Yes, currently it does. This ticket was initially raised exactly after discussing making use of JS library under Apache License (see link at top of thread).
Is there a Matrix of sorts (like http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ) that allows "GPLv2 or later" to contain "GPLv2 only" or "GPLv2 or later" PHP code, while using "GPLv2 or later," "GPLv3," or "Apache 2.0" licensed libraries? (I can't figure it out.)
You can combine Apache License 2.0 with GPLv3 so think of it as GPLv3 in context of that matrix. And combining GPL versions is pretty thoroughly covered there.
(Alternatively, I could write the plugin in a way that remotely pulls in and possibly caches the less.js library so that it's external and doesn't impact licensing, but that's a hoop and a half ain't it...)
Note that repository rules say that "All images and scripts shown should be part of the plugin". I think this is rule even more obscure and less policed than license one, but still it there and trying to fetch things from elsewhere is technically breaking it.
#47
in reply to:
↑ 46
@
13 years ago
Replying to Rarst:
Note that repository rules say that "All images and scripts shown should be part of the plugin". I think this is rule even more obscure and less policed than license one, but still it there and trying to fetch things from elsewhere is technically breaking it.
We actually try to enforce that one very strictly. Pulling JS code from another site is a no-no because it's a security issue.
We do make exceptions for the brain-dead obvious stuff. A Facebook plugin can use JS code from Facebook servers. A Twitter plugin can use JS code from Twitter servers. That sort of obviousness is okay.
What isn't okay is when a plugin includes JS code from some random server we've never heard of, or a server which is tied back to the plugin author, and there's seemingly no reason for doing so, or there's no reason that the code couldn't be included in the plugin itself. This is basically an attempt to do an end run around our spot checking for security issues, since the author can change the JS on the fly and compromise any sites running said plugin.
#48
in reply to:
↑ 5
@
13 years ago
"We're already in the situation where some plugin directory code is GPLv2-only instead of GPLv2+, so combining that plugin code with WordPress already requires care." ~ Mark Jaquith
This (the difficulty in integrating code) is the same case made against allowing GPLv3 code in the repos. For consistency sake, should we change the policy to disallow GPLv2-only plugins (or any containing GPLv2-only code) and purge those from the repos? (Rhetorical; I don't seriously suggest this.)
OK, so a break down of the concerns are:
"I would also hate for me to pick up code or an idea from a plugin that is licensed in an incompatible way and then end up using that in core, thereby doing quite a bit of damage." ~ Nacin
and
"It makes integrating code/idea from plugins into core impossible if the plugin is GPLv3." ~ Otto
First, copyright doesn't apply to ideas (that's in the realm of patents), only copy (text, writing, code implementations etc). Having an idea inspired by GPLv3 code doesn't bar you from implementing that idea in GPLv2+ code.
Next, "integrating" the code is problematic in that you can't wholesale copy the code in - that's correct, but you can re-implement the idea, which is usually what happens eventually anyway. (You can copy it though if the implementation is short and obvious; see below.) So it's merely less convenient perhaps.
Lastly, you don't have to be concerned with incidentally or accidentally copying short or obvious code (such as $var = '';
or maybe even longer codes) as short or obvious copy (subjective, I know) isn't copyright-able (or even patent-able).
Basically, and in summary, your not going to "accidentally" remember enough of the code to re-implement it as originally "expressed" as to trigger the copyright. The only way to "infect" core with GPLv3 code is to copy it in on purpose.
"Copyright does not protect facts, ideas, systems, or methods of operation, although it may protect the way these things are expressed." ~ http://www.copyright.gov/help/faq/faq-protect.html
The other concern is:
"Some people will not use or work on GPLv3 code. It's incompatible with too many things. " ~ Otto
WordPress Core's code will still be GPLv2+ and those people can still work on it. The code in the plugins doesn't change this. Most plugins are also GPLv2+ and those people still can work on those plugins and incorporate them into their projects. No one is required to incorporate any plugin code into their own work if they don't want; it's all optional and voluntary.
Now for the Pros: We can use libraries in our plugins that we can't under GPLv2 licenses and we avoid an unnecessary and somewhat arbitrary limitation on developer and user freedoms.
This concludes my argument in favor of officially allowing GPLv3 plugins.
#49
@
13 years ago
The rule that plugins cannot dial home for images is a major obstacle - and saying that exceptions will be made to domains the WP Devs know is just not acceptable. How is a plugin developer supposed to know what URLs a WP Dev knows and which they don't?
I wish to develop a plugin to display ancient Egyptian hieroglyphs. I will probably release a lite one soon - about 10Mb. That covers the core 700 glyphs.
Now I would like to release one that covers the 10,000 plus glyphs and add multiple "font faces" (to use the modern equivalent). I estimate a full plugin would be 200Mb if it contained all the images.
So the sensible thing would be for it to dial home (on a subscription basis like Akismet to cover hosting charges) to access the precise images needed for the page. I can then ship a compact plugin of under 1Mb. GPLv2 isn't an issue - everything is GPLv2. The problem is the Repo rules.
So in order to meet Repo rules I will need to publish a massively bloated 200Mb plugin instead of one which is under 1Mb. That is impractical.
Plugins need to be able to dial home for images.
#50
@
13 years ago
@KatePhiz: You forgot the second part of that paragraph:
If the plugin does require that data is loaded from an external site (such as blocklists) this should be made clear in the plugin's admin screens or description. The point is that the user must be informed of what information is being sent where.
So it's ok if you load images from an external source, as long as you let users know.
#51
@
13 years ago
@KatePhiz: It's important that the user be aware of the fact that they are a) sending potentially tracked information back to the author of the plugin and b) adding a dependency into their site of another site. The user of the plugin must be made aware of these facts in advance.
As long as the user is made aware of what's going on and has the chance to opt-out or not use the plugin if they disagree with the method of operation, then you can do pretty much whatever. The point, really, is full disclosure.
For your specific case, instead of hotlinking images as you suggest, I'd write the plugin such that the user could select whatever glyphs/fonts they need to download from your site, and have the plugin then go get that image and save it where it was needed, then access it locally. This would prevent the need for insane hosting charges on your end, since presumably they'd only download the required images once, and it would give the user the option to choose what bits they need, and it would also easily explain to the user that they're downloading the needed images from wherever they're downloading them from.
#52
in reply to:
↑ 33
@
13 years ago
Policy here, policy there.
Code has been taken into trunk already that is not licensing conform if it had been asked upfront what the policy of the original author(s) was (no need to drop names here, core had a similar issue and we solved it in the end, so I leave that same space as well for others).
And this is more a policy thing than licensing itself. I therefore suggest to not enforce more than needed. The only "real" problem I see is that core contributors must respect the license if they pick code from a plugin or elsewhere - which is necessary any way. And if you take a look into the past - how often does it happen that plugin code goes into trunk? And more interestingly, when did that result into a licensing issue for trunk that could not be resolved in the end?
And that's equally true for GPL-2.0
plugin code (which was said earlier that this license should have had been enforced) - which would be technically incompatible with WordPress core now (for the matter of incorporating into core and distribution then (as discussed) and which probably was the original point highlighted by scribu with this ticket).
So probably leave the code the air to breath it needs to live. And the coders as well. Consider that we discuss free software here, and I don't see a reason to limit our users right to use a a GPL-2.0
plugin. Or a GPL-3.0
plugin. Or a Apache-2.0
plugin. Or a BSD-3-Clause
plugin. Maybe something sound like the OSI approved licenses would be some guideline users are able to follow more easily. If not, make clear what you want and for what reason, so users who think about contributing their work to the plugin repository know what this is about. Maybe the most important part.
Related: #13067 - if software repositories are configurable, different opinions in the communities won't be an issue that much. Even if not imaginable first-hand, this can be a chance to improve the policy and guidelines for wordpress.org repository. If you consider to review the policy, please review that feature request as well.
@mikeschinkel:
If you're looking for identifiers for license names and versions, you might be interested in the SPDX Open Source License Registry. For reviewing licensing of code, I found Fossology useful but you need to budget some time for setup and then for the actual review. I've never run it across the plugin repository myself.
#53
@
13 years ago
- Resolution set to fixed
- Status changed from new to closed
The guideline now reads as follows:
Your plugin must be compatible with the GNU General Public License v2, or any later version. We strongly recommend using the same license as WordPress — “GPLv2 or later.”
For more, see http://wpdevel.wordpress.com/2012/04/30/the-plugin-directorys-licensing-guidelines-have-been-updated/.
Closing as fixed.
Context:
http://wordpress.stackexchange.com/questions/12488/hosting-plugin-with-excanvas-dependency-of-flot-jqplot-and-more-in-official-re/12490