Its possible my earlier post was…a bit much. Probably being frustrated all day means I shouldn’t post at 1:00 AM.

I still believe that these INs are a terrible idea. They serve to make my life more complicated and its a very “corporate” way to control your products compared to the Open Source methodology of choice.

I’m drawing comments. I’ll take that as a good sign. To correct myself and respond to a few comments, is this IN thing a form of DRM? Wikipedia defines DRM as

an umbrella term that refers to any of several technologies used by publishers or copyright owners to control access to and usage of digital data or hardware, and to restrictions associated with a specific instance of a digital work or device.

Assuming that Wikipedia is fairly accurate here is there a case we could compare this to DRM? INs definitely don’t qualify as copy protection or technical protection measures. There is really nothing to prevent you copying the work in question. However, I think there is a point that INs control access to the software. Can you install it later via Yum (provided you have the proper contracts) or use RPM to install the packages from the CDs? Yes. Would every single person installing RHEL 5 understand that you have to go back and install more stuff? I have folks that I can’t get to understand that you must register your system with RHN to even get any updates. What about the software on the CDs that are not covered by my contracts? I can just make my own Yum repository of those too.

Does this potentially violate the GPLv3? I am not a lawyer so insert grain of salt here. In a more lucid state I would definitely say no. The distribution can be completely reproduced via the source without loss of functionality.

Another commenter had the audacity to say “installation numbers are a convenience.” I laughed. I laughed a lot. Thanks, ‘cause I needed that. I do more than install a few RHEL 5 clients and servers. I maintain well over 1,000 RHEL based machines. So my environment is highly automated. The admins I work with understand well the existing system of choosing package sets. Now I need to somehow figure out from their package set choices what IN I should use. Or do I distribute INs to the admins and let them combine yet another code on top of the RHN activation key and our internal configuration management keys and make the same package choices twice? There are also the folks that want to install their own version of RHEL without our local modifications. I see the next 6 months are going to be putting out a lot of fires of “I can’t install RHEL 5” rather than doing useful things. No matter which way ends up the best to solve using INs there has been more complexity introduced.

The same comment’s corollary seems to indicate that based on your contracts you are not permitted to install some “binary bits” found on the installation media. That seems like “technologies used by publishers or copyright owners to control access to and usage of digital data” to me.

Perhaps what really set me off last week is that we use the academic contracts to purchase our RHEL subscriptions. So on Red Hat’s website I see my line items that look like “RHEL WS/AS Site Subscription” or “RHN Academic Site Subscription.” None of my line items are specific to Server or Client much less the virtualization, workstation, or cluster options. The web site gives me several INs. All of which are the same Server, 2 sockets, and 4 VMs. I’ve seen lots of noise on mailing lists about academic customers not having the INs that cover what they purchased. I’ve spoke with various folks in and outside of Red Hat and I know they are honestly working to correct the situation.

The solution here is choice. If I’m doing onesy-twosy installs let me chose what options I want to install. This is one reason we have installclasses. During firstboot and RHN registration I could be presented with a well designed dialog explaining that I have installed software options not covered by my entitlement if that were the case. This would warn about security issues and give me options for what I should do. In my automated environment I have control over what can be installed and can configure my local configuration management tools to not install options that we do not have access to right beside the code that knows how to register the machine with RHN. I do that already, that adds minimal complexity.

The solution is choice.