This is quite the discussion thread. I was having a hard time trying to figure out where to insert the post.
Let me introduce myself. I am Leon Katsnelson and I am responsible for Product Management for the IBM Data Management portfolio which includes DB2 and IDS database servers as well as Data Studio to mention just very few products. In other words, if there is anything that is wrong with our approach you can blame me and leave poor Alex and Antonio be. They are really good developers who thrive on technology and have been pushing us to fully embrace Django. Let me get right to the genesis of this thread. Will IBM be releasing commercial grade Django driver for its databases? I can't say this in an open forum. I can however confirm that we have been watching Django with a great deal of interest as part of our overall commitment to support of the scripting languages (PHP, Ruby, Python, Perl etc.). So, if you follow what we have done with Ruby on Rails (DB2onRails.com) it is a definite maybe :-) A bit to the method to our madness. As you would expect IBM provides solutions to corporations large and small and what we provide is commercial software. IBM is a very big contributor of Open Source but our business is "commercial" software. The lines between commercial software and open source do get blurry from time to time as is the case with DB2 Express-C (www.ibm.com/db2/express) for example. This is a product that follows open source business model i.e. free license with availability of inexpensive support and extra features. However, DB2 Express-C is not open source. For most of our corporate customers this is very important as they have restrictions on the use of open source. I am not hear to argue the wisdom of having such restrictions, I am simply stating the fact. One of the reasons (there are more) many corporations have such restrictions is lack of "indemnification". In other words, they don't like acquiring a product and getting it used within their infrastructure and than finding out that they are a target of a law suit claiming that they have misappropriated some IP. If you think it does not happen just look at the case of SCO suing Diamler-Chrysler over Linux. This does not happen to individual developers and budding start-ups but if you are a large company with a lot of money things are different. It is like you have a bulls eye painted on your corporate logo and it is in the cross sight of every IP lawyer who thinks he/she 1% chance of even having a semblance of a case. it is sad that we live in such a litigious society but it is a reality of IP law. When IBM provides commercial software we guarantee its pedigree. Before we ship any software we put together a Certificate of Originality. This is one of the processes we have to ensure that all of the code we are shipping to our customers was either written by IBM employees and IBM has full rights to it or if the code came from some place (e.g. open source) we are absolutely sure we have the rights to use it. I am simplifying things a bit but this is the essence of the due diligence of what we must do. If you read so far you should get an idea by now that for IBM developers taking an existing Django adapter and just creating one for DB2 or IDS is not a simple proposition. That is not to say that we do not leverage open source in IBM development; we do. But we do it with great care. Yes, Django has is a fairly liberal license that would allow us to do this i.e create what lawyers call "derivative work". And thankfully it is not a viral license that would force us to open source the entire product (DB2 or IDS) that would ship the adapter. For us to look at Django code we need to be sure that we understand the pedigree of that code so we inadvertently don't infringe on some third party rights. For example, the code in the Django adapter could have had contributions from someone who has not explicitly assigned the rights and may not wish to have IBM use this code. Maybe this person expects to be compensated for their contribution if a company like IBM was to benefit from it. Again, this is not a hypothetical scenario. This happens quite frequently. The way we and other protect ourselves is by coding to a publicly available specification. If there was such a spec for Django database interfaces it would make it a lot simpler for us to commit to developing a Django adapter for IBM DBMS. My reason for making this post was to explain the need for a spec. I am not hear to argue the wisdom of IBM practices; this is way out of my domain of responsibility. Yes, we can read the "Dutch pseudo-code" but we need to make sure that when if someone launches a lawsuit we can clearly demonstrate that there are no lines of the pseudo-code found their way in to IBM-supplied code. That is a lot more difficult to do with the "Dutch pseudo-code" than with English. And it is really difficult to argue with or our lawyers that the code we were looking at is really a spec. Our developers will have to indicate that they looked at the 3rd party code and not a spec and that is pretty much where things will end i.e. no certificate of originality and no ability to ship the product. On Mar 20, 10:11 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > *sigh* > > On Thu, 2008-03-20 at 06:20 -0700, jeffself wrote: > > My employer currently uses DB2 for its database. Antonio Cangiano > > recently mentioned that IBM has written a DB2 driver for Python. This > > driver uses the SQLAlchemy ORM. I asked him if IBM had any plans to > > write a driver that would work with Django and here is his response: > > > "The API team (which currently maintains all the dynamic language APIs > > for DB2) considers the Django adapter a priority. > > Such a priority that they've never brought this request to us in the > past. Guess that's why the word "high" wasn't used in that sentence. :-) > > > Due to IBM's strict > > rules in terms of open source participation though, the developers > > can't simply look at the code of the other adapters (not even the > > dummy one) and adapt it for DB2. Therefore, in their case, the lack of > > a public spec, that outlines method by method the requirements for any > > new Django ORM adapters, is the biggest obstacle. If such a document > > was freely published on the web (without restrictions), > > Except for copyright and normal open source licensing requirements, > presumably. > > > the API team > > could come up with a Django adapter for CPython and for Jython in a > > short amount of time." > > > Are there any plans to implement a public spec? > > Well, there already is a spec. It's written in Python, which is mostly > Dutch pseudo-code rather than colloquial English, but it's fairly well > commented and the method names are sensible. Interestingly that's > enough, for example, for IBM's kernel developers, who regularly read > other parts of the kernel when constructing their APIs and driver > contributions. > > Still, there's no accounting for some people's wish for paperwork. The > best way to continue would be for you to write up something based on the > current backends, send it here and we can review it. It's probably > something that would fit nicely alongside DevModelCreation in the wiki > and would be nice to have just for documenting how things work. We could > tidy up the DeveloperDocs page and promote it to "official" in some > sense. There'll probably be a bit of back-and-forth needed after the > first version to work out which features really are to be relied upon, > but certainly stuff in django/db/backends/__init__.py is going to be > pretty much an accurate representation of the state of play at the > moment. In fact, that file shows precisely how much duplicated effort > this "specification" requirement will require: it's got all the methods > you need, a honking great docstring on almost all of them -- adding > docstrings to the remaining ones will be easy and satisfy, say, Ivan's > requirements I would thinking -- and is laid out in a fashion that a > competent Python programmer can scan and implement really fast. > > Regards, > Malcolm > > -- > The early bird may get the worm, but the second mouse gets the > cheese.http://www.pointy-stick.com/blog/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
