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}

but what about...

from: mingenthron
date: Feb. 23rd, 2010 08:01 pm (UTC)
Link

I have my own, of course, but I'm curious... what is your opinion on joint copyright? Does that also not put the contributor and the organization behind the project on the same kind of equal footing?

Reply | Thread

Brian "Krow" Aker

Re: but what about...

from: krow
date: Feb. 23rd, 2010 08:24 pm (UTC)
Link

The problem with joint copyright is that depending on the lawyer, it either exists or it doesn't exist.

MySQL for years gave employees joint copyright, but then right before the acquisition Marten announced that it had never existed. When I spoke to lawyers at the time I found that some believed it existed, and some did not.

Even if it did? I think the onus it places on developers is too large, especially when you are dealing with an individual vs a company. The economic imbalance in that relationship really places the developer at a disadvantage.

I once had a Google lawyer go over the Sun contribution agreement with me and point out issues in it. I as a non-lawyer would have never picked up on the nuances that the lawyer pointed out to me. Asking any developer to go through the trouble of retaining council to contribute a patch really is too much to ask for. It is poor table manners at best.

Reply | Parent | Thread

Re: but what about...

from: mingenthron
date: Feb. 26th, 2010 09:09 pm (UTC)
Link

I can see that point of view, but I also know that from time to time, a project sponsor may need to defend the project legally. Doing so would require all parties interested to be a party to the legal action, copyright assignment or joint copyright.

To me, joint copyright (a-la Sun's) or copyright assignment to a trusted entity (a-la Apache projects) always felt like an okay way to do this.

Is it poor table manners? Copyright assignment may be, but joint copyright is not if you're contributing to that project with some kind of trust that the project owner will represent the interests of your contribution and the project as a whole.

As to whether or not joint copyright exists, I can't say. It would seem to make sense to me that I could write something and share my copyright with someone else, if I were to choose to do so. I'm sure you can find litigation on both sides of this issue.

In fact, I bet the discussion you had with the Google lawyer was probably under circumstances where they were trying to keep from agreeing to something like that.

The most telling experience I'd ever had with lawyers was years ago, with a startup, an in-house corporate attorney doing a legal review. He said "this looks like their council just needed to complain about a few things to justify the fees.". I'd never thought about it in those terms before, but almost any time you go to see a lawyer for advice they have to say something... or you'd feel like your time was wasted.

Reply | Parent | Thread

Is it a problem to have mixed copyright?

from: xaprb
date: Feb. 23rd, 2010 10:45 pm (UTC)
Link

Have you ever seen a situation where mixed copyright is a problem? Maatkit currently has a mixture of copyright and my sense is this could be a problem when someone evaluates it for their own use.

Reply | Thread

Brian "Krow" Aker

Re: Is it a problem to have mixed copyright?

from: krow
date: Feb. 23rd, 2010 10:58 pm (UTC)
Link

Multiple copyright notices are fine, and so are multiple licenses in some cases. Its confusing though, and we have avoided it thus far.

Reply | Parent | Thread

webmaven

Virality of the GPL kernel

from: webmaven
date: Feb. 24th, 2010 01:19 am (UTC)
Link

Depending on circumstances, the GPL can also apply to plugins that are not usable except as a part of the GPL system. Does Drizzle's GPL'd kernel have an explicit exception for plugins?

Reply | Thread

Jobin Augustine

Re: Virality of the GPL kernel

from: jobinau
date: Feb. 24th, 2010 06:53 am (UTC)
Link

This is a very serious question and major point of confusion about GPL.

If you go back to other projects in GPL, say Linux Kernel,
any software which devloped on Linux for Linux will be using Linux specific system calls and can be foced to accept GPL.
But things won't work that way.

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.
here the reqirement is, the NON-GPL sofware should only use the published APIs of the GPL sofware and should make sure that NON-GPLed software should not be
doing any changes to GPLed sources.

Coming back to Drizzle's case, same thing applies. a NON-GPLed Pluggin can exists as long as it is just "USING" the API's

I think the best place to refer for more reading is the Linux Kernel copywirte notice itslef.

Thank you,
Jobin.

Reply | Parent | Thread

Re: Virality of the GPL kernel

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

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:

http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLAndPlugins

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)
Link

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)
Link

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
http://www.gnu.org/licenses/gpl-faq.html#OrigBSD
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

A different point of view

from: robla
date: Feb. 28th, 2010 08:07 pm (UTC)
Link

Hi Brian, great food for thought. I'd like to pose a question to you, though: do you think that MySQL would have sold to Sun for $1 billion-ish had MySQL not been the exclusive property of MySQL Inc.? Many, many more thoughts on the subject here:
http://blog.robla.net/2010/thoughts-on-dual-licensing-and-contrib-agreements/

Reply | Thread