GPL group recommends CMS templates be licensed under a different license.

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

... but templates are a special case, because they are combined with data provided by users of the application and the combination is distributed. So, we recommend that you license your templates under simple permissive terms.
_ --- "Frequently Asked Questions about the GNU Licenses" www.gnu.org

As I mentioned in my post "Themes versus Modules" there are I believe valid reasons and means to support allowing Themes to be excluded from the automatic GPL "infection" currently required by Drupal. On this page I hope to be able to formulate a specific question that can be asked of the lawyers. I have included one to start but I leave it to the community to determine if it is ready to be asked or needs further refinement ...

I am a developer, not a designer, but I have been doing a LOT of reading on the issue of Drupal Themes and the GPL. The motivation for this research is based on the well-documented issue that Drupal is plagued by a persistent lack of high-quality Themes and from what I have read one of the apparent causes of this is the inability to build a viable commercial market for Drupal Themes as WordPress and Joomla have. Professional designers need to embrace Drupal and many would if they could commercialize their designs without their work being tainted by the GPL but that is not allowed under the current Drupal licensing rules because they contain Code.

High quality Drupal Themes are very little about code (even though they require some) and much more about image/design/art ... they are about the "look & feel" of a website and when properly implemented should be unconcerned with type of content or the ways in which that content is created. Yet as long as the Drupal community insists that Themes be treated the same as Code (aka Modules) the problem of building a strong and diverse Drupal Theme base will continue to relegate Drupal to 3rd Place behind Joomla and WordPress. An exception for the GPL needs to be made and I believe it can be made as I will outline below.

I want to say something about Modules here. Speaking as a developer with 25 years of work in the IT world I am greatly concerned about my intellectual property rights but even so I personally do NOT think that Drupal Modules should be granted the same exceptions as Themes. This would make it far too easy for proprietary modules to gradually siphon off the established code base and eventually shatter the open source nature of the Drupal developer community. I will not use this article to debate that view but I needed to express it so that this page can focus on the issue of allowing Themes to be excluded from the GPL.

Now one possible solution to this problem would be to write a proprietary template engine (for argument let us say it is written only in Ruby or Perl), a Drupal "bridge" or "wrapper" Module for interfacing with that engine, and then building new Themes for that engine thus bypassing the GPL taint. While such a solution is technically possible and legally sound (IMO - IANAL) it is far from desireable since it would add needless processing overhead to achieve the same results we already have. This is not a likely solution.

Another possible, and much more likely, solution may be found in a significant item I wish to add to this discussion, an item which comes from the FSF organization's own official GPL website, to wit:

I am writing a website maintenance system (called a “content management system” by some), or some other application which generates web pages from templates. What license should I use for those templates?

Templates are minor enough that it is not worth using copyleft to protect them. It is normally harmless to use copyleft on minor works, but templates are a special case, because they are combined with data provided by users of the application and the combination is distributed. So, we recommend that you license your templates under simple permissive terms.

Some templates make calls into Javascript functions. Since Javascript is often non-trivial, it is worth copylefting. Because the templates will be combined with user data, it's possible that template+user data+Javascript would be considered one work under copyright law. A line needs to be drawn between the Javascript (copylefted), and the user code (usually under incompatible terms).

What this FAQ basically says is that an exception to the GPL for Theme templates is very possible. So, here is a question for the lawyers:

GENERAL CONCEPT IN A NUTSHELL:
Can Drupal add a GPL exception clause for NEWLY CREATED Themes if that exception is NOT applied retroactively ?

SPECIFIC QUESTION:
Can a notice be posted on drupal.org by the Drupal Association to the effect of:

Effective MM/DD/2011 (hereinafter "Effective Date") any Drupal Theme package (templates & data) created on or after the Effective Date (as determined by the date of the first public distribution as an installable package) are eligible to use the following license exception to the GPL:

... (here the lawyers insert TBD exception language, see below) ...

All Drupal Themes created prior to the Effective Date are not eligible for this exception. Any Theme which is a derivative work of another Theme is subject to the licensing terms of that original Theme.

Nothing in this exception shall be construed as to prevent the creators and/or current copyright holders of any eligible Drupal Theme to permit said Theme to be voluntarily licensed under the standard GPL terms.

Now here is the example exception text from the GNU FAQ. This was just to cover templates with Javascript but the idea is there and this makes a good starting point:

As a special exception to the GPL, any HTML file which merely makes function calls to this code, and for that purpose includes it by reference shall be deemed a separate work for copyright law purposes. In addition, the copyright holders of this code give you permission to combine this code with free software libraries that are released under the GNU LGPL. You may copy and distribute such a system following the terms of the GNU GPL for this code and the LGPL for the libraries. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The final exception language, which would have to be worked out by the lawyers, ought to include language that covers the following provisions for all "eligible" (new) Themes:

  1. Themes may include HTML & CSS as well as similar "layout" coding.
  2. Themes may include programming code such as PHP, javascript, etc.
  3. Themes may include SWF, AS2, AS3 and similar "Flash" related files.
  4. Themes may include any kinds of image files such as JPG, GIF, PNG, etc.
  5. Themes may include any kinds of sound files such as WAV, MP3, OGG, etc.
  6. Themes may include any kinds of video files such as AVI, MP4, MOV, etc.
  7. Themes may include sub-themes and/or sub-templates.
  8. Theme source code is not subject to the GPL requirements/restrictions.
  9. Theme distribution is not subject to the GPL requirements/restrictions.
  10. Themes may include calls to Drupal base code, modules and libraries to access & format data requested by a Module.
  11. Themes may access any Drupal content or data in READ mode in order to present data requested by a Module.
  12. Themes may *not* CREATE, UPDATE or DELETE any Drupal content or data with the exception of the Theme's own "settings" variables.

ONE FINAL NOTE: I chose to post this topic as a wiki page rather than as a discussion page hoping that the language would evolve to the point that the lawyers could be asked a rational question. Nonetheless if it is possible to ask about the above "GENERAL CONCEPT IN A NUTSHELL" now that would be great.

Comments

Not feasible

Crell's picture

(I asked the admins to enable comments on this post.)

1) As I noted in the other thread in this group, the distinction between a module and theme is impossible to make in practice in the first place. Since they cannot be treated separately, they cannot have separate policies.

2) IF it were possible to make such a distinction, it would, technically, be possible to allow people to opt-into such an exemption. Assuming you're talking about themes downloaded from drupal.org, though, that would create an untennable situation. Rather than knowing "if you download it from Drupal's VCS repository it's GPLv2+, period, have a nice day", which is nice and simple, you'd have a policy of "if you download it from Drupal's VCS, it's probably GPLv2 but could be something else, but we're not sure what else, you'll have to check individually and see. In some cases that means you cannot actually use the them. Sorry. Have a nice day." That is not a policy we are interested in supporting.

3) IF it were possible to make that distinction, and IF it weren't prohibitively confusing to have a mix-and-match policy, your initial supposition is, I believe, incorrect. You state that the reason there is a smaller Drupal commercial theme market than WP or Joomla is the GPL "infection" (your word) on themes. The obvious misplaced negative connotations aside, I do not believe that to be the primary reason.

The primary reason that Drupal themes have a smaller market is that they are harder to build, and harder to build generically. Drupal is substantially more flexible than WP or Joomla, and therefore a theme that is not site-specific will be harder to build in the first place. There are a lot of really good Drupal themes made, but they're site-specific and the L&F (the art design, which as you said is the valuable part) is proprietary to the client. Generic Drupal themes that don't look like Drupal are extremely hard to do for technical reasons, not legal ones.

I also do not believe that actively encouraging the commoditization of code is in the interests of the Drupal community or the principles of Free Software.

Even still, commercial theme companies like TNT still exist and are still quite viable.

Thus I believe your intent here is not one that can be supported, nor is your method logistically viable.

I appreciate what you are saying however...

Aveu's picture

I understand your points but I think there are some flaws/gaps in your logic. Let's discuss:

1) As I noted in the other thread in this group, the distinction between a module and theme is impossible to make in practice in the first place. Since they cannot be treated separately, they cannot have separate policies.

I replied about distinctions in the other thread as I think that conversation does not depend on this one even existing (but this conversation on the other hand is very dependent on that one coming to resolution or else this one is moot). In general terms though my response is: What is (or should be) and what is not considered a Theme can (by conscious choice) be defined via Best Practices much as many other things are here at the d.o -- isn't that really what "the Drupal Way" is, required best practices as determined by the community?

2) IF it were possible to make such a distinction, it would, technically, be possible to allow people to opt-into such an exemption. Assuming you're talking about themes downloaded from drupal.org, though, that would create an untennable situation. Rather than knowing "if you download it from Drupal's VCS repository it's GPLv2+, period, have a nice day", which is nice and simple, you'd have a policy of "if you download it from Drupal's VCS, it's probably GPLv2 but could be something else, but we're not sure what else, you'll have to check individually and see. In some cases that means you cannot actually use the them. Sorry. Have a nice day." That is not a policy we are interested in supporting.

The flaw in your logic is assuming that Themes would have to be maintained in the CVS (or at least the same CVS). I have read suggestions by others here to create some sort of "Themes Marketplace" section on the d.o separate from the rest of the site. This could easily be done via a subdomain hosted on a different server. The DA could even set up an ecommerce shopping cart portal for Themes and collect a small fee ($1) for each sale (excluding free themes sold for $0) to fund the hosting. Different site, different rules but still GPL.

People need to remember that the GPL actually SUPPORTS making money by selling original works as long as the "4 Freedoms" are kept intact.

3) IF it were possible to make that distinction, and IF it weren't prohibitively confusing to have a mix-and-match policy, your initial supposition is, I believe, incorrect. You state that the reason there is a smaller Drupal commercial theme market than WP or Joomla is the GPL "infection" (your word) on themes. The obvious misplaced negative connotations aside, I do not believe that to be the primary reason.

Sorry about the negative connotation, the words "viral" and "GPL" seem to be inescapably locked together even when the intent is only to be descriptive. I will try avoid such terms. As for your own choice of words I think phrases like "prohibitively confusing" and the many variations of "can not" and "do not" suggest that there is a fundamental difference between how we approach problems. This is not meant as a flame, just an observation. For me I see the possibility to do what the GPL says is OK, to make money with original works under the GPL. Your answers suggest that you only see what can't be done and what hasn't been tried yet. If you could perhaps suspend your doubts and play devil's advocate, ask "how?" instead of "why?" you might find there are ways to make this happen. I hope I do not offend with this observation.

The primary reason that Drupal themes have a smaller market is that they are harder to build, and harder to build generically. Drupal is substantially more flexible than WP or Joomla, and therefore a theme that is not site-specific will be harder to build in the first place.

Your argument actually supports my point! The additional difficulty and higher learning curve combined with the INability to viably commercialize their work is making designers simply avoid Drupal. Why should designers put out so much extra effort to get into the Drupal market when the lower hanging fruits of generic non-Drupal templates is unencumbered by the GPL?

Designers make money mostly in one of two ways: (A) sell, as you suggest, one site at a time for big fees charged to single clients ... or (B) sell attractive generic themes to wide audiences with small fees shared among many buyers. The following story will illustrate my point:

A friend of mine who is a designer (I am not an artist) told me: "If I make a Drupal Theme for the masses I can sell it to Drupalistas much like Top Notch Themes [her example] does for about $200 a pop. If I make one or two sales before someone grabs the code and starts republishing it on one of the $50 premium sites I will be lucky ... OR ... I can strip out ALL the Drupal API calls, put in pure HTML and put it on Envato Marketplaces for $25 and make MORE money selling to non-Drupal webmasters. And for that matter, why even bother creating the PHP powered version if I am going to do that?"

So in the end, the Drupal community loses. If designers could create Themes and sell them "safely" to 20-30 buyers they would be more willing to sell them at lower prices.

There are a lot of really good Drupal themes made, but they're site-specific and the L&F (the art design, which as you said is the valuable part) is proprietary to the client. Generic Drupal themes that don't look like Drupal are extremely hard to do for technical reasons, not legal ones.

It isn't that the art is the valuable part, all of it is valuable, it is just that to a designer their creative work is not easy and should not be easy to just duplicate and give away after only one sale.

Many people said websites had to have tables to look good, then along came CSS and the game changed. CSS3 and HTML5 are changing the game again as we speak. Drupal is still young, who is to say what innovation will "come along" in breakthrough designs to change the game. But if WE don't encourage the involvement of high-quality designers with the same enthusiasm we have coders then we be the last to see those innovations because most of the cutting-edge designers won't work in Drupal for the economic reasons I've already discussed.

I also do not believe that actively encouraging the commoditization of code is in the interests of the Drupal community or the principles of Free Software.

Thus I believe your intent here is not one that can be supported, nor is your method logistically viable.

I am not sure I correctly understand your term "commoditization" of code but the GPL clearly encourages "making money" so how do you see that is against the interests of Free (as in speech) Software ?

Fundamental misunderstanding

Crell's picture

I believe there are a number of fundamental misunderstandings in your post above. I will address them out of order so that this response makes the most sense.

1) By "commoditization", I don't mean commercialization. Drupal has already been demonstrated to be commercially viable. Commoditization means, essentially, the business model of per-unit sales. $10 for each copy of a program or module with redistribution prohibited. That particular business model works great for widgets, cars, toothbrushes, and other physical objects and has for millennia (moreso after industrialization made rapid reproduction in a factory easy). It is, however, directly contrary to the spirit and intent of Free Software because of the "redistribution prohibited" part. The GPL was written specifically with the intent of removing that clause when applied to software, on the argument that it was unethical. That the removal of that restriction makes that business model more difficult and frequently untennable is not a bug but a feature of the GPL and of Free Software.

As a supporter of Free Software principles, you are correct that I am not "suspending my doubts" to try and find ways around that policy. I am trying to explain why it is impractical and/or impossible to do so. As Director of Legal Affairs for the Drupal Association, I am representing the official position of the Association in this matter as documented in the Legal FAQ, which is quite clear on these matters.

Yes, the GPL supports making money as long as the 4 Freedoms are kept intact. Commoditization does not keep those 4 Freedoms intact. Therefore the GPL does not support Commodization. QED.

(Side note: There are some markets where people do manage to commoditize GPL software; most notably I know some Indy game developers who do so. If they are able to do so then more power to them! But we cannot "bend" the GPL to encourage such commoditization within Drupal, even if we wanted to do so, which I do not.)

2) Your artist friend apparently does not understand the licensing of Drupal themes, or themes for any other CMS, either. As stated in the other thread and as stated in the Licensing FAQ, the GPL on Drupal applies to any PHP and Javascript portion of a theme, but not to image or CSS files. The GPL policy of the Drupal.org community repository (currently CVS, soon to be Git) applies to all files without exception. If you are distributing a theme through not-Drupal.org, then you are (generally) under no obligation to use the GPL for images and CSS files. Successful Drupal theme companies do just that. To quote from TNT's FAQ, for example:

The template files and Javascript of our themes are licensed under the GPL - General Public License, Version 2... Other files (graphics/CSS) are copyright TopNotchThemes.

Thus is you buy a theme from them, you are not allowed to redistribute the entire theme to some other download site. If you do, you are breaking copyright law. Of course, that doesn't stop people (this being the Internet), but that's not a matter of licensing restriction. Someone who is going to take your friend's theme and throw it on TuCows or some illicit download site to resell themselves doesn't care how much of the original code is under the GPL.

There's nothing different about Drupal themes there.

Also note that TNT does custom theme work and consulting, too. The "make something once and then sit back while it's sold a million times and get rich" model, well, doesn't actually work on the Internet. It's not the job of the GPL or Drupal to prop up that business model, especially when the spirit of Free Software is against that business model (since it is inherently based on restricting the flow of information, as above). If your friend wants to be a successful Drupal themer, she should try a model similar to TNT: Sell some mixed-license themes commercially as advertising and provide theming consulting services along side it. There is plenty of money to be made that way.

3) I am not familiar with any plans by the DA to offer a commercial theme marketplace on Drupal.org. Even if it were to do so, it would have to be under licensing terms no less-GPLed than those used by TNT and similar companies above.

I hope that clarifies the situation.

Great idea

eigentor's picture

The idea of a theme marketplace on d.o. may actually be a brilliant idea.
First let me state my starting point: GPL and non GPL aside, Drupal has a problem: the general notion is it is ugly because beatiful themes are lacking. This is a very serious problem and gets even more focus now UX matters start to improve and are not the weakest leg anymore.

Lack of design and much more so lack of designers in the community I would see as the biggest flaw now. So we should go great lenghts to improve this.

The general situation at the moment is that everything on d.o. is free. So only free themes are hosted. So people create Theme shops elsewhere, sell their themes on templatemonster et al. So people that go to d.o. still don't get to see beautiful themes because the beautiful ones are scattered around gazillion different places.

No matter how GPL issues can be resolved, investing some thought in it could be well worth the pain. Designers need strong incentives to flock to Drupal, because as Larry states: no matter how an experience Drupal themer might see it, Drupal theming is very hard. The incentives of making money by sales is a very direct one. And be sure a designer could sell more drupal themes off d.o. than off any template shop.

It is not that hard, but the fact that popular themes (look into 960's page.tpl.php) have LOTS of PHP inside the theme scares people off.

So the idea to have a mixed free/non-free marketplace on d.o. aka on some subdomain could take us places. Sure this would raise discussions much bigger than the founding of Acquia. Sure this needs a business model, someone who jumps the task and everything. But hey- the mere idea of going to d.o., going to themes and seeing lots of beautiful ones (top dowloaded and best rated to the top, please! Base themes like Zen get their only category so they do not take up the first place) makes me climb the eiffel tower to shout off it in joy.

As to the Licensing part: Larry nails it pretty clearly, that is how it is and will be as we won't reinvent GPL here. So a theme marketplace with paid themes would have to reside in another repository than the one where all modules and core and stuff goes.

Life is a journey, not a destination

Thanks.

Aveu's picture

It wasn't my idea, someone else said it a while ago. I think my sole contribution is the idea of isolating it to a separate subdomain and server. Among other things that also would allow the look & feel of the portal to adapt to different needs than the rest of d.o

So a theme marketplace with

Grayside's picture

So a theme marketplace with paid themes would have to reside in another repository than the one where all modules and core and stuff goes.

Put Drupal.Org in a better position to help connect service providers with consumers. The association recently posted about an intent to pursue this.

Such a system could connect out to an independent market to connect products with consumers, instead of requiring all themers to maintain their own website. By connect out, I mean a very straightforward profile link.

Theme development

Group organizers

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: