A month or so ago, this question came up in a LinkedIn Drupal group:
Suppose a charity organisation has built 40 or so custom Drupal 6 modules as part of a system to run certain aspects of their business. Suppose that now they want to de-brand it and sell it to similar organisations.
The original poster was asking what version of Drupal to use -- polish up the Drupal 6 version, port to Drupal 7, or go all the way to Drupal 8? But the discussion quickly turned to the logistics and licensing issues around selling a Drupal-based product at all.
The thing is, the way Drupal is licensed, you cannot restrict what other people do with anything you create on top of Drupal, once you provide it to them. So while you can sell your modules, you can't prevent your customers from giving them away after they've purchased them -- if you try to restrict them, you actually lose the right to use Drupal itself, under the terms of the GPL license.
So the question becomes, how do you build a business around a custom solution built on Drupal? You have a few options:
- Charge for services. This is what most Drupal shops do -- charge for development, maintenance, training, support, hosting, and more. Not for the code.
- Get funded to develop the module in the first place -- aside from traditional pay-by-the hour models, crowdfunding has risen as a great way to spread the cost of development across a bunch of interested customers. Grants can be another source of development. These funding models fit very well with the open source model that Drupal uses.
- Software as a Service. Nothing says you have to sell or give your custom modules away in the first place -- you can operate a business on top of Drupal without giving away any of your "secret sauce."
You can attempt to do what the original poster wanted, publish the modules and make them available for sale. The challenge here is that once you've sold to one person, you can't restrict them further.
Another option is to break
Another option is to break out the functionality as a separate library that does not rely directly on Drupal and release a "bridge" module that enables Drupal to use that library. That also opens up the ability to expand support to other systems (such as WordPress) with minimal effort.
Hi, Brian,
Hi, Brian,
Yes, you can absolutely do that... but then you lose a lot of the development benefits of using Drupal, such as Field API, EntityFieldQuery, etc.
One of the things we like about Drupal is how fast we can develop rich apps in it -- if we can't leverage Drupal to do that, it's no longer that fast...
Thanks for your comment!
Cheers,
John
I guess I never got a
I guess I never got a notification of this reply - just happened to see it when reviewing some reports.
If a library is built properly, you can indeed leverage Drupal's APIs. A properly build library should only provide data; the business logic in a library should be kept to the absolute minimum. For logic that requires Drupal or Wordpress et al to provide the data, the library should provide an interface to contract that system into providing the data in a consistent manner.
It's definitely do-able - it just takes proper planning. And that proper planning can also open up more potential markets for that commercial library.
What about "Premium Themes"?
What about the various avenues of a "drupal theme" and paid for services. Just google "drupal premium theme" I doubt most use a bridge layer -- as an example from the 1st page of google results:
http://www.themebrain.com/terms-of-use
sure sounds like they're limiting redistribution, etc. .... all the theme layer "runs through drupal" so are these not legit for the GPL?
Hi, David,
Hi, David,
I don't see anything wrong with the terms of use you linked... They do explicitly call out in their 4th clause,
>All files (CSS, JavaScript, PHP, images) which do not fall under Drupal’s GPL version 2 are not allowed to be resold or redistributed without our written approval.
Maybe written a little confusingly, but Drupal's license does not cover images or CSS at all, and Javascript often can be used without being derived from Drupal code (Drupal uses jQuery). The Drupal Licensing FAQ addresses this issue directly: https://www.drupal.org/licensing/faq#q7
> The GPL on code applies to code that interacts with that code, but not to data. That is, Drupal's PHP code is under the GPL, and so all PHP code that interacts with it must also be under the GPL or GPL compatible. Images, JavaScript, and Flash files that PHP sends to the browser are not affected by the GPL because they are data.
... that's not the full answer, because it goes on to clarify a few other points -- read the FAQ to get the best answer. The bottom line is, images and CSS are considered content and not necessarily derived from Drupal, and so Drupal has no say in the copyright on those (unless they are distributed on Drupal.org). And so the premium theme creators can distribute those under any terms they like, if they created them in the first place. The template.php and template files from any Drupal theme are indeed GPL, so anybody purchasing a premium theme can give those parts away -- but if they re-use the images or CSS, the premium theme author has retained rights they can use to stop that...
From the Drupal perspective, themes are part code and part content. Drupal cares about the GPL on code, but not on content -- imagine the uptake on any CMS that enforced a particular copyright license on any content written on a site using it!
Add new comment