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}

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