Archive for May, 2007

More on MySQL AB and the GPL

Wednesday, May 30th, 2007

The other day I linked to this post about MySQL AB and the GPL in a Slashdot comment. As I note in that comment, it appears that the link to the MySQL protocol description has changed.

Anyway, based on some of the responses in that Slashdot thread and in our blog here, I thought I should clarify what I’m trying to say. I have no problem with MySQL using the GPL to license their software. That’s their choice and if I choose to use their product I can’t really complain much about it. I may still prefer to use a database with a less restrictive license since several exist, but I have no issues with the idea of MySQL using the GPL for their database product.

I do have issues with how MySQL AB uses the GPL though. Here is my understanding of what they are doing: They have a document that describes the protocol necessary for a database access library to communicate with the MySQL database. Because the MySQL system is released under the GPL, they claim that terms of the GPL also apply to the protocol itself. As a result, they claim that if you use the document which describes the protocol to implement a library or system which communicates with a MySQL server (or emulates one, etc.), you must abide by the GPL. As far as I can tell, they are attempting to apply copyright (the GPL) to an idea (the description of the MySQL protocol in that document). Again, I’m not a lawyer, but it is my understanding that copyright applies only to manifestations of ideas, not the ideas themselves. That is, they can copyright the code which implements a protocol (which they have, it’s the MySQL database) and they can copyright the text of the document that describes the protocol, but they can’t copyright the protocol itself. If they want to protect the idea itself, they need to patent it. I believe that people who have read this generally agree with me that this is not a valid use of copyright. Am I wrong? If so, how is this valid?

I think we all can agree that this is at the very least questionable use of copyright. I am not sure why they would try to play these games other than to attempt to eliminate less restrictive 3rd party client libraries. I would think that as the company that produces MySQL itself, they should be able to legitimately keep their official client libraries ahead of any 3rd party competitors in terms of performance, reliability, and/or just their ability to offer support. Instead, they have resorted to what looks like misusing copyright. I’ll say this again: why bother with these stupid games when there are better database available like Firebird and PostgreSQL?

My other issue with MySQL AB is just that it appears they do a poor job of educating their users about what their license really means. I guess when they don’t seem to understand what their own license covers, I shouldn’t expect them to be able to explain it to their users. It seems like they are just being intentionally unclear and misleading, rather than being straightforward and honest about the licensing requirements. I admit that this is very subjective. Perhaps the people who commented here defending them disagree. I mean, MySQL AB is free to offer poor and confusing support if they want to. Thankfully, not only am I free to not use their product, but I can also attempt to explain my reasons to others (by whining about it on my blog)!

Posted in Linux | No Comments »

Event System Changes

Wednesday, May 23rd, 2007

I guess it’s a bad sign when you start rewriting the rewrite, but I’m working on some event system changes now that should make the system much more flexible. In our current system, you register a shared_ptr to an “EventListener” to receive events of a particular type. That is ok, but it is a little ugly for a few reasons. Often a class wants to register itself, and getting a shared_ptr from *this is not pleasant. I ended up just having classes that want to register themselves have a separate listener class that they create so that I can easily get a shared_ptr to use (e.g. the IThreadedSubSystem and ThreadedSubSystemListener). That is pretty ugly. It can also be constraining because you either have to code up separate listeners for every event types you want, or do some kind of “if .. else if .. else if ..” to figure out what to do with the event that the listener receives. That is pretty ugly too!

I decided that it would make a lot more sense to just register a boost::function that takes a shared_ptr to the event. That way, you could bind a free standing function, or a member function, or whatever to receive events. Objects could register themselves to receive events without jumping through hoops. However, boost::function objects are not comparable to other boost::function objects, which makes it hard to store them in map.

I have seen boost::signals before. We actually talked about just pitching our EventSystem altogether and just giving each event type a static signal. Then if you care about that event type, you just connect to that signal. That could be nice, but I think having the event system take care of that is a little more clear and makes event queuing a little easier.

Anyway, what I am working on now is actually using boost::signals for the actual event dispatch, but still within the framework of our event system. That allows us to still use boost::functions (which is what drives the signal library), but it has a workaround for the lack of comparisons. When you register an event handler function with the EventSystem, it looks up and if necessary creates the signal. The event handler is connected to that signal and the EventSystem returns a signal “connection”. The user can then disconnect their handler by calling disconnect() on that “connection” object. That could be pretty unwieldy if you wanted to register for 10 event types and keep track of 10 different connections. As a result, I am also creating another class to manage those connections automatically. You just create an instance of this class and then call the “AddHandler” method with the event type and handler object. This manager class stores the event connection and takes care of disconnecting it when it is destroyed. Alternatively, you can call “RemoveHandler” and it will disconnect the connection. I’m not sure what I’m going to call it though. “EventHandlerManager”, “EventConnectionManager”? I know “Manager” isn’t very descriptive, but I can’t come up with anything better. It automates the management of event connections.

That allows us to still have the flexibility of using boost::functions, the actual event dispatch is handled by boost::signals, and as long as you use one of these connection manager objects (and dispose of it properly) the interface should be pretty clean for the user.

Let me know if you have comments, questions, or suggestions for that class name.

Edit 4/29/2009: We finished these changes a long time ago, so I’m removing old dead links.  We went with the name “EventConnectionManager” for the object that automatically hold event handler connections.  Since this post we have also abstracted the event hander registration and dispatching into a new class “EventDispatcher“.  The existing event system inherits from that, and the threaded subsystem class has a dispatcher as well.  The reason for that is so we can ensure thread-safe messages going to the new thread.  A threaded subsystem (e.g. “SoundSubSystem“) has all of it’s events from the main event system come through a single handler which takes care of the thread safety.  Then the message is placed in a queue for the thread to pick up and handle using it’s thead-specific dispatcher.  It’s a little complicated but made the threading for the sound system pretty easy.

Posted in Protocce | No Comments »

AMD open-sourcing graphics drivers?

Tuesday, May 15th, 2007

I saw this story on /. (which links to this blog post) the other day. I’m sure nothing I say will add anything that hasn’t already been said, but I am pretty excited about the possibility of real open-source graphics drivers (for cards that do a little more than the onboard video). Of course, statements by a VP of marketing that are quoted on a clearly non-official blog post are a long way from actually delivering anything at all, so I won’t be holding my breath. I am happy they are talking about it though.

In the past, I have been a pretty dedicated NVIDIA user, I don’t think I have bought a non-NVIDIA card since the GeForce series was introduced in 1999. Their linux drivers are closed-source binary blobs and make life harder than it should be for linux distros. Once you go through the pain to get them set up, they work well and give good performance. Ultimately, as a Linux game developer, that’s what I am looking for. I’m also excited about Noveau and I’m looking forward to trying their driver when it is farther along. However, if AMD provided decent open-source drivers for the ATI cards (or if Intel gets a decent graphics chipset going), I would happily drop NVIDIA without a second thought.

Posted in Linux | No Comments »

Excited about CDT

Monday, May 14th, 2007

So I read this blog post by Doug Schaefer, the CDT project lead. I’ve been reading his blog lately. It’s interesting. Based on what I’ve found in the milestone builds of the CDT (I’m currently using CDT 4.0 M7/RC1) and what I’ve read on his blog, I’m really excited about what they are doing. Performance is way ahead of the released version, and code navigation is getting much easier. For example, F3 to “Open Declaration” works pretty well, although it seems to only work in headers… I haven’t actually tried debugging yet. I’ve been scarred by my previous experiences, but maybe I’ll try that out now. Anyway, if you are a C++ developer in Linux, I’d recommend you check out a milestone build of Eclipse and the CDT.

PS Is it just “CDT” or is it “the CDT”? Anyone know?

Posted in Linux | No Comments »