First I need to state that ADO.Net is a very good component. It does an excellent job of what it was designed to do. ADO.Net provides an object based representation of a database.

Some the excellent features ADO.Net are:

• DataTables: Provide a memory representation of a database table (or combination of tables). This allows software to directly read and write to the database data. The ADO automatically takes care of concurrency issues.
  
• DataSets: Provide a memory representation of a number of data table and the relationships between the tables. With DataSets the database schema can be represented in an object format.
  
• XML tools: Provides ability to both input and output XML representations of data to and from data sets and data tables.
  
• Serialization: Data sets can be serialized allowing database data to be available via a web service or remote service. This allows for rich clients to have direct access to the database.
  

There is an issue with ADO.Net and Data Sets (summarized in this discussion on wikipedia), but that is not bad part.

The bad part is that ADO.Net falls short of the requirements to properly support Object-Oriented design (OOD). While doing an excellent job of providing an object oriented view of a SQL database, a SQL database itself is not very object oriented. That is ADO.Net provides objects that map one to one to the features of database. In the absence of any other components what typically happens is that ADO.Net is used directly with application code. Even with careful planning it can still result in these bad design practices:

• OOD tenant of encapsulation is violated. What occurs when ADO is used is that many of the SQL database issues are not encapsulated, but brought into the application code.
  
• Complex objects and especially object composition are not used. Databases only support the storage of built-in types. The result is that the application objects that deal with the database data tend not to use software structures such as queues, FIFOs, collections, and references (object composition). Instead application objects use the built-in types almost exclusively and use the database foreign key structures directly, instead of references. In fact the code is likely not to be object oriented at all.
  
• There is significant code that needs to be created that is dedicated to ADO configuration, setting up data tables/data sets, reading and writing to database, etc. This isn't bad code; the bad part is that it needs to be written, tested, deployed and maintained.
  

This results in really ugly application code. This ugly code has a number of nasty features:

• Software and the database must be changed at same time. Typically changing the database schema requires changing the application software. Adding new features requires not only adding the new objects, but insuring the database is also changed.
  
• The issue of versioning the database schema and software needs to be accommodated. For example when new features require database changes there needs to be a deployment process where the existing databases are upgraded. Alternately the software needs to handle both the old and new database schema.
  
• The application code becomes larger than it needs to be in order to handle that lack of true objects in a database. Bugs become harder to fix. New features become more difficult to add. The code just becomes harder to understand because of its size, lack of encapsulation and use of structured programming
  instead of object programmer techniques.
  
  

This begs the question, how should you employ OOD and still use a database? One answer is to use an object-relational mapping technique such as is provided by Hibernate or product such as DB4O that makes a standard SQL database look like an object oriented database. These are good, but have their draw backs. Fortunately there will shortly be solution from Microsoft that extends ADO.Net called ADO.Net Entity Framework. It may not solve all the "ugly code" issues and will certainly have some drawbacks, but is very promising. We are excited by it.

The ADO.Net Entity Framework is a very attractive solution since it is not only provides an object-relational mapping service, but will provide Query support using LINQ as well as integrating tightly with Visual Studio. This is great, but in my opinion the biggest advantage of the Entity Framework is that it allows new, and even ongoing, software projects to use OOD while using existing databases, existing database tools and practices. In other words the substantial investment in databases can be protected, while building OOD software to exploit it.

There are lots of open source licenses in existence. Some are general purpose and some are very specific. Our favorites are BSD and GNU GPL. Many of the other open source licenses are variations of these 2 classics.

BSD is the most permissive of the 'open source' licenses. When software has a BSD license it is practically in the public domain. The only real requirement of the license is a citation provision where if BSD software is incorporated into another product, its usage must be acknowledged. Other than that provision BSD licensed code can be incorporated into other products with no restrictions. As software developers we have no qualms about using BSD licensed code.

GNU license is a little more restrictive. If you use a GNU GPL application, for example to build a web site, it is free. It is free even if you make money from the Web site. If, on the other hand, you incorporate GNU GPL code in your product you must make your product GNU GPL licensed as well. For products that are developed for profit this is a very restrictive requirement. This is why most GNU software is also available with a commercial license allowing incorporation into proprietary products. Jetfire is available with a GNU General Public License as well as a commercial license. Here is an excellent article on GNU vs commercial license.

For us when we ship a product with a BSD license we want it used everywhere. One of our goals is to get consulting revenue from customers who want special features. Another goal is to release other products that rely on it. For example Jetfire WebParts operate on top of our BSD licensed COR product. Our primary goal; however is to get attention from delivery of a valuable, quality free software product. In we effect advertising our capabilities.

When we license a product with GNU our strategy is to get is used everywhere as well, but with the twist that if it is used commercially we are also looking for revenue. We are willing to sacrifice some usage that a more permissive license would afford in return for getting revenue. Many non-commercial applications will pay for the commercial license simply to get enhanced support.