# Engine Licensing, an encouraging perspective on why to start

**URL:** <https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341>\
**Category:** Rails\
**Created:** [November 17, 2005, 7:13am UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341 "2005-11-17T07:13:32Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 17, 2005, 7:13am UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/1 "2005-11-17T07:13:32Z")

</div>

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/](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](http://www.inimit.com) Fax 604.444.9942

---

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 17, 2005, 3:05pm UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/2 "2005-11-17T15:05:17Z")

</div>

As far as I know, _none_ of the “open source” licenses have _ever_ been  
tested in a court of law. So the so-called “rights” one has when one  
“uses” the GPL, either by granting it or accepting it, may not in fact  
exist.

In short,

a. You are free to give away your own intellectual property, as long as  
you realize that someone might come along, as SCO did, and claim it was  
not yours to give away, requiring you to spend money defending yourself.

b. You are _not_ free to give away someone else’s intellectual property,  
even if you didn’t know at the time you did that it was someone else’s.  
_You_ are obligated to do the research.

c. Many corporations view the GPL as a _contaminant_ in their releases  
as a result of a. and b. – having any GPL software in close association  
with their proprietary software exposes them to _huge_ financial and  
legal risks.

So … once we’ve sorted out all the intellectual propery issues  
associated with the GPL, we can move on to the more interesting  
questions about how viable business models are that blur the rather  
sharp distinction, at least in the USA, of for-profit (Red Hat) and  
not-for-profit (Fedora Foundation) organizations. And yet another  
interesting question – when will some for-profit organization “adopt”  
the two major not-for-profit distros, Debian and Gentoo?

I’m sure DHH has all this worked out for Rails and the projects he built  
upon Rails and abstracted Rails from. But how about larger projects? I’m  
embarking on some Rails and Ruby projects, one of which will in fact be  
a “commercial” one. DHH, any comments on the GPL – and the Ruby  
license, which differs from the GPL in some subtle ways I don’t  
understand?

I was originally planning to base it on an existing package (running on  
the LAMP stack) which does _exactly_ what I want, but the prospect of  
having to teach a lawyer programming wasn’t particulary exciting. I may  
still use that package because it’s well known and they’ve established a  
partner program with commercial users. But I’m leaning towards doing  
something a lot simpler based on Rails and sqlite.

–  
M. Edward (Ed) Borasky

> **[世界杯竞猜彩票-世界杯官网竞猜（集团）有限公司](http://www.linuxcapacityplanning.com/)**
>
> 世界杯竞猜彩票一直以来遵守商业道德，世界杯官网竞猜坚持诚信为本，保证诚实经营。世界杯竞猜彩票先后成为安徽省电子商务协会理事单位、安徽省网商协会会员单位、合肥市电子商务协会理事单位、合肥市服务外包行业协会会员单位、安徽省云计算产业促进会会员单位。世界杯官网竞猜一直保持良好的技术及服务态度，更好地为客户服务。

---

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 17, 2005, 3:41pm UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/3 "2005-11-17T15:41:28Z")

</div>

M. Edward (Ed) Borasky wrote:

> As far as I know, _none_ of the “open source” licenses have _ever_ been  
> tested in a court of law. So the so-called “rights” one has when one  
> “uses” the GPL, either by granting it or accepting it, may not in fact  
> exist.  
> 'Fraid they do.

> **[German court enforces GPL](https://www.theage.com.au/national/german-court-enforces-gpl-20040420-gdirvl.html)**

Translation of the ruling:

> **[OIIFB\_GPL2\_20040903.pdf](https://www.oii.ox.ac.uk/wp-content/uploads/old-docs/OIIFB_GPL2_20040903.pdf)**
>
> 134.30 KB

> I’m sure DHH has all this worked out for Rails and the projects he built  
> upon Rails and abstracted Rails from. But how about larger projects? I’m  
> embarking on some Rails and Ruby projects, one of which will in fact be  
> a “commercial” one. DHH, any comments on the GPL – and the Ruby  
> license, which differs from the GPL in some subtle ways I don’t understand?

(I know I’m not DHH, but still…)

Surely the Ruby licence is irrelevant? It’s the Rails licence which is  
relevant, and that’s MIT-licenced, so you can do almost anything with  
it.

The GPL is even _less_ relevant, because there’s nothing essential in  
the stack that requires it, and anything brought in would be clearly  
identified as such.

The main difference between the GPL and the Ruby licence that I could  
see was that you’re allowed to distribute your modified binaries without  
the source.

---

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 17, 2005, 4:02pm UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/4 "2005-11-17T16:02:40Z")

</div>

On 17.11.2005, at 16.03, M. Edward (Ed) Borasky wrote:

> I’m sure DHH has all this worked out for Rails and the projects he  
> built upon Rails and abstracted Rails from. But how about larger  
> projects? I’m embarking on some Rails and Ruby projects, one of  
> which will in fact be a “commercial” one. DHH, any comments on the  
> GPL – and the Ruby license, which differs from the GPL in some  
> subtle ways I don’t understand?

It’s not subtle ways, it’s indeed quite fundamental. So, in David’s  
own words [1]:

One of the stances we have taken with Ruby on Rails is to release the whole thing under MIT license, which basically just says: â??You can do whatever you want, just donâ??t sue us.â?

So the difference is that GPL says anything derived from that code  
will have to be released under GPL, too. There is no such restriction  
in BSD or MIT licenses.

//jarkko

[1] [http://jlaine.net/blog/83/interview-with-david-heinemeier-hansson](http://jlaine.net/blog/83/interview-with-david-heinemeier-hansson)

---

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 19, 2005, 11:37pm UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/5 "2005-11-19T23:37:13Z")

</div>

Alex Y. wrote:

> [German court enforces GPL](http://www.theage.com.au/articles/2004/04/20/1082395838556.html?oneclick=true)

This is behind a registration page, so I can’t read it without giving  
away private information. So … I’ll take your word for it.

> Translation of the ruling:  
> [http://www.oii.ox.ac.uk/resources/feedback/OIIFB\_GPL2\_20040903.pdf](http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL2_20040903.pdf)

That was a little more interesting. Of course, it appears to have been  
in a German court, not one in the USA. I’m curious how the German courts  
deal with the issues of MP3 royalties. 🙂 So … yes … the GPL _has_  
been tested and apparently upheld in _a_ court of law, so I stand  
corrected.

> Surely the Ruby licence is irrelevant? It’s the Rails licence which is  
> relevant, and that’s MIT-licenced, so you can do almost anything with it.

I’m not sure the Ruby license is irrelevant, since the product must, to  
be a product, not have external dependencies. In other words, I can’t  
package a Rails app and say to a customer, “This is my product – you’ll  
have to install Linux, Apache, MySQL and Ruby and agree to their  
licenses before you can use it.” MySQL is rather irrelevant; I don’t  
like their license and will either use SQLite or PostgreSQL, depending  
on the database requirements. And Apache will be irrelevant if WEBrick  
will do what I need – and I’m guessing it will.

So that means at a bare minimum, to deliver a complete application, I  
need to package my application, Rails and Ruby, probably in a Windows  
and Linux form. I don’t have a Mac to test on and I don’t have the funds  
to get one. So the Ruby license is very relevant in this case.

> The GPL is even _less_ relevant, because there’s nothing essential in  
> the stack that requires it, and anything brought in would be clearly  
> identified as such.

Well, Linux for one is GPL :). As long as I don’t have to “package”  
Linux, for example, by distributing my application as a LiveCD, I guess  
the GPL is irrelevant. But … I’m seriously considering exactly that –  
a LiveCD. So … guess what? The GPL _is_ relevant! 🙂

> The main difference between the GPL and the Ruby licence that I could  
> see was that you’re allowed to distribute your modified binaries without  
> the source.

Thanks! I’m not sure I need to distribute “modified binaries”, although  
for the Windows users, I’d be a non-starter if I required any  
compilation steps for a user. So there would be binaries in that case.

–  
M. Edward (Ed) Borasky

> **[世界杯竞猜彩票-世界杯官网竞猜（集团）有限公司](http://www.linuxcapacityplanning.com/)**
>
> 世界杯竞猜彩票一直以来遵守商业道德，世界杯官网竞猜坚持诚信为本，保证诚实经营。世界杯竞猜彩票先后成为安徽省电子商务协会理事单位、安徽省网商协会会员单位、合肥市电子商务协会理事单位、合肥市服务外包行业协会会员单位、安徽省云计算产业促进会会员单位。世界杯官网竞猜一直保持良好的技术及服务态度，更好地为客户服务。

---

<div class="post-metadata">

**Author:** ![nshb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/df788c/32.png) [@nshb](https://www.ruby-forum.com/u/nshb)\
**Post date:** [November 20, 2005, 6:54pm UTC](https://www.ruby-forum.com/t/engine-licensing-an-encouraging-perspective-on-why-to-start/49341/6 "2005-11-20T18:54:30Z")

</div>

M. Edward (Ed) Borasky wrote:

> Alex Y. wrote:
> 
> > M. Edward (Ed) Borasky wrote:  
> >   
> > 'Fraid they do.
> > 
> > [German court enforces GPL](http://www.theage.com.au/articles/2004/04/20/1082395838556.html?oneclick=true)
> 
> This is behind a registration page, so I can’t read it without giving  
> away private information. So … I’ll take your word for it.  
> That’s funny… I got to it from a google search. I’ll see if I can  
> dig it up again, but it’s only a brief piece about the ruling below.

> > Translation of the ruling:  
> > [http://www.oii.ox.ac.uk/resources/feedback/OIIFB\_GPL2\_20040903.pdf](http://www.oii.ox.ac.uk/resources/feedback/OIIFB_GPL2_20040903.pdf)
> 
> That was a little more interesting. Of course, it appears to have been  
> in a German court, not one in the USA. I’m curious how the German courts  
> deal with the issues of MP3 royalties. 🙂  
> Funnily enough…  
> [http://www.toytownmunich.com/lofi/index.php/t19284.html](http://www.toytownmunich.com/lofi/index.php/t19284.html)

> I’m not sure the Ruby license is irrelevant, since the product must, to  
> be a product, not have external dependencies. In other words, I can’t  
> package a Rails app and say to a customer, “This is my product – you’ll  
> have to install Linux, Apache, MySQL and Ruby and agree to their  
> licenses before you can use it.” MySQL is rather irrelevant; I don’t  
> like their license and will either use SQLite or PostgreSQL, depending  
> on the database requirements. And Apache will be irrelevant if WEBrick  
> will do what I need – and I’m guessing it will.  
> I really don’t follow your logic here. All products have external  
> dependencies. You certainly _can_ package a Rails app and say “You’ll  
> need a functional Ruby stack before you can use it,” in exactly the same  
> way as you can say “Here’s a word processor. You’ll need a functional  
> version of Windows before you can use it.” Any software has a licence  
> agreement attached to it. If you’re selling a word processor, you’re  
> insisting that the user must have agreed to the licence for the  
> operating system it runs on, be that a BSD licence, the GPL, or a  
> Windows EULA.

If installing the stack is not something your customers are willing to  
swallow, you can either package the whole stack, meeting the licence  
requirements of each of the parts in turn, or host it for them and  
sidestep the entire licensing issue completely. It’s not your customer  
that would have to agree to the licences of (to take your example)  
Linux, Apache, MySQL and Ruby, unless you’re planning on allowing them  
to redistribute your work. The GPL explicitly excludes any claim over  
running the code, and only covers distribution. The Apache licence is  
similar, but the exclusion is implicit. MySQL is private-licenced, but  
PostgreSQL is BSD-licenced, with no use restrictions, SQLite is public  
domain, and Ruby gives you the option to use the GPL rather than its own  
licence - but that makes no claims over use restriction either.

> So that means at a bare minimum, to deliver a complete application, I  
> need to package my application, Rails and Ruby, probably in a Windows  
> and Linux form. I don’t have a Mac to test on and I don’t have the funds  
> to get one. So the Ruby license is very relevant in this case.  
> That’s a different question to the one I was considering. The question  
> was: “Given this third-party generator/plugin/engine/whatever, can I  
> continue to distribute my application under my current licencing scheme  
> if I include it in my code?” As far as I could tell, that was the  
> perspective of the original posting, and is completely independent from  
> the licence of anything lower down in the stack.

> > The GPL is even _less_ relevant, because there’s nothing essential in  
> > the stack that requires it, and anything brought in would be clearly  
> > identified as such.
> 
> Well, Linux for one is GPL :). As long as I don’t have to “package”  
> Linux, for example, by distributing my application as a LiveCD, I guess  
> the GPL is irrelevant. But … I’m seriously considering exactly that –  
> a LiveCD. So … guess what? The GPL _is_ relevant! 🙂  
> Note my careful choice of words… There’s nothing _essential_ in the  
> stack that requires it. Linux can happily be replaced with a non-GPL’d  
> OS, even for a LiveCD. But seriously - is it really that hard to meet  
> the conditions of the GPL? Bear in mind that it can apply to all levels  
> below your code, and leave you with room for an entirely separate  
> licence for your application code.

> > The main difference between the GPL and the Ruby licence that I could  
> > see was that you’re allowed to distribute your modified binaries without  
> > the source.
> 
> Thanks! I’m not sure I need to distribute “modified binaries”, although  
> for the Windows users, I’d be a non-starter if I required any  
> compilation steps for a user. So there would be binaries in that case.

And if you’re supplying unmodified binaries, you need to supply the code

- or at least tell the user where they can find it. In Ruby’s case, all  
you’ve got to do is include a link to [http://www.ruby-lang.org](http://www.ruby-lang.org) somewhere  
in your documentation, and include copyright attribution. That’s it.  
You don’t even need to include the source code. That would also cover  
anything under the GPL, by a certain reading of clause 3b.

That ended up longer than I intended 🙂
