So, if you want to contribute code to Tungsten (I'll describe shortly why you might to do that), you first fill out our handy Code Contributor Agreement and send it to us. The CCA says that you grant us rights to use the code within Tungsten as if we had written it ourselves, which includes selling it in licensed versions of Tungsten. At the same time, you retain your rights to the code and can also use it for any purpose you please including donating it to other projects, selling it, licensing it commercially, etc. It is really a very simple agreement. We also plan to match further protections to contributors as Monty.org adopts them.
After you send us the CCA, you can send us patches. Why would you want to do so? Recall that Tungsten allows you to create database clusters that protect you from data loss, failover quickly to replicas, and scale performance by spreading work around multiple data copies. Here are just a few ways you can help Tungsten do that better:
- New types of backups. Anybody want to add built-in backups using InnoDB Hot Backup? How about storing backup files on Amazon S3? Note: The second project is very high up my personal list so you'll need to hustle.
- Replication event filtering. Our forums see regular discussions about filtering (like this one). What about a handy filter to remove specific databases, tables, or columns when moving data from masters to slaves?
- Support for new databases. Anybody need to replicate from MySQL to Amazon SimpleDB? How about Drizzle or PostgreSQL?
- Sharding. Anybody need to connect transparently to databases spread across multiple shards? You can do it by extending SQL Router load balancing.
- Fixing things that are broken.
Speaking of patches, we got an initial contribution to implement replication from MySQL into Drizzle earlier in the summer. Now that we have all the licensing paperwork in order it's time to get that one properly integrated.
4 comments:
Hi Robert
I remember you were at the Community Leadership Summit, but I don't think you were in the session we talked about MySQL. We got a few comments there that assigning copyrights to a project where the receiver is dual licensing it (for money) is an "unbalanced" relationship. I don't personally see that as a big problem, even so, we ended up with the following solutions in the discussion:
1) MySQL Ab actually used to pay for sufficiently valuable contributions. (But I wouldn't recommend this as a rule!)
2) A contributor agreement could include a clause that any product that incorporates the contribution (the specific lines of code contributed, not the whole GPL product it is going into) is guaranteed to be available at least under an Open Source license (such as GPL). Ie the receiver could not create a "premium version" that is closed source - he would have to remove the contributed lines of code.
For MariaDB we cannot do 2, since we want to keep the door open to be compatible with Sun/MySQL. I also think it is problematic for someone doing dual licensing - it could be interpreted to stretch also to the proprietary products your product is embedded in, thus defeating the whole point of having a contributor agreement.
Other than that, it is a fair suggesting, just that it doesn't work :-)
Hi Henrik!
I don't think [joint] copyright assignment per se is unbalanced. It's a reasonable compromise so that projects don't become entangled in ownership issues as they add contributions. I guess that's not a surprising perspective given that I'm on the "producer" side in this case.
Can you explain why #2 interferes with Sun/MySQL compatibility? That's an interesting issue.
We cannot promise anything on behalf of Sun. To be able to pass the code up to Sun, we also cannot promise anything that Sun hasn't promised already. So for instance, Sun quite likely could want to do - say closed source backup modules - just to take an example from history. Then they couldn't accept our code. Our current thinking is, we want to keep that door open, so we can't start making any additional promises and "hope" that Sun (or Oracle) will accept anything Monty has promised someone.
For the additions Monty have done to the SCA - and we could do that for #2 - they are binding promises for Monty Program, but otoh the contributor agreement doesn't require us to pass on any such requirements to a 3rd party that we can license the code to under any kinds of terms. So yes, we could give such a promise for Monty Program, but then that can be circumvented by us licensing the code to a 3rd party (such as Sun/MySQL) that can do all the things we promised not to do.
So in summary, we could promise #2 for us, but we can't promise that will be true for all downstream places the code will find its way. (sorry, it's midnight, I'm not sure if I made it any clearer...)
Your explanation was very helpful. Tungsten does not have the same issue as there is no relationship with another code base. The additional contributor promises are a very interesting issue that I look forward to working on together.
Post a Comment