I was just talking about engines with a colleague and I came up with an
exceptional reason why Engines really are one-of-a-kind when it comes to
licensing.
As many of you may know, the GPL license states that a piece of GPL
licensed
code can not be included as a library within a commercially licensed
product
when is shipped to customers. It can however be included by the customer
upon installation, or packaged on the same CD as the commercially
licensed
product, but not to be included until post-installation of the
application,
and by the customer themselves.
I would first like to point out that there has been little to no mention
in
any of the code I have seen, other than in the core Rails, as to what
license it uses, which leaves everyone out on a limb when it comes time
to
understanding whether or not you can actually package your product with
an
Engine, generated code, plugin, or such in it.
That being said, with the advent of Engines, they may very well soon
contain
a GPL license or something similar restricting the usage of the
application
license which has that code included within its core.
With the methodology in place to install an Engine, whereby you can run
“script/plugin install
svn://example.com/plugins/my_ferrari_engine/testarossa” and the engine
will
be instantly deployed within that application in the
“vendor/plugins/testarossa” directory, you can require that after the
installation process of the commercial application has been completed,
install the engine with extreme ease, while still containing the
overriding
functionality in your core application simply waiting for the Engine to
be
dropped in.
Now, in comparison to that of a generator, which is as far as I can tell
the
closest thing to providing the full scope of functionality that engines
have
(models, controllers, libraries, tests, etc), when deployed it will
extract
its contents all over your core application and may even overwrite files
and
such as a generator has a tendency to do. An example is when you have
already run the scaffolding generator for a model/controller, and you
have
previously customized your “/stylesheets/scaffold.css” layout to be
unique.
When you run the scaffold again for a new model/controller you will be
prompted to overwrite that scaffold.css file. At this point, the
developer
has to make the decision whether or not he/she wants the to deploy the
updated StyleSheet based on the most recent generated scaffolding code.
This specific example could be solved by having a diff merge tool option
at
the time of overriding instead of having the yes/no/all prompt when it
comes
to a file that already exists and whether or not to overwrite it. But
that
still would leave the developer in this case, with the merge to handle
on
their own, which may or may not have conflicts.
So with that in mind, the generators result could not be included by
default
if it had anything other than a LGPL/MIT or compatibly commercially Zen
license. And if you were to run the generator afterwards, as explained
above, you would have to deal with conflicting files or complex scenario
analysis when deploying to ensure that no files are overwritten or are
properly overridden by secondary controllers and models within the same
/app/controllers/ and /app/models respective directories.
So as a result, you find yourself, with an Engine that has a GPL or some
other license that still has some rights reserved by the author when it
comes to re-licensing that sub-application, easily deployable after the
fact
of sale to your customer with a 100% commercial license that still
allows
for GPL software to be utilized in a symbiotic fashion.
This conclusion does leave the GPL licensors at a loss if they do
in-fact
refuse to have their application included in a commercial application.
Personally, I would be more apt to have more usage than less. As Bruce
Perens said in an interview with me previously, its not the generic code
that makes your business sink or swim, it’s the 10% differentiating code
that separates yourself, and allows you to soar. If businesses can spend
more time on the uniqueness of their product rather than on the basic
requirements of any application such as login/ACL/etc, the products
would be
better, and result in far greater usefulness of the tools we use ever
day.
For those that have heard little about Engines and want to know more,
visit:
http://rails-engines.rubyforge.org/
Warmest regards,
Nathan.
Nathaniel S. H. Brown Toll Free 1.877.4.INIMIT
Inimit Innovations Phone 604.724.6624
www.inimit.com Fax 604.444.9942