Warmest thought and best wishes for
A Wonderful Christmas
(May the love that comes that holy night light all your days and with hope and joy)
and
A Very Happy New Year 2008!!

Mandriva today announced that the Nigerian government has selected Intel-powered classmate PCs running on Mandriva Linux for educational use in nationwide pilot in Nigeria. Mandriva is working with Intel Corporation and Technology Support Center Ltd. to provide 17,000 Intel-powered classmate PC. The aim of this project is to improve the quality of technology delivered to students, and to help teachers and parents.
The Intel-powered classmate PC is a small, rugged, mobile educational solution specially designed for primary students in emerging markets. Shipped in May this year, this fully functional PC is currently being piloted in more than 25 countries around the world. Nigeria was one of the first countries to run pilots of Intel-powered classmate PCs in their schools.
Nigerian government’s decision to choose Mandriva Linux to run on classmate PCs reaffirmed Mandriva Linux as one of the most popular Linux distributions in the world. Mandriva's emerging market strategy is based around a network of local partners and OEM agreements with hardware providers. Mandriva has been working with Intel on classmate PCs since the very beginning, making Mandriva Linux one of the first operating systems to run on the machine. The classmate PCs provided to Nigeria will run a customized version of Mandriva Linux 2007 built on Mandriva Flash technology. This edition has been tailored to classmate PCs hardware with a unique launcher application which makes it easier to access the most commonly needed applications.
"We are delighted to participate in this project along with our partners, and to help bring Mandriva Linux and open source applications to Nigeria. This operation validates our approach of cooperating with Intel on the classmate PC and of leveraging our local presence in a country such as Nigeria," said David Barth, CTO and Vice President of the Consumer Business Unit for Mandriva.
The Intel-powered classmate PC will be used in local Nigerian schools by teachers, parents and students. Students will use them to learn about IT technology and to assist them with class research. Teachers will use them to improve their computing skills and to help them track students and projects.
"Based on the needs of the community, the Intel-powered classmate PC will assist a communities that have been previously underserved. The classmate PC's features for teachers and parents will also help them focus on education," said Dele Ajisomo, President of Mandriva West Africa.
Intel-powered classmate PCs use a low power Intel processor for good performance and battery life. These mobile PCs feature a 2 GB of internal flash storage, WiFi mobile technology, as well as anti-theft applications, classroom management and a content filter. These mobile PCs are designed to deliver the right performance to support essential learning applications and experiences.
“The TSC is proud to open the doors of Technology Enabled Learning and to be part of the team enhancing the quality of education delivery in Nigeria. The Technology Support Center and Mandriva working together provide high quality open source solutions to facilitate technology adoption, knowledge based economic empowerment, technology diffusion in some of the most remote and underserved areas of Africa”, said Nyimbi Odero, CEO Technology Support Center .
The initial stable release from the openSUSE project was SUSE Linux 10.0, released on October 6, 2005 and the latest version available is 10.3 that was released on October 4, 2007.
Download OpenSuse
As Torrent
From FTP
Introduction
This article discusses the use of Microsoft's Active Directory as an authentication service for Linux systems. Although Linux has a perfectly good directory based authentication system (OpenLDAP), it may be desirable on some sites to authenticate Linux users against a Microsoft Windows 2000 server.
Although this article discusses Linux (because that is the system I have available in my office), this authentication mechanism works well against other Unix systems that have a PAM/NSS mechanism. Currently that includes Solaris, although discussion has taken place on the possibility of getting this to work on HP-UX. Since most of the work is done at the Windows 2000 end, the instructions for getting this to work on Solaris are not too different from what I have described here.
Before attempting any of this, you should be familiar with the concepts of PAM and NSS, and be familiar with how to set up PAM and NSS on your Linux distribution or operating system.
Also, before I begin, I should state that I really do not believe that Active Directory is the best way to authenticate Linux clients, nor is it the best way to authenticate users in a multi platform environment. It may be the case that in your network, for political and financial reasons, you are constrained to using Active Directory as a directory product, however, and so this document may be of some benefit to you if you are unable to rethink your IT strategy in this area.
Furthermore, I really recommend taking caution in implementing any of the instructions in this article. Microsoft does not support authenticating to Active Directory for any non-Microsoft client, and Microsoft does not support the instructions contained in this article in any way. If you wish to follow the instructions in this article then you do so at your own risk.
Authentication Systems
The traditional way of authenticating users on a Linux system is to store the accounts and passwords in an /etc/passwd file or, more commonly, a combination of /etc/passwd and /etc/shadow.
This is fine when there is only a single Linux system on a network, as the /etc/passwd file is local to the system on which it is stored. Although it is possible to share a single /etc/passwd file amongst multiple Linux systems, using such tools as rsync, it makes more sense to have a centralized authentication database containing all of the user accounts and passwords.
There are many such centralized authentication systems available, including Kerberos, NIS, and others. LDAP is a protocol that can be used to enable a fairly powerful mechanism to store centralized authentication as well as user information.
Cross-Platform Authentication
The aim of cross-platform authentication is to have a single, centralized password database that can be used to authenticate users on both Unix, Windows, and perhaps even other systems such as Macintosh or NetWare.
Because LDAP-based authentication is supported on the most recent Microsoft systems, including Windows 2000 and XP, and is also supported on Linux and other Unix systems (such as Solaris), it makes an excellent choice for a cross-platform authentication system. Note that there are limitations to this. Firstly, the Microsoft clients for Windows 2000 and XP are specific to authenticating against a Microsoft Active Directory server. Although OpenLDAP uses the same LDAP protocol, there are other features of Active Directory (including a modified version of Kerberos with a Microsoft specific mechanism called a "PAC") which means that Active Directory clients will not necessarily be able to authenticate against OpenLDAP.
The second limitation of Active Directory is that clients for it (in LDAP mode, that is) are only available on Windows 2000 and Windows XP. Although Active Directory will work in a "down-level" mode to support older Microsoft clients, users of systems such as Windows NT and Windows ME/98/95 who wish to have full LDAP/Kerberos based authentication support are forced to upgrade.
Of course, another limitation of Active Directory is that it only runs on Microsoft Windows 2000 servers. There are no releases of Active Directory for other platforms. In contrast, many of the other directory services available (such as those from iPlanet and Novell) are supported as servers on many platforms.
LDAP Alternatives
Other alternatives to Active Directory exist where an LDAP-based authentication system is desired. These include:
MKS AD4Unix
What is AD4Unix?
MKS AD4Unix is a plug-in extension for Microsoft's Active Directory Server, that enables Unix-related authentication and user information to be stored in Active Directory. AD4Unix includes a schema update, and an extension to Microsoft's User & Group manager (part of the Active Directory administration interface, which is in turn part of the Microsoft Management Console).
The primary goal of AD4Unix is to create a unified account database for Windows and Unix servers via Active Directory. This is what specifically enables cross-platform authentication using Active Directory.
AD4Unix was written by Maxim Batourine of the Faculty of Architecture, Landscape, and Design at the University of Toronto. Full credit should be given to Maxim for the assistance that I received during preparation of this article.
Obtaining MKS AD4Unix
MKS AD4Unix can be obtained via the AD4Unix download page.
AD4Unix is delivered as a single .MSI (Microsoft Installer) file that can be installed directly onto a Windows 2000 server.
Installing MKS AD4Unix
The original installation instructions for AD4Unix, and guidelines for its use were written by JJ Streicher-Bremer for AD4Unix 1.1.1. Things have changed somewhat since then, there is now an installation package (MSI format), however there are still a few hairy parts of the installation because the installation package is not perfect. JJ has also been particularly helpful in preparing this article, both personally and in discussions and posts to the nss_ldap mailing list.
My goal in installing AD4Unix was to take a machine with a blank, formatted, hard disk, and install Windows 2000 and then AD4Unix from scratch. This took a bit of messing about.
These instructions are based on Windows 2000 server, service pack 2, and AD4Unix version 1.5. Here follows a log of what I did to get the product up and running:
Adding User Entries
Now that the AD4Unix plugins are installed, it is possible to use Active Directory Users and Computers to enter new Unix users into the Active Directory system. You could also modify the Unix user and group attributes of your existing Active Directory users to make those users visible on a Unix system.
To add a new user, run the program "Active Directory Users and Computers" from the "Administrative Tools" menu. Note that you need to run this program from the same computer on which the ADS4Unix plugins were installed - if you normally manage your user base from another workstation then you will need to install the plugins there as well, perhaps this time without the schema updates.
After creating a new user, the user editor window (obtained by double clicking a user in the user list) will contain an extra tab, titled "Unix settings". This contains the following extra fields:
Note that these fields replicate the information in the /etc/passwd file normally found on a Unix system.
Group Entries
For Active Directory groups, there will now also be a "Unix settings" tab in the Active Directory Users and Groups tool. This tab contains two fields:
Adding a user to a UNIX group is again done via the Active Directory Users and Groups tool, simply by the same method that you would use to add an Active Directory user account to an Active Directory group. Group membership on Linux or Unix mirrors the membership on Active Directory.
Other Components
Now that the Active Directory (server) end of things is configured, we need to configure a Linux box to act as an Active Directory client. This includes setting up a few pieces of software, including:
OpenLDAP client
The OpenLDAP client can be obtained in a number of ways. This includes:
Note that although we only want to have the OpenLDAP client, the OpenLDAP project includes a single source tarball containing the server and client components. If you prefer to build from the source code then you will need to obtain the latest openldap.tar.gz file from the OpenLDAP download page, and read the installation instructions included.
The client components that we are concerned with include the shared libraries and the ldapsearch program, which we will use for testing. If you are going to compile NSS_LDAP and PAM_LDAP from source as well, then you will need the OpenLDAP header files. All of these files should be installed when you run "make install" from the OpenLDAP source directory.
If you have a Red Hat system then you may just want to install the OpenLDAP RPMs. In Red Hat this is the openldap and openldap-client RPM files. You should use a recent version of OpenLDAP, for example release 2.0.21 from the latest Red Hat 7.2 updates. Note that you do not need the openldap-server RPM.
In any case you will need a version of OpenLDAP that is more recent than 2.0.12 and you should certainly not use any of the release 1.x versions of OpenLDAP.
If you are installing on a Red Hat Linux system, then you will find the OpenLDAP client configuration file installed on your system as /etc/openldap/ldap.conf. You should edit this file in a text editor (such as vi or emacs) and include the following two lines:
HOST
BASE
Where "
Once you have configured your ldap.conf file, then you should be able to perform a simple LDAP query using the ldapsearch program. For example:
ldapsearch -x ""
Note the empty string in quotes at the end of the command line. On running this search command you should see some interesting if not particularly informative details.
One of the interesting quirks of Active Directory is that it doesn't allow searches below the top level of the directory while anonymously bound (not authenticated) to the directory. So, for example, the following search will fail:
ldapsearch -x "sAMAccountName=del"
whereas, once bound (for example, as administrator), the command will succeed:
ldapsearch -x -D "cn=Administrator,cn=Users,dc=somecompany,dc=com" -W/
"sAMAccountName=del"
(the above command will prompt you for a password - you must supply the Administrator password for your Active Directory).
Note that if your base DN for Active Directory is "dc=somecompany,dc=com" then your default Administration DN will be "cn=Administrator,cn=Users,dc=somecompany,dc=com". This may have changed if you have modified your Active Directory installation, so check this before using it in the above LDAP query.
You should get your OpenLDAP client working before progressing any further. If you cannot perform at least simple top level searches on your Active Directory, then you should locate and fix any problems before attempting the next step.
NSS_LDAP
On the Linux side, the most important components are nss_ldap and pam_ldap. These modules are both available from PADL Software. The modules are also shipped with most modern Linux distributions including Red Hat.
If you want to obtain the modules from source code, then you will need to download them from the "Software" page at the PADL web site, above. You will need both pam_ldap (available as pam_ldap.tgz) and nss_ldap (nss_ldap.tgz).
If you recompile from source, get the latest (183 or thereabouts as of the current writing) version of nss_ldap, and make sure you use the following two options on the ./configure line when compiling:.
/configure --enable-schema-mapping --enable-rfc2307bi
The --enable-rfc2307bis flag is required for any nss_ldap version after 172 (Red Hat 7.2 uses 172 so this flag is not needed).
If you prefer to install from .DEB or .RPM files, you will need to make sure that the nss_ldap and pam_ldap modules are installed on your system. Note that in Red Hat Linux, both pam_ldap and nss_ldap are stored in the same RPM module -- nss_ldap-172-2.i386.rpm.
You will, however, need to rebuild the nss_ldap RPM, as follows.
Recompiling the NSS_LDAP RPM file
The nss_ldap-172-2.i386.rpm file supplied by Red Hat does not include a particular flag that is required to allow nss_ldap to work against the Active Directory schema (which is different to the OpenLDAP schema normally used on Red Hat Linux systems). The best way to enable this flag is to recompile the nss_ldap RPM file.
Firstly, obtain the nss_ldap-172-2.src.rpm file. This can be obtained either from your Red Hat CD set (if you have the full CD set with the source CD), or from the Red Hat FTP site (ftp://ftp.redhat.com/) or one of its nearby mirrors. The file you are looking for will be in the redhat-7.2/en/os/i386/SRPMS/ directory on the FTP server.
Install the source RPM file using:
rpm -ihv nss_ldap-172.i386.src.rpm
You will then need to edit the file /usr/src/redhat/SPECS/nss_ldap.spec. Around line 67 of the file, you will find the configure command, which reads:
%configure --with-ldap=openldap --libdir=/lib
You will need to change this to read:
%configure --with-ldap=openldap --libdir=/lib --enable-schema-mapping
Also, near the top of the file you will find the line:
Release: 2
Change this to:
Release: 3
You can then rebuild the RPM using:
cd /usr/src/redhat/SPECS
rpm -ba --clean nss_ldap.spec
After the build process finishes, you will have a file in /usr/src/redhat/RPMS/i386 called nss_ldap-172-3.i386.rpm. (Note: this is for an Intel / AMD based system -- on a SPARC system you will be looking for a file called nss_ldap-172-3.sparc.rpm). You should install this file using the following command:
rpm -Uhv usr/src/redhat/RPMS/i386/nss_ldap-172-3.i386.rpm
Note that the --enable-rfc2307bis flag on the %configure line is also is required for any nss_ldap version after 172. The release of NSS_LDAP shipped with Red Hat 7.2 is version 172 so this flag is not needed, but if you obtain a more recent RPM then you will need the following configure line instead of the one shown above:
%configure --with-ldap=openldap --libdir=/lib
--enable-schema-mapping --enable-rfc2307bis
NSS_LDAP configuration
The configuration file for nss_ldap is the file /etc/ldap.conf. This will normally have been created on your system when you installed the nss_ldap module.
Once you have installed nss_ldap and pam_ldap, you will need to edit the /etc/ldap.conf file, as follows.
Authconfig
Red Hat Linux comes with an authentication configuration program called authconfig, which you can use to perform the basic configuration to allow your system to use LDAP authentication. To run this, log on as root and run:
authconfig
On the first screen, select "Use LDAP". Enter the IP address of the LDAP server (which is your Windows 2000 Active Directory) and the base DN that you entered when you set up Active Directory (e.g.: dc=yourcompany,dc=com). Also make sure that "Use LDAP Authentication" is checked (next page).
Authconfig is intended to set up a system to authenticate to an OpenLDAP server, and therefore doesn't perform all of the functions needed to set up your system to authenticate against Active Directory. To complete the configuration, you will need to edit your /etc/ldap.conf file, which is the primary configuration file for OpenLDAP.
You should also uncomment the following lines, which should be in your basic LDAP.conf file, but commented out:
nss_base_passwd cn=Users,?sub
nss_base_shadow cn=Users,?sub
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid sAMAccountName
# nss_map_attribute userPassword msSFUPassword
nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember member
nss_map_attribute cn sAMAccountName
pam_login_attribute sAMAccountName
pam_filter objectclass=user
pam_password ad
Note that in the above configuration file entries,
Allowing Anonymous Searches in Active Directory
At this stage, everything should nearly be working. You should be able to log in as a user in your Active Directory domain, using the Active Directory password, and mostly get logged in. You will see some error messages, however, including:
id: cannot find name for user ID 1001
id: cannot find name for group ID 1000
This is because your Active Directory cannot be searched anonymously. There are two solutions for this problem:
To enable anonymous searches on your Active Directory, follow these steps:
Inserting an Administration DN into /etc/ldap.conf
An alternative to allowing anonymous searches on your Active Directory is to allow the nss_ldap routines to bind as an administrator DN to your directory and perform searches in privileged mode. To do this, insert the following lines in your /etc/ldap.conf file:
binddn cn=Administrator,cn=Users,
bindpw
You should be used to the "
WARNING: The above example shows that the administrator user name and password have been coded in clear text in the /etc/ldap.conf file! Unfortunately, this file must always remain world-readable, because otherwise users logged on to the system will not be able to read data from the directory. You should not do this on a system where any user has shell access to your system, or can in any other way read this file.
Of course, there is a third alternative, which is to create a new user within Active Directory and assign this user no rights other than read access to the directory. You could then key this user's logon and password into the /etc/ldap.conf file, rather than the administration DN and password. I don't consider this method any safer than allowing anonymous binds; however, as any user that could (anonymously perhaps) read this file could read the logon name and password of the special DN that you have created.
PAM_LDAP
On a Red Hat system, PAM_LDAP is part of the NSS_LDAP RPM. PAM_LDAP by default uses the same configuration file (/etc/ldap.conf), so all of the nss_ldap changes work also for pam_ldap
Note that PAM_LDAP is only used for authentication, whereas NSS_LDAP is used for all user information. A user can still log on to a Linux system without NSS_LDAP working, although they will get frequent messages saying "I have no name!". If this is happening to you, then it is possible that you have PAM_LDAP working correctly but NSS_LDAP broken.
I have had it reported to me that on some recent Debian systems, PAM_LDAP and NSS_LDAP have different configuration files. I am not entirely convinced of the wisdom of this, but it could be useful in certain situations, and for debugging purposes. If you are on such a system, it would be wise to locate all files containing the name "ldap.conf" on your system and work out which of these belong to PAM_LDAP and which belong to NSS_LDAP.
Note that to be able to change passwords on an Active Directory server from Linux, you need to have SSL and TLS enabled, both at the client end and at the server end. Enabling SSL and TLS on an LDAP client is covered in the SecurityFocus article, Linux Authentication Using OpenLDAP, Part One.
Web Resources
There are many resources on the Internet that can assist you in getting all of this mess running on your network.
The Active Directory documentation, supplied by Microsoft (full documentation is supplied with every copy of Windows 2000 Server) contains all of the information you are ever likely to need about Active Directory. It contains a complete installation guide, a full set of details about the schema management utilities, and extensions to the RFC 2307 schema that have been implemented by Microsoft along with a complete rationale. Guides to extending the Active Directory schema are included, along with a helpful set of utilities allowing you to use all manner of third party clients in an Active Directory environment. Please note that everything that I have said in this paragraph is basically incorrect and largely tongue-in-cheek.
The OpenLDAP consortium page, which is to be found at http://www.openldap.org/ contains much useful documentation about OpenLDAP and LDAP in general.
Innosoft's LDAP world page, to be found at http://www.innosoft.com/ldapworld/ is a useful jumping off point for many LDAP-related topics.
The home page for MKS AD4Unix can be found at http://www.css-solutions.ca/ad4unix/
PADL, a company based in Melbourne, Australia, makes the nss_ldap and pam_ldap modules available for free. They also offer a product called ypldapd which can make LDAP servers visible in a NIS environment, for Unix systems that do not support LDAP based authentication or name services. This could be an exceptionally useful extension to any cross-platform LDAP service especially in a Unix environment where PAM and NSS are not supported. Their home page can be found at http://www.padl.com/
Quartet, is a new project, which attempts to implement much of the functionality of Active Directory on Linux. The Wiki Wiki Web page for Quartet can be found at http://www.babel.com.au/quartet/, although it should be noted that no actual code has been written for this project yet and it may be some time before it is ever useful.
Everyone who is working in a multi platform Unix and Windows environment should be familiar with the SAMBA project. SAMBA version 3.0 can join an Active Directory domain. Work is progressing on getting user information for SAMBA stored in LDAP. The SAMBA home page can be found at http://www.samba.org/
Windows has a number of design flaws, resulting in it becoming slower and slower and not lasting very long. You've probably heard more than once someone say "My computer is getting sluggish, I'm gonna reinstall". Reinstalling Windows solves the problem... until next time.
You may think this is just how computers work, they're very new technology, and still not really stable. Well, try Linux and you'll be surprised. Five years from now, your system will be just as fast and responsive as the day you installed it, not to mention that you won't have any viruses, adwares, trojans, worms, etc., that would force you reinstall anyway.
I have managed to convince many people to switch to Linux, while keeping Windows on their hard disk, because they needed to use some piece of software that Linux doesn't have (eg Autocad), so they use both systems. Since the day they switched, most of them have reinstalled Windows about once in a year or two; but Linux didn't let them down, and is still running perfectly well and snappy today.
Linux lets you spend more time working, less time reinstalling over and over again.
The long-awaited follow-up to its sleek Razr phone for GSM networks, now on sale in Asia, is based on Linux. The model, called Razr2 V8, will come to the United States within two months as Motorola's first Linux phone in this country.
Cell phones traditionally have used proprietary operating systems, fragmented even among one manufacturer's products. Motorola and other vendors have also opened up phone platforms through the Java and BREW software environments. Linux will help to further expand the community of developers for software, which is becoming an increasingly important part of mobile phones, said Christy Wyatt, vice president of ecosystem and market development at Motorola. The company has shipped about 9 million Linux handsets in the past four years and is now extending the OS down from smartphones to midrange handsets such as the Razr2.
On Tuesday at LinuxWorld in San Francisco, Motorola unveiled Motomagx, the latest version of its mobile Linux platform. Motomagx offers a new development option, called WebUI, to help bring Web 2.0 applications to phones. It lets developers who use tools such as AJAX (Asynchronous JavaScript and XML) present their applications on a mobile phone through the WebKit open source browser engine, Wyatt said. WebUI, Java, and Linux itself will be the major development environments for Motorola's Linux phones, she said.
One key to developing a large Linux developer community has been agreeing with other mobile companies on a single Linux platform, Wyatt said. In January, Motorola formed the LiMo Foundation along with NEC, NTT DoCoMo, Vodafone, Samsung, and Matsushita Electric Industrial (Panasonic).
The company's Motodev Developer network helps software creators write applications for Linux phones. In the United States, where mobile operators control software more tightly than in other parts of the world, Motorola helps developers get their applications on the carrier software and services "deck," Wyatt said.
After Linux becomes the dominant platform for Motorola's phones, the company still expects to sell Windows Mobile devices aimed primarily at enterprises, Symbian phones in Europe, and a number of low-end phones based on simpler, more closed platforms. But Linux is headed toward being one of three dominant platforms in a consolidating mobile-software world, along with Windows Mobile and Nokia's Series 60, Wyatt said.
For the moment, phones based on the CDMA family of technologies are left behind in Motorola's Linux drive. Between CDMA and the BREW software environment frequently used on those phones, there is much porting and development work to be done, Wyatt said. But the company's majority-Linux forecast assumes it will be able to bring out Linux-based CDMA phones, she said. There will be a non-Linux handset comparable to the Razr2 V8 for CDMA networks, she said.
Google has joined the fight to save Linux from an army of patent-waving Microsoft lawyers.
With Redmond threatening to collect royalties from Linux users and distributors across the industry, claiming that the open-source operating system violates 235 of its patents, Google has thrown its considerable weight behind the Open Invention Network (OIN), a consortium of companies bent on protecting open-source software from legal attack.
All OIN members - including big names such as IBM, NEC, Novell, Philips, Red Hat, and Sony, as well as Google - agree not to use their Linux-related patents against each other, and all have free access to a collection of additional open-source-related patents purchased by the consortium as a whole.
"Patent issues...become a much smaller concern inside the community, and OIN members can focus their energy on writing and releasing software rather than vetting their code for intellectual property issues," wrote Google open source programs manager Chris DiBona on The Official Google Blog . "It's the legal equivalent of taking a long, deep breath."
As more names join the OIN, pooling more and more Linux-related patents, it becomes increasingly difficult for a company like Microsoft launch an attack on the OS. "We are very open about our patents," OIN chief executive officer Jerry Rosenthal told The Reg. "We list them on our website, so that people who might want to do Linux harm understand why it would not be in their interest to bring litigation."
Knowing they're protected by the OIN, Google's DiBona argues, open source developers are more likely to drive the industry forward: "We believe Linux innovation moves fastest when developers can share their knowledge with full peace of mind. We're proud to participate in an organization that's making that possible, and we look forward to seeing OIN grow and thrive."
Google is OIN's first "end-user licensee," which means it's the only member who doesn't sell, distribute, or develop Linux code. It only uses the OS within the company.
"Google is such a well-recognized and well-thought-of name, we'll now see other end-users become licensees," said Rosenthal. "We want to continue to grow this ecosystem of patents, so that ultimately a vast majority of [Linux-related] patents will be available to the community for free."
According to DiBona, Google's in-house open-source gurus are fond of saying "Every time you use Google, you're using Linux...Check a Google engineer's workstation, and you'll probably find it's running Linux," he explained. "Do a search on Google.com, and a Linux server will return your results. Ever since Google got its start, Linux has given us the power and flexibility we need to serve millions of users around the world."
That puts the company squarely in the sights of Microsoft general counsel Brad Smith and licensing chief Horacio Gutierrez, who recently told Fortune that Redmond plans to use 235 of its OS patents to collect royalties from Linux users and distributors alike.
To date, the OIN has purchased more than 100 worldwide patents and patent applications involving Linux - and that doesn't include the patents individually owned by its members. The difference, Rosenthal says, is that unlike Microsoft, the OIN is completely open about its patents and uses them strictly for defensive purposes. "Microsoft says they have 200 some Linux patents, but they won't tell us what they are," he told us. "That's just an attempt to spread fear, uncertainty, and doubt. It they tell us what the patents are, then we can deal with it, but they won't. It makes you wonder they really have." ®
Source: ChannelRegister