On Aug 30, 2007, at 12:03 PM, Eric Tucker wrote:
However, it is unreasonable to expect companies who have proprietary algorithms in custom modules or even want to integrate with a third party API (or perhaps Google's nifty search-in-a-box) to let a CMS licensing constraint hold them back. Thus, these companies will turn away from Drupal if licensing does not permit it.
This is where 'distribution' comes into play. I've written modules with proprietary algorithms for clients, and the solution was simple: they didn't distribute the modules to other entities. Integration with third-party APIs like Google's, and the use of external APIs like Amazon's, take place over HTTP protocols. RESTful interaction for example is clearly inter-program communication and not 'derivative work'. Turning away from software with a particular style of license for ideological or business reasons is nothing new.
I don't think it's a big leap to say that a CMS is not merely a single software product but will increasingly become more akin to an operating system. Ideally, every piece of code for a site somehow sits somewhere in that CMS. The CMS ties everything together. It's the kernel and the glue. The database is like the hard drive. The web server is like the CPU.
It's an interesting philosophical discussion, but it would definitely be a stretch. Similar to arguing that Adobe Photoshop is an 'operating system' because there is a large suite of plugins that depend on it, and Photoshop ties them together. While I'm frustrated by some of these barriers, the reason for them is clear: there is no good way to carve out an exception for these things without undermining the point of the GPL: to make software available free.
If Oracle could never install their database product on Linux, would they use Linux? If a hot new site wants to build or integrate a proprietary map API, would they use Drupal?
Please read my earlier response regarding the 'driver' and 'operating system' exceptions that the FSF already includes in the GPL and accounts for in their documentation. If you have 'stump the GPL guy' questions, please contact the FSF directly. I reiterate that I am only relaying the summary of the information I got from them.
I am all for a GPL-like license for the core, but I believe the long term interest of the Drupal project is best served by ensuring that third party modules can be developed with their authors choosing the license that is best for them much like developing an app that happens to run on an operating system.
This would dramatically change the current state of Drupal development. At present, any module that's distributed must be released under the GPL, or at least dual-licensed. That's one of the reasons for Drupal's thriving developer community.
Let's make sure that the ability to build third party modules under any license stays that way.
There's nothing to 'stay' -- this ability does not currently exist. The question was whether it was possible to use a module to act as a 'bridge' between GPL and GPL-incompatible software like a commercial message board system. --Jeff