Tuesday, October 18, 2011

Contributor Agreements, Open Stack's Contributor

I have not been a fan of the Open Source Contributor agreements that have been used for the last two decades. All of them tend to have an onerous bit whereby a developer has to hand over the copyright to a group, organization, or company.

I’ve never felt like this is a very honest exchange. With MySQL you were handing over copyright to a company that was making money off your work. With the FSF I have always been bothered by Richard’s insistence that FSF has the right then to take that code and relicense it. His stance on dual licensing under commercial licenses is my issue with this.

The Open Stack contributor’s agreement is a bit different then much of what we have seen thus far. It basically states, and please keep in your mind firmly that I am not a lawyer, that you have the right to submit the code you are submitting. It states directly that you can do whatever you want in the future with the code you wrote.

It is not Apache specific. I don’t see any reason why it couldn’t be used with a GPL project as well.

It is worded such that the group that the code is contributed too couldn’t just take your code, and then hold the contribution hostage. By hostage I mean that the contribution would sit in a limbo where you couldn’t do anything with it, and would therefor be at the mercy of the new owner of the code publishing it.

The GPL, BSD, Apache, MIT, and other licenses where a watershed in their time. Lawyers learned the licenses, and each of these licenses have been “debugged”.

Every time a company sees a new license, or a new legal agreement, there is a huge bar that must be met before it can be signed.

If you are an engineer, think of lawyers as a picky c++ compiler. Some lawyers issue better warnings then others. Some organizations turn the compiler flag “all warnings to error” on. Other organizatiosn not only do this, but add they add in -Wextra for good measure.

We have software licenses, the OSI stamped out quite a few of these.

What is missing then?

  • Agreements for developers who are on advisory boards. 

  • Contractor agreements that carve out open source projects such that they don’t become entangled with “work for hire”. 

  • Contribution agreements.
Take a look at the Open Stack contributor agreement. Could it be used as a standard for open source contributions?

Where is the advantage in using it? We already have a long list of companies who signed it for Open Stack. It has been debugged, and a number of large companies are willing to sign it.

Thursday, September 29, 2011

Spoon full of Sugar, Oracle and the Open Core Model

From the 451 Group:
“MySQL flirted with the open core licensing model in early 2008 with plans to introduce new features into Enterprise Edition that would not be available under an open source license.”



MySQL didn’t flirt with, it was going to do it. 



Why? Because we were asking the question, “how do we pull in customers to make more money”. 



MySQL was going to put the new backup API, which never materialized, into an Enterprise branch. 



It was a lousy idea for the following reasons:



1) There was no internal API in the server for this, so the engineering was going to be messy and expensive. 



2) We didn’t own the technology that was needed to even do this (Oracle owned Hot Backup)



3) Percona has an awesome tool for doing this, that is Open Source (http://www.percona.com/software/percona-xtrabackup/)



4) Backup is a core feature everyone needs, and some of those “everyones” are the folks who manufacture tools that you want to have work with your product.



5) When we were going to announce it, we hadn’t even written it/completed it. It was vaporware. 



It would have been a horrible move, and would have caused Chaos for no particular reason. It was dead on arrival, and when it was to be announced as a strategy since it didn’t even exist. 


Lets look at Oracle’s move. Both the authentication module, and the Thread Pool come into the MySQL server as plugins. If the engineering of the MySQL server continues in the current direction (which is somewhat flattering to Drizzle I might add), then they are on a good path (if I can find my blog entry where I talked about this as a good strategy, I’ll link back to it here). 


Much of the hubbub around Open Source, Community, etc, in regards to this are a bit inflated I feel. They haven’t touched the core product, and they are creating API. Are they possibly hurting themselves in regards to ubiquity?


Doubtful. 


Would I pick those two pieces? No, but they aren’t the last two I would pick either.  If Sun had continued as a company? Something similar to this would have been done as well.


From an engineering and usage stand point?


The first person who sniffs at the authentication mechanism who knows anything about security is going to freak.


The Thread Pool can only be used by a very limited number of users (and there are some restrictions on what can be done in the server while it is in use). MySQL’s IO was never designed for the Thread Pool, and there is a lot of engineering work that would need to be done to make it work. 


Still? People will use both, and I am betting some customers will want them badly enough to pay. 


If they are really badly needed? Well then someone will write an open source version of both.


I have no great love of Oracle, but this is really not a big deal at all. The original GPL’ing of the Public Domain/LGPL clients was a much bigger deal.

Thursday, September 22, 2011

memcached_exist()

New in version 0.53 (which yes, I really should renumber into 1.X at some point in the near future) is memcached_exist(). 


Ever wanted to find out if a key existed but didn’t want to have to fetch the object?


Well now you can do this. It works by seeing if an add can be done on the key (the add though is dated in the past, so any write afterward will expire it).


You can currently grab the code via bar on Launchpad.


Have fun! 

Monday, September 12, 2011

Friday, August 5, 2011

Thursday, August 4, 2011

C/C++, #Ifdef, working around the need for them

Consider the all to common code:



#ifdef HAVE_SOMETHING


something();


#endif



ifdef are problematic because any number of combinations of them can lead to multiple execution paths that the compiler never will so. PIA


The above assumes that HAVE_SOMETHING will have some value or not. 


Another option is the following:



if (HAVE_SOMETHING)


{


  something();


}


The significance in the above?


Any good compiler will evaluate HAVE_SOMETHING, and if the value is zero then the code path will be optimized out.


Awesome.