Themes versus Modules

Aveu's picture

There has been much discussion through the years about the automatic GPL status of Themes and Modules, and I will weigh in on that topic itself in another post (see the bottom of this post). But for now suffice it to say that I see an argument in favor of requiring GPL for Modules but I see a very different and very compelling argument in favor of excluding Themes from the GPL mandate. This post is to address a pre-cursor to that argument ...

If there is ever to be an exception for Themes but not for Modules then we must start by creating a clear distinction between what a Theme is and what a Module is. Fortunately such a distinction is pretty easy: While both are a form of "add-on" or "plug-in" to the Drupal system, Themes are about layout and Modules are about content. In the same way that CSS should never need to worry about what content is in the various HTML statements, Drupal Themes should never need to worry about what content is in the various nodes and databases.

All computer programs can be loosely defined in terms of 3 phases: input, process, and output. A Theme definitely will manage the output, it may manage the input (think things like forms and controls) but a Theme will never manage the processing, selection, and/or storage of the data itself (other than layout related processing like calculating fluid column widths). Even providing Javascript for form input validation should not be handled by a Theme, but rather by whatever form creation Module was used.

Themes should have very little latitude to decide what data they are to display. It is the pre-eminient domain of the Module to process and select records for display. A good example of what I mean is that given a table of data a Theme may implement an AJAX type interface to color, sort and even filter rows for display. This filtering would seem to be a selection decision by the Theme but in reality the base data was all provided by a Module and the Theme is merely "prettying" it and hiding some of it at the User's or Developer's (default) request. If the User switches to a non-DHTML powered Theme that same data will still be displayed, probably as an HTML TABLE, sans the AJAX functionality.

Themes should be independent of display technologies. Anything called a "Theme" that needs technologies like Javascript or Flash to display a particular kind of data should be suspected of being a Module creating a content block and not just a Theme.

Another thing to think about is data management. When it comes to "CRUD" a Drupal Theme should only be allowed to use the "R" function, leaving Drupal Modules and Core alone to chew on the remain "CUD" functions. If a so-called "Theme" starts altering existing data and then returning it for storage to the database then it has crossed the line into what a Module is supposed to do. Note however that if a Theme presents the User with a form containing a field of text data that can be edited and then sends any changes in the text back to Drupal, the changes were not done by the Theme but rather by the User. Likewise the Theme did not create or populate the form and the Theme did not further process the data after the SAVE button was pressed.

This is how I see the difference between these two items and I welcome any comments on this subject to help improve the distinction between Themes and Modules. Please stay on-topic and don't hijack this post to discuss the GPL issue as it relates to Themes ... that is addressed in my post called "GPL group recommends CMS templates be licensed under a different license.".

Comments

Though I don't really feel

PixelClever's picture

Though I don't really feel that GPL is important, you are mistaken in your generalizations in regards to modules and themes. Modules can be related to content (views), or to layout (panels), or functionality (backup and migrate). Themes can deal with all of these same issues depending on the complexity of the theme. It is not correct to say that a theme doesn't care about the content. Themes structure content per content type, per block type, and even per field. Only the simplest themes do not account for the content.

Drupal theming, Module development and logo design:
http://www.PixelClever.com

To clarify

Aveu's picture

Perhaps the following is just my own interpretation and recognizing that I posted this for feedback.

My thoughts on how to un-blur the line between the themes and modules led me to consider the reason a theme exists: to create/modify the look & feel of the website/page/block/field etc... That to me is the purpose and function of a "true" theme and adding any functionality to a theme which is not related to look & feel does a dis-service to the webmaster/site developer.

Likewise module developers who hardcode a particular look & feel do a dis-service to the webmaster and to the many theme designers who ought to be able to add value to that module via theme hooks. When a module requires code hacking to change the look & feel of its output that is a poorly written module in my opinion.

Yes, every module that creates output should have defaults but those defaults should defer to whatever theme is active if that theme has routines for its output type. This is much the same as CSS and HTML. HTML can have many elements of many types and CSS can have functionality dedicated to each type of element. Sets of CSS code may or may not address certain element styles.

When I say that a theme should not care what the content is I mean that in the same way that CSS should not care what the elements are ... it either has a function for a specific element or it leaves it alone. Ultimately I think to achieve such functionality I think the theme engine will need to be greatly enhanced, implementing an expanded API allowing for granules of theme functionality based on content type.

Finally, the less a theme alters the underlying content data the better. Module writers should not have to wonder that if Website A uses Theme X instead of Theme Y will his data be handled correctly?

Today we have many modules and many themes that DO mix it up "willy-nilly" and I think that is a mistake. I am hoping for a better distinction so that we can move towards a cleaner relationship between all developers / modules and designers / themes.

Impossible distinction

Crell's picture

The distinction you're making between modules and themes is, within the context of Drupal, unnatural. As Aaron noted above, lots of modules are all about front-end code. Is Semantic Views, for instance, "module" or "theme"? If a module includes template files, are those considered theme or module? Simply moving the file from one directory to another doesn't change its nature.

In Drupal 7, themes can now run alter hooks. That is, a lot of "Theming" now happens via template.php in PHP code, code that is otherwise identical to what you would put in a module. It's just happening in a theme.

And of course as long as template files are PHP code, there's nothing stopping someone from writing SQL and other business logic right into the template file. They're stupid to do so, and should be trained not to, but that doesn't mean people don't do it.

There are even proposals in the works to merge modules and themes even further. I do not necessarily support these endeavors, but that is the direction Drupal has been moving: Themes and modules are getting closer, not further apart. Dries has even toyed with the idea, albeit briefly, of removing template engines and making PHP template our only templating system.

It would be wonderful if all themes were pure display and contained nothing but a few dead-simple template files and CSS. In actual practice, that is simply not possible given the way Drupal is designed.

With that distinction essentially non-existent, there's no legal way to treat them differently. The sort of templates that the FSF is referring to in your other post are, I suspect, based on the assumption of much "dumber" theme logic than Drupal implements.

It's so simple.

Aveu's picture

Think of it this way:

If Drupal is a planet then Themes are orbiting satellites and Modules are ground-control.

Satellites are not allowed to enter the atmosphere for any reason, they can only toss data back and forth with ground control, if a satellite breaks orbit then as the saying goes: "Houston we have a problem."

SO MAKE A NEW RULE:

If you write something and want to call it a "Theme" then it can only play with OUTPUT -- it can do anything it wants with OUTPUT -- it can make OUTPUT dance on the screen with snowflakes and flames while singing Geek & Gamer Girls ... BUT ... if it tries to save or delete CONTENT it can no longer be called a "Theme" anymore. It has broken the rules and loses the right to use that name. It may be a Module or it may be a Module/Theme hybrid but it is no longer a pure "Theme".

Despite the analogy this isn't rocket science ... We set a BEST PRACTICE that either a Theme follows the "OUTPUT ONLY" rule or it cannot be CALLED a Theme. It is no more complicated than a line in the sand - do not cross the line.

If a Theme needs (?) to directly manipulate content (why?) then either it becomes a hybrid Module or else better we can encourage the maintainers to split the CONTENT related functions off into a Companion Module. That is much more preferable because it means someone else can look at that same Companion Module and come up with a whole new and different Theme for it. Now we have 1 Module and 2+ Themes, and that is a good thing.

Architectural distinction

Crell's picture

You're trying to apply a social convention as an artificial separation where architecturally and legally one does not exist.

Sure, it would be wonderful if in some idyllic world we could say that a theme is "pure output". That is, however, simply not the situation in practice. Most themes in practice contain a substantial amount of PHP logic (code, definitely GPL-affected). That's because, contrary to what everyone seems to think when they first start out with "theming", the display layer requires logic,frequently complex logic. Complex logic in PHP as part of Drupal is subject to the GPL. There is no way around that. Simply declaring it "output" does not magically make preprocess functions not subject to the GPL.

The idea of "well just don't call it a theme then" is equally nonsensical. There are cases where SQL will run from a preprocess function, and that's not always an evil thing to do. Are you suggesting that if someone has an SQL query in their template.php file then they are not allowed to call it a theme, even though it's in a themes directory and is enabled through the admin via the "Themes" page? That's crazy talk.

Or take Javascript in the theme. That's clearly output, but is also complex logic that, in most cases, will be extending and deriving from jQuery, which as distributed by Drupal is under the GPL. There's no way around that, either.

It is already understood and documented that, if not distributed via Drupal.org, CSS and image files in a theme are generally not subject to the GPL (unless the image itself is derived from a GPLed image, like Druplicon). Commercial theme companies already take advantage of that. PHP code, however, which includes template files when using PHPTemplate, are.

That is the only distinction we can make unless we vastly change Drupal's theming architecture. That is not possible to do without vastly reducing its capability.

WOW! You *REALLY* misread what I wrote.

Aveu's picture

WOW! You REALLY misread what I wrote.

You're trying to apply a social convention as an artificial separation where architecturally and legally one does not exist.

Forget the legal, this is not about the legal, period. That is a separate post and if that post was never there this topic is still valid. This is about exploring Best Practices for Theme & Module development, period.

WHY IS THIS PROPOSAL A BEST PRACTICE?

Because if Themes are allowed to do what Modules ought to be doing then needless incompatibilities will be created. While some Themes might require assistance from Modules, the opposite should never be true.

In an "idyllic world" no Module should break just because an admin or user changes the Theme for their site. If a Theme designer decides to not include specialized functionality for certain output types (tables for example) the Module should still work even if the output is rendered as just plain HTML. This is called "graceful degradation" and that is a Best Practice in most web software development shops.

Best Practices are choices, often based on rational observations but also sometimes based on artificial or arbitrary preferences. Take Drupal's own coding style "rules" for example (http://drupal.org/coding-standards).

Whether "the Drupal Way" code formatting requires indents of 2 spaces or 4 spaces per level is arbitrary. It is a convention based on what exactly ? Why is 2 better than 4 ? Shorter lines ? OK .. but 4 spaces makes it easier to visually see the logic structure at a glance. Both have value, bottom line it was a choice. Drupal made a choice and now that is a line in the sand that is not crossed. If you submit your code with incorrect indentation it will be rejected. It will not be allowed to play in the CVS until it gets back in line.

There are several more examples of artificial and arbitrary decisions in the guidelines. I am doing nothing more than proposing one more guideline.

Sure, it would be wonderful if in some idyllic world we could say that a theme is "pure output". That is, however, simply not the situation in practice. Most themes in practice contain a substantial amount of PHP logic (code, definitely GPL-affected). That's because, contrary to what everyone seems to think when they first start out with "theming", the display layer requires logic,frequently complex logic. Complex logic in PHP as part of Drupal is subject to the GPL. There is no way around that. Simply declaring it "output" does not magically make preprocess functions not subject to the GPL.

Here is where you completely misread what I said. I never said a Theme is "pure output" ... I said a "pure Theme" should only contain functionality to process (format) output and should contain no functionality to process (alter) content. PHP, javascript, even SQL queries are fine as long as they don't try to directly (repeat, directly) WRITE into to the databases. The logic of what data is allowed to be stored (or removed) in the databases should never be handled by Themes with the possible exception of input validation filters, and even there the logic is better supplied by a form module and not by the Theme that prettys the form elements.

For example I think browser compatibility code (things like IE6 hacks) can and should be handled at the Theme level. That is certainly complex logic if done comprehensively. Of course a Theme helper Module to handle the common standard queries (like determining screen resolution and useragent) could be designed to be shared by all Themes. On the other hand a Theme should never have logic to take an action if the useragent turns out to be a bot. Such a decision should be handled by a separate Module interfacing with robots.txt and other security Modules. If a website comes to depend on such a function in its Theme and then later the admin changes Themes, forgetting about that non-output related functionality, the security of the website could be compromised.

The idea of "well just don't call it a theme then" is equally nonsensical. There are cases where SQL will run from a preprocess function, and that's not always an evil thing to do. Are you suggesting that if someone has an SQL query in their template.php file then they are not allowed to call it a theme, even though it's in a themes directory and is enabled through the admin via the "Themes" page? That's crazy talk.

see above

Or take Javascript in the theme. That's clearly output, but is also complex logic that, in most cases, will be extending and deriving from jQuery, which as distributed by Drupal is under the GPL. There's no way around that, either.

see above

It is already understood and documented that, if not distributed via Drupal.org, CSS and image files in a theme are generally not subject to the GPL (unless the image itself is derived from a GPLed image, like Druplicon). Commercial theme companies already take advantage of that. PHP code, however, which includes template files when using PHPTemplate, are.

Again, this topic is not about the legal issue, but I'm glad you mentioned CSS. It made me think ... would you want CSS or HTML deciding what is written in the Apache logs? Of course not, that is not it's JOB .. and the exact same logic ought to apply to Themes. The W3 Consortium has been slowly and steadily working for years to create standards that help to separate content from layout/format. Many previously common coding practices are now deprecated and even obsoleted in the modern HTML standards. What I am proposing is absolutely the same for Drupal, keep content and theme functions as separated as practical.

That is the only distinction we can make unless we vastly change Drupal's theming architecture. That is not possible to do without vastly reducing its capability.

All that is required to make this distinction is a policy. No coding required unless you want to automate checking what functions a Theme invokes to ensure no WRITE type functions are called (which would be trivial).

Let's get back on track

Todd Nienkerk's picture

Avue:

Above, you say this:

I am doing nothing more than proposing one more guideline.

Can you explain, as concisely as possible, what exactly it is you're proposing? I'm having a very hard time trying to suss out exactly what we're talking about in this thread. I got the impression -- and I don't think I'm alone -- that you're arguing that only themes, not modules, should generate output. (I disagree, hence my lengthy reply below.)

If you're talking about proposing a coding standard along the lines of something else you said earlier:

If you write something and want to call it a "Theme" then it can only play with OUTPUT [...] [I]f it tries to save or delete CONTENT it can no longer be called a "Theme" anymore.

...Then I agree. I think it's bad practice to write to the DB -- even access it (apart from the variables table) -- from the theme layer. A helper module should be written to do these things.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

You are correct.

Aveu's picture

Todd,

Your understanding at the bottom of your above comment is exactly what I was proposing.
Themes should be designed to play WITH output, not BE output. Themes should not write to the DB.

As simple as that. A properly coded Theme should do that and the restriction on what section of the d.o it can go in is the incentive to code it that way.

Good in theory, impossible in practice

Todd Nienkerk's picture

I agree that modules and themes should ideally be separated into data and output, but this simply isn't possible in the Drupal development ecosystem.

When creating a website, the responsibility of generating output for a particular task (module, plug-in, form, etc.) can be assigned to one of the following people: the webmaster, the themer, or the developer.

  • The webmaster, sometimes called the "admin," is a Drupal user who builds and runs a website. The webmaster is given all the data in some raw form and must use the presentation layer to shape it into what they want. The webmaster must know HTML, CSS, and probably a bit of JavaScript to achieve what she wants. (In my experience, it's highly unlikely that a webmaster knows as much about theming as a themer.) Because the webmaster built the site, she knows all of the modules in use and therefore can predict all of the data that will be delivered. In this scenario, no module "just works" out of the box. All output must be designed by the webmaster before it can be seen.
  • The themer creates Drupal themes but does not create or run whole sites. Like the webmaster above, the themer will take raw data and use HTML, CSS, JS, etc. to create a theme that a webmaster will enable on their site. The themer doesn't necessary know what modules will be in use and therefore does not know what kind of data will be delivered. (Will Views be used? Will they be displayed as nodes, grids, or tables? What about the Flag module? Or Fivestar? Will the webmaster override profiles using Content Profile?) This task is easier when working with a well-defined site, as the themer will know in advance exactly what modules will be used. However, when creating a contributed theme or working with a site that may add modules in the future, the themer has three options: (1) don't support any output not included in core and let the webmaster or developer handle the rest; (2) make a guess as to what modules may be used and support a handful, letting the webmaster or developer handle the rest; or (3) support every module in contrib, which removes the burden from the webmaster and developer. Option (3) is obviously impossible, so we're left with a theme that supports (1) only core output or (2) a handful of select modules' output. In this scenario, some modules may "just work" when enabled, but it depends on which modules the theme supports.
  • The developer builds Drupal modules that generate and deliver data. The developer knows more about the data within her particular module than anyone else. When building a module, the developer has two options: (1) generate the data and deliver it to the theme in a raw format, which will require the webmaster or themer or generate output; or (2) generate the data and the output, and provide both to the presentation layer so that the webmaster or themer can decide whether to keep the developer's output or override it and make their own using the raw data provided. In this scenario, most modules will "just work," and the webmaster and themer have the choice to generate their own output.

Drupal currently follows the developer-centric model, which provides the most out-of-the-box functionality without sacrificing the tastes of the webmaster and themer. This makes sense because Drupal modules outnumber themes 1,000:1. (I made that up, but I'm sure it's in the ballpark.)

What makes this issue particularly difficult is that Drupal must simultaneously satisfy the needs of small, simple sites and big, complicated sites. Everything I've discussed above wouldn't be an issue if Drupal were only used by small, simple sites. Drupal would be tightly focused to perform a few tasks and would therefore need fewer modules. It would be more popular amount small site administrators, which would increase the demand for more contributed themes. In other words, if Drupal were used only by small, simple sites, it would be WordPress.

But Drupal isn't tightly focused, and it runs some of the biggest websites in the world. Its module ecosystem is enormous, and every large Drupal site has its own very strict use cases, needs, and branding concerns, which makes most Drupal themes custom one-offs.

Because Drupal must "just work" for small sites and be highly overrideable/customizable for large sites and because its modules vastly outnumber its themes, it makes perfect sense for Drupal developers to generate output in their modules. It's the only way this ecosystem could function.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

Tom Tran's picture

I would like to understand what if a theme renders the layout/style of the core and some contrib modules, but then modules get upgraded over and over and the themer has to adjust. For custom theming it would be only a small adjustment for the themer if the webmaster deems upgrading the module really important.

But say we would like to create theme solutions for specials kinds of websites (e.g. Real Estate)? But are dependent on many modules for the special kinds of output needed. It seems to be a bad practice to include complementary modules going with a theme and have it upgraded in-house if needed, kind of custom project.

But then it is very difficult to provide turn key theme templates that fulfill special needs for certain kinds of websites.

Please correct me if I am wrong here. Thanks

Backwards Compatibility

Aveu's picture

webtome, What you are describing is called "backwards compatibility" and it is a great question!

GENERALITIES:

Perhaps the answer is wrapped around a question that has not been asked:

As a Best Practice what kind of output should core modules be "restricted" to creating so as to ensure maximum backwards compatibility with all Themes ? ... also ... Should backward compatibility rules be different for core vs contrib modules ? (other then theme companion modules of course, see below)

In my mind any core output ought to be delivered to the theming engines in as plain a format as possible and with as much CSS identity as practical. I think for the most part Drupal does that rather well. If this principal is strongly adhered to then all themes should be free of impact unless the CSS identifers are changed.

What this means is that if I have a "hands-off" theme that does NO modification to the Drupal output then I will get a ugly website with white background, black text, and blue/red hyperlinks, no columns and no alignments. In short, HTML for beginners 101. But as long as the HTML includes lots of CSS tags to use then with templates and CSS I can manipulate this output to look any way I want.

Now take the example of a Calendar contrib module ... custom styling calendar's is something I like to do.

NOTE: To keep this matter simple I am going to ignore all the fantastic work that has been going on in calendar modules recently so for those who have added many great advances please take no offense.

A calendar type contrib module could provide the output as a simple HTML table or it could provide it as a series of 31 unformatted SPANs. Each of course would have CSS identifiers built-in. If provided as a table then I need simply add some basic CSS table styling and away it goes ready for the web, but if provided as a series of SPANned data I must do much more worjk to make it look like a calendar, although I am able to vastly increase the ways I can style it.

To me, a well behaved calendar module ought to offer at the very least the "31 SPANS" structure and the "5x7 TABLE" structure, each as optional variant outputs. Later the module author might decide to add XML and iCAL outputs and those would be more optional variant outputs. Or someone might write a bridge module that takes the 31 spans and creates XML from them. The bottom line is that a contrib module ought to consider the issue of backward compatibility and keep old formats intact when reasonable to do so. Obviously correcting a design flaw might mandate changes (as in D5 vs D6 theming) but good module writing should be sensitive to breaking old themes.

SPECIFICS:

Now as for your specific question of a real estate or other custom purpose site.

Any module that delivers custom purpose outputs should (IMHO) provide a helper or companion module with at least one default theme for each content type the module will produce. By keeping these "look & feel" functions modularized away from the other processes of the real estate module, you simplify maintenance of the module and you offer ease of access to other themers who might need/want to radically change your layouts.

It is all about planning ahead. Input > Process > Output are the three distinct and key sections of every program. A well designed module is going to incorporate these distinctions in their logic. If the logic is clean then you can create a collection of modules that play nicely together while keeping the I/O functions separate from the process functions. This collection -- with defaults set -- is no different than any other turnkey system.

Look at it this way ... Drupal is a turnkey system the way it is currently distributed. With nothing more than filling in a few blanks you are up and running with a basic look and feel and an option for a couple of content types. The new Drupal Profiles are other turnkey systems. I am currently working with the DrupalCart profile on a website, its a low budget site that wanted basic shopping cart functionality and I was able to have it running in minutes then spend the rest of the time tweaking the look and feel to make the customer happy. In this role of "themer" I don't really care how the website works internally. All I need to know are the types of content and the names of the variables I can access for displaying output. In my role as "developer" I do need to understand the internal workings but if I can tweak those without worrying about the theme I am much happier.

Input > Process > Output ... keep them separate in code

GPL Metaphors are like a box of chocolates

eaton's picture

Lots of discussion about the GPL boils down to bad analogies and essays about hopes and dreams. Let's break the "themes and the GPL" issue down, really simply.

  1. If you check something into Drupal.org's source control repository, you are voluntarily distributing it under the GPL. Period. End of story. This has nothing to do with whether themes, as platonic entities, should be required to be distributed under the GPL. If you put it into Drupal.org's source control repo it's GPL'd.
  2. Any theme that includes executable code that interacts with Drupal's own executable code is essentially plugin code just like a module, with a slightly different set of technical responsibilities. It is that executable code that is subject to the 'derivative work' clauses in the GPL. In other words, if you have a bunch of alter hooks and preprocess hooks in your template.php file, it must be GPL'd just like a plugin module.
  3. Images, CSS files, flash files, icons, and other 'support assets' are not automatically subject to the GPL because they're not executable code. However, if you check them into Drupal.org's source control repo, you're voluntarily distributing them under the GPL. See #1.
  4. Template files themselves -- like node.tpl.php -- contain PHP and thus fall under the same issue as #2. However, because Drupal supports different templating engines, it is theoretically possible to create an engine whose templates contain no executable code and thus don't have to be GPL'd. Most template files, though, consisting of executable PHP as well as HTML markup, don't fit that critera.

Given this setup, it's perfectly possible for a designer to build a CSS-and-images-only child theme for an existing base theme, and announce that it's a commercial product rather than a GPL'd one. If they created any PHP-based preprocess functions, or custom tpl.php files, those would need to be GPL'd.

Unless a module actually

Acubed's picture

Unless a module actually contains code that is exclusively distributed under a GPLv2 license, it isn't a derivative work. (And if the work being derived were dual licensed, for instance, you would have your choice of license.) You would have to ship GPL'd code inside non-GPL'd code in order to be protected (or, use the LGPL which allows you to do so). The only legal requirement that modules be licensed under the GPLv2+ is a contractual one, as you said, to get hosting at Drupal.org. That's why the question is should the licensing standards be changed.

Not so! ... or so they say ...

Aveu's picture

Acubed, If you read the various posts in the "Legal" group here you will see that according to the SFLC -- the lawyers of the Drupal Association who are also the lawyers of the FSF (so they are very well versed in the GPL) -- a "derivative work" exists simply by the mere interfacing of any Module/Theme with any Drupal API call. You may not agree but that is the official and endorsed position of both our lawyers and our leadership.

I've read the SFLC and they

Acubed's picture

I've read the SFLC and they don't have anything to say on the topic of loadable extensions or similar libraries that are not distributed with the licensed work. Nor does the FSF: The FSF argues against using the LGPL only because it would allow you to distribute LGPL libraries with proprietary code, but it does not affect the use of libraries not distributed with the licensed code. There is not a single court case that has upheld that simply interfacing with some program or device means that it is a derivative work, and in fact the courts have held that interfacing with other software programs or devices through an API grants the coders more rights to do so and not less, and the EFF has successfully argued this position.

The position as I read it depends on the fact that copies when in computer memory form the same work -- This is called an intermediate copy and because it is not distributed it is not covered by the GPL, since the GPL only needs to be agreed to in order to distribute code (the GPL is not an EULA).

Copyright law covers code as a "literary work" no court has held that such protections are extended to computer RAM. Additionally the courts have ruled multiple times that writing or re-writing a software program, even if it uses a particular API of another software program, does not constitute a derivative work. The courts have also ruled that a program which modifies another work, is not a derivative work, and even if it were because it copied portions of code from the parent work, fair use would still likely apply (for instance, if the copied code were code necessary to unlock a lockout mechanism), see Lewis Galoob Toys, Inc. v. Nintendo of America, Inc. and Huntsman v. Soderbergh among other cases.

Why don't people READ ? sheesh

Aveu's picture

Aveu wrote:

Acubed, If you read the various posts in the "Legal" group here...

Acubed wrote:

I've read the SFLC and they don't have anything to say on the topic ...

I didn't say read THEIR website, I said read OURS ... Our website will tell you that the Drupal Association HIRED the SFLC for counsel and the official legal opinion they have given directly to our Drupal Association Board of Directors is that ALL MODULES and ALL THEMES are "derivative works" under the GPL ... Dries and the rest of the Board support that position.

If you disagree take it up with the D.A. BoD not me, I was just pointing out what I read HERE.

http://groups.drupal.org/node/12624#comment-40505

I'm not interested in wishful

Acubed's picture

I'm not interested in wishful thinking. I'm interested in what the law actually says and what courts will actually uphold. I've cited what the courts have to say on the issue, I think that trumps what anyone else would prefer the law to say, short of being able to also cite the law and court cases (which no one else has, not the SFLC, no one on Drupal). Personally I would prefer the law not artificially restrict the distribution of software at all, but since the conversation is within the context of copyright, I'm talking about the law, and the law is clear, modules are not derivative works. The relevance that themes vs. modules is if the requirements for Drupal.org branding/hosting should be changed and what impact it would have on the development of themes, because there is no control of themes distributed outside Drupal.org.

Very well said.

Aveu's picture

Nicely written eaton, and very succinct. Precisely describes the GPL situation for all Drupal contributors.
This text ought to be put into a stand alone page and added to the short list on the [http://drupal.org/contributors-guide |Developing for Drupal] page.

PS: This comment really belongs in the [http://groups.drupal.org/node/114819 |other thread]. Follow up comments on any legal stuff should go there.

Can we circle back to intent?

mandclu's picture

Part of me feels like there should be a comment in here about feeding the trolls but I'll hold off for now.

I'll confess that I'm no lawyer and definitely have no expertise when it comes to copyright law, but it seems like a stretch to say that something is a derivative work simply because because it interacts with a published API. Are Photoshop plugins derivative of Photoshop? That hardly seems logical, but I'll concede that there is a lot to do with copyright law that is counterintuitive.

Maybe I'm just tired of seeing my inbox filled with message after message about these GPL arguments, but really... who cares? If someone in Kazakhstan wanted to publish a set of Drupal themes and claim they were non GPL, who would take it to court? And who would respect these non-GPL supposed licenses anyway?

Being GPL'ed doesn't restrict people from making money on their work, so how much does all this matter anyway? Can't the people who really love debating about this take the topic to a forum that's filled with people who actually care?

Move the legal discussion

Todd Nienkerk's picture

Can't the people who really love debating about this take the topic to a forum that's filled with people who actually care?

As the OP has mentioned several times in this thread, there's another post in the Legal group dealing with the GPL issues: GPL group recommends CMS templates be licensed under a different license. Let's end the legal debate here.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

THANK YOU

no longer here 327072's picture

I may not have been exact in my representation of what the truth of the matter is on GPL, open source, theme licensing issues, or what have you, but I thought it was really obvious that the topic was not germane to how themes WORK, which is why I am subscribed to themes discussion.

I apologize to the community at large for being grumpy in my post, and also for apparently offending the sensibilities of others who have more knowledge about licensing, open source, etc, than I.

Please, instead, take my posts as an expression of frustration about an ongoing posted topic that seemed to be lodged in the wrong discussion space, and thanks Todd for being more explicit than I was.

I did not mean to fuel the fire, but mistakenly I did. I guess I am guilty of feeding the troll (GOFTT).

I hope everyone had a happy new year, and 2011 is a one full of good tidings.

madame philosophe
so many thoughts...so little time.

At least a little, it does

Acubed's picture

It does matter, at least a little, because the GPL is still a copyright license. It still makes it illegal to distribute the program unless you meet the author's demands, and I want to have none of that.

It might not matter for an uncopyrighted, public domain Drupal module (where there is no compiled form, it matters more for compiled software and media, like the source files for graphics), but the consequences of such an idea becoming law are tremendous. Imagine Microsoft or Apple requiring all programs that run on their OS to get corporate approval, and not just with some DRM scheme (as we see a bit of now), but actually taking developers to court because their software is considered a derivative work of Windows or OS X.

Outside that, no, it's probably irrelevant. As you suggested, is anyone really going to force me to distribute the source code for public domain modules over this idea?

Theme development

Group organizers

Group events

Add to calendar

Group notifications

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