[theme-reviewers] GPL and limiting usage

Emil Uzelac emil at uzelac.me
Fri Sep 20 20:21:36 UTC 2013

So all this comes down to what we were saying in this discussion all along
or at least from the second Theme submission, that there are no GPL issues.

Am I wrong Justin?

If so we already touched the policy and noted that this should be

On Fri, Sep 20, 2013 at 3:14 PM, Justin Tadlock <justin at justintadlock.com>wrote:

> The issue here is really all about whether a theme can block features/code
> bundled within the theme itself without a paid subscription.  It's not
> connecting to an API to use a service (like Akismet).  It's connecting to
> an API to determine whether particular code in the theme will run based on
> nothing more than a payment.
> For a simple example, this code in `footer.php`:
>     <?php if(!pl_is_pro()):?>
>         <a class="pl-credit" href="http://www.pagelines.**com/<http://www.pagelines.com/>"
> title="Built with PageLines DMS [basic]" target="_blank" style="display:
> block !important; visibility: visible !important; opacity: 1 !important;">
>             <i class="icon-pagelines pl-transit"></i> <span
> class="fademein">DMS</span>
>         </a>
>     <?php endif; ?>
> I'm sure most of you can understand it, but I'll break it down:
> * A footer link is displayed if you do not have a subscription to their
> pro service.
> * The inline style rules break our guidelines on inline style rules.
> * The inline style rules seem to be there solely to make it hard for users
> to hide this via CSS.
> Obviously, anyone can remove that if they know where to look and a little
> bit about code.  But, the lengths in which the theme author has gone to
> block users from removing a footer credit wouldn't be allowed in any other
> theme.
> I haven't had a chance to fully look over the code, but I'm guessing based
> on the comments so far, that this is just one of many similar restrictions.
>  It seems the gist of everyone's concern is about actual restriction within
> the theme code that's being put on WordPress.org.
> Let's all assume that there's no GPL issues.  The question then becomes
> whether this violates WordPress.org policy and/or theme review policy.
> So, let's talk policy.
> Assuming I understand the issues clearly, let me present another example
> that's not tied to the theme in question.
> Suppose in the next theme I upload to WordPress.org, I decided to create
> some color and layout options for the theme customizer.  This code would,
> obviously, be within the theme.  However, anyone who downloads this theme
> from WordPress.org would not be allowed to use my theme customizer options
> out of the box.  They'd need to purchase an API key for this feature to
> become unlocked.  Of course, anyone who knows a little PHP can go in and
> change the code so that it works without an API key.
> From what I've gathered from this discussion, that example is no different
> (please do correct me if I'm wrong).  I'm not sure if that necessarily
> breaks the GPL (probably not).  It's more a matter of policy -- whether
> this is something that we should allow on the WordPress.org theme
> repository.
> I apologize if I'm misunderstanding anything that's happening with the
> code and hope I didn't misrepresent the situation.  I'll be sure to give it
> a better look when I get a chance.
> On 9/20/2013 2:50 PM, Otto wrote:
>> On Fri, Sep 20, 2013 at 2:40 PM, Bryan Hadaway <bhadaway at gmail.com>
>> wrote:
>>> Because, I'm going to bang on pots and pans until you actually
>>> acknowledge
>>> that the horse ever even existed. The issue isn't contained within the
>>> walls
>>> of the theme's code, it's a licensing issue that has not changed just
>>> because a new version of the theme was uploaded.
>> In my view, the issue existed in the theme, up until they moved the
>> problem code to a plugin on their own site. And I'm kind of okay with
>> that.
>> So as far as I'm concerned, the issue is not an issue anymore.
>> Now, as I see it, you're wanting to create a whole new issue, one
>> where now we impose even more strict guidelines on theme authors. As
>> near as I can tell, you essentially want the theme review team to say
>> that subscription models are unacceptable. Well, call me crazy, but I
>> don't think that's a really good idea.
>> If you want to fine-pick the nitty gritty details and go "oh-noes
>> they're selling code that actually checks for subscriptions", well I'm
>> going to say that checking for subscriptions really doesn't bother me
>> too awful much, as long as the code to do so ain't on WordPress.org.
>> So yeah. That's my viewpoint. I don't much care whether they have a
>> subscription model or not for their own code that is being sold from
>> their own site. My 2 cents.
>> -Otto
>> ______________________________**_________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.**wordpress.org<theme-reviewers at lists.wordpress.org>
>> http://lists.wordpress.org/**mailman/listinfo/theme-**reviewers<http://lists.wordpress.org/mailman/listinfo/theme-reviewers>
> ______________________________**_________________
> theme-reviewers mailing list
> theme-reviewers at lists.**wordpress.org<theme-reviewers at lists.wordpress.org>
> http://lists.wordpress.org/**mailman/listinfo/theme-**reviewers<http://lists.wordpress.org/mailman/listinfo/theme-reviewers>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20130920/b9ccb32a/attachment.html>

More information about the theme-reviewers mailing list