[theme-reviewers] GPL and limiting usage

[Emil Uzelac]

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
acceptable.


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>