Drizzle, Licensing, Having Honest Conversations with your Community

« previous entry | next entry »
Feb. 23rd, 2010 | 09:27 am

I pulled this from a quote on yesterday's Slashdot story about MySQL Licensing where the author of the quote mentions Drizzle's licensing terms:

"you require the code to be under BSD"

This is actually a myth, we don't.

If you look through the Drizzle codebase you will note that very few files have BSD headers, and all that do?

They are a part of new systems that have been written since the fork of the project, and not all of these are BSD.

Why is this?

A large part of Drizzle is derived work from MySQL, and in all cases there we inherited its GPLv2 license on files. Bug fixes and code refactoring projects all fall under the umbrella of "derived work". In all of those cases the work was made under the GPL but no copyright assignment ever occurred. To understand ownership there you would need to look at the revision history to the code. We have never made any effort to track anything more then "where did the code come from".

I am a big opponent of copyright assignment in open source. How do you have an honest conversation with someone where you say "yes, I will need the work you did for free, to be assigned over to me, so that I can make money on it"?

Or better put:

"Here is $100 for the code you did, would you like some trinkets and beads to go along with that?"

We never did copyright assignment for Drizzle, and in no other project I have run personally have I ever done it. It is not a conversation I can have with a straight face with anyone. If you need commercial rights to your work and you want to do a true "quid pro quo"? License your code under the BSD license in the first place, that way both you and the contributor are on equal footing.

Does this mean we are a free for all when it comes to code? No, we track ownership. We know where every single line of code came from thanks to bazaar. If someone wanted to "poison" the codebase we would know exactly who that was. We would point the copyright owner to the offender, remove the code, and help with the prosecution of said individual. We have an active discussion going on at the moment about the future of our copyright headers, and one option we are considering is just replacing the copyright owner notice with a "Please see revision history for complete ownership information".

Are all of the files in Drizzle GPL? No, we do have some which are BSD.

I am a big fan of the BSD license and I typically suggest to developers that they use it for certain projects. As a license it links well with other code, and by establishing new plugins as BSD the original author can pull from any bug fixes that are made to the code. As an example Patrick Galbraith established the built in drivers that allows Drizzle to speak with Memcached. He has pulled code from the Drizzle driver and used that for his MySQL drivers. If those drivers had been done as GPL he would have not been able to pull code back into the MySQL Memcached drivers (which are BSD).

The GPL works just fine as the license for the kernel of Drizzle. I don't see that changing. In discussions with the other core authors, there has never been a push to "rewrite" the entire internals just to change the license. It is more work then it is worth, and it is not needed. The micro-kernel design means that going forward most of the work is pushed out to the libraries that link us to other systems. Work in the kernel is all about making those interfaces robust and creating more opportunity for plugin writers.

A final note on licensing and direction.

We never had any ambition to aim Drizzle at the deeply embedded market. Taking Drizzle, compiling it into a library, and linking it against another application is not a goal that the core team has ever had. If we had ever wanted to go into the world of deeply embedded databases we would have needed to have done code assignment or switched the entire license of the program.

In the deeply embedded world SQLite reigns supreme. SQLite does an awesome job in that space, and we see zero reasons to go head to head with it. If I needed a deeply embedded database I would just use SQLite, I wouldn't bother to write a new one.

Drizzle's core will stay GPL, and we continue to take contributions without code assignment. If you are a programmer I believe you can appreciate the merits of why we do this.

If you are a developer and you find yourself in the peculiar position of being asked to sign over your work? I would encourage you to take a hard look at why this is being asked, and see how comfortable you are with the value you are getting in return for your work.

Link | Leave a comment | Share

Comments {11}

Re: Virality of the GPL kernel

from: http://www.lenzg.net/openid/
date: Feb. 24th, 2010 08:48 pm (UTC)

So this is the rule:
if a sofware is just "USING" the api's provided by another sofware, it is not considered as a "derived work" and need not comply with GPL.

Actually, the FSF has a different view on that:


If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in?

It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Reply | Parent | Thread

Re: Virality of the GPL kernel

from: anonymous
date: Feb. 25th, 2010 06:08 am (UTC)

That's an argument that says that programs using the Windows API are derived works of Windows and that argument is not viable without upsetting the most profitable operating system market for developers on the planet. It's also challenged by the existence of Wine and posix.

Reply | Parent | Thread

Jobin Augustine

Re: Virality of the GPL kernel

from: jobinau
date: Feb. 25th, 2010 09:29 am (UTC)

very well pointed.
that is exactly the the confusion point in GPL.

Same discussion point came infront of Linux Kernel team from initial days.
that is why i posted : "using Linux specific system calls and can be foced to accept GPL"
But things didn't went that way.
Now you know, there exists even binary-only and propritory drivers/modules for Linux.
and but still the debate continues...
in effect, this rigidity of GPL is diluted... and tested by time.

Coming back to Drizzle's kernel legal validity as it is GPL.
Even if we consider the worst case situation, Drizzle is in a much safer place because:
1. Currently all plugins of Drizzle are GPL or BSD.
BSD current version is considered GPL compatible licence.
(quoting from FSF, "plug-ins must be released under the GPL or a GPL-compatible free software licens")
further clarified here : http://www.gnu.org/licenses/license-list.html
2. GPL does not prevent privilage of the copywrite owner of the plugin to relase his code under muliple licences (say GPL and BSD).

so i don't see any legal issue as of now in Drizzle.

now if we look at real world legal issues reported so far related to GPL, most of the are of single kind.
"This is a GPL sofware or derived work. but sourcecode is not published and not avilable"

Reply | Parent | Thread