[wp-trac] [WordPress Trac] #16898: Fix plugins about page license requirement

[WordPress Trac]

#16898: Fix plugins about page license requirement
--------------------------------+----------------------------
 Reporter:  scribu              |       Owner:
     Type:  feature request     |      Status:  new
 Priority:  normal              |   Milestone:  WordPress.org
Component:  WordPress.org site  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:                      |
--------------------------------+----------------------------
Changes (by mikeschinkel):

 * cc: mikeschinkel@… (added)


Comment:

 Replying to [comment:17 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 [comment:23 Otto42]:
 > There are only a few restrictions
 > 1. 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?

 "**[http://code.google.com/p/google-api-php-client/ 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 [comment:23 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
 [http://www.ipinfoblog.com/archives/intellectual-property-inducing-
 copyright-infringement.html 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`?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/16898#comment:25>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software