[theme-reviewers] Spammy theme?

Tue Jul 26 01:20:47 UTC 2011

The idea of "adoption" is for the benefit of *end users*, who would have a
seamless upgrade experience from the old version of the previously abandoned
Theme, to the updated version post-adoption.

The GPL poses no issues or problems whatsoever with "adoption"; if anything,
the GPL actually facilitates the concept, because it permits modification
and redistribution of the code. Bear in mind: the GPL deals with
*copyright*, not *trademark*. The Theme upgrade process deals only with
Theme name/slug, and as such would be a *trademark* question rather than a
*copyright* question.

But I wholeheartedly agree that if the original developer indicates that he
does not want the Theme to be "adopted", then as the trademark owner, that
decision should be respected.

Themes can be forked right now; no changes needed. While I'm all in favor of
making a transition as easy as possible, whatever changes that could be made
to the infrastructure in order to tie the *fork* to the *original*, none of
those changes would benefit those who need it most: i.e. those who are using
the *original* version of the obsolete Theme.

Properly attributed Themes - both originals and forks - wouldn't need any
additional header tags in order to indicate the original:fork relationship,
because that relationship would be indicated clearly by the
copyright/attribution notice.

Chip

On Mon, Jul 25, 2011 at 8:08 PM, Darren Slatten <darrenslatten at gmail.com>wrote:

> Theme adoption seems like it could raise issues with the GPL, regarding the
> need to clearly distinguish between original code and post-adoption code.
> I'm guessing not too many Theme developers would appreciate having their
> name/attribution diluted by the adoption process. Perhaps a better solution
> would be to allow "forking" a Theme. Details and benefits would be something
> like this:
>
>
>    - Add a new style.css key/value pair to define a "Fork of:
>    {$retired_theme_name}" relationship.
>    - A retired Theme would keep its own attribution and statistics data.
>    - New Theme would be named something different and effectively treated
>    as an independent Theme (i.e., a retired Theme could be forked by more than
>    one developer).
>    - The "Fork of:" data could be used to trigger a separate kind of
>    update notice--one that makes the distinction between a simple update and a
>    "Under New Management!" update.
>    - Retired Themes could still be resumed by original authors, even if
>    the Theme has been dormant for awhile (and forked in that time).
>    - WordPress.org could provide aggregate statistics on original+fork
>    downloads.
>    - Themes could be forked whether they're retired or not.
>    - Users could get a better understanding of how a certain Theme will
>    function (e.g., I'd rather download a Twenty Eleven fork than a Classic
>    fork).
>    - Users could filter their Theme search by origin.
>
>
> Just throwing some ideas out here...
>
>
>
>
> On Mon, Jul 25, 2011 at 6:45 PM, Vicky Arulsingam <
> vicky.arulsingam at gmail.com> wrote:
>
>> I like this idea a lot, especially allowing other developers to adopt
>> a theme and bring it up to WP standards.
>>
>> Should the original theme author be contacted about their outdated
>> theme or is it considered forfeit especially since a theme hasn't been
>> updated in 2 years
>>
>> On 7/26/11, Edward Caissie <edward.caissie at gmail.com> wrote:
>> > The basic premise I have always tried to champion is moving the "older"
>> > themes into a secondary repository so they are not lost but are
>> obviously
>> > shown as "out-of-date"
>> >
>> > There are many older themes that can be easily brought up to current
>> > standards but the original author's are no longer interested in updating
>> > and/or involved with WordPress.
>> >
>> > I would like to see these themes simply moved, then after another
>> arbitrary
>> > time limit made available to be adopted by a new author. I have put
>> forward
>> > this idea at least once before and still see it as having a great deal
>> of
>> > potential (aside from all necessary changes to the repository to make it
>> > work).
>> >
>> >
>> > Cais.
>> >
>> >
>> > On Mon, Jul 25, 2011 at 4:15 PM, Claude Needham <gxxaxx at gmail.com>
>> wrote:
>> >
>> >> On Mon, Jul 25, 2011 at 1:11 PM, Angelo Bertolli
>> >> <angelo.bertolli at gmail.com> wrote:
>> >> > Why not just have a "works with version X" selection for users like
>> on
>> >> > the plugin side?  Then the users could decide what was working, and
>> >> > things could be pruned accordingly.
>> >> >
>> >> If a theme seriously does not work with the current version of
>> >> wordpress, it should be retired.
>> >> I am assuming that we are trying to encourage people to work with the
>> >> latest release that they can.
>> >>
>> >> I have been in situations where a plugin that I relied upon had not
>> >> been updated yet. (A shopping cart).
>> >> But if I need an old obsolete theme -- I probably already have it
>> >> installed on my site.
>> >>
>> >> If I am theme hunting, it would be very disappointing to dl a theme
>> >> from wporg that is obsolete under the most current core.
>> >>
>> >> Just my thoughts,
>> >> Claude Needham
>> >> _______________________________________________
>> >> theme-reviewers mailing list
>> >> theme-reviewers at lists.wordpress.org
>> >> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>> >>
>> >
>>
>>
>> --
>> -----
>> Vicky Arulsingam
>> _______________________________________________
>> theme-reviewers mailing list
>> theme-reviewers at lists.wordpress.org
>> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>>
>
>
>
> --
> Darren Slatten
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20110725/0472f515/attachment.htm>