Archive Index (1999-2012) | 2013-current at | About  

Linux phone standards group doubles membership

Jul 17, 2006 — by LinuxDevices Staff — from the LinuxDevices Archive — 1 views

[Updated 9:45 A.M.] — An industry group devoted to standardizing Linux for mobile phones has announced three powerful, influential new members. The LiPS (Linux Phone Standards) Forum's new members include number one mobile phone chip vendor Texas Instruments, top Chinese telecom equipment manufacturer ZTE, and global carrier/operator Telecom Italia.

Additionally, a number of smaller software companies have joined the global standards organization. Founded by 11 companies last November, LiPS has added nine new members over the past six months.

LiPS constituents include semiconductor vendors, handset manufacturers, commercial Linux providers, third-party software vendors, and mobile carriers and operators. The group prides itself in the diversity of its membership, and welcomes companies to join that share the goal of avoiding “fragmentation” of Linux on mobile phones.

LiPS is fundamentally an industry standards body working to define a common middleware layer, including telephony APIs, graphical user interface(s), device management, security, application security, and an addressbook. It aims to use existing components where possible, modifying them as needed, in cooperation with existing maintainers. Its first specifications are expected later this year.

The scope of LiPS

LiPS works closely with the OSDL's (Open Source Development Labs) Mobile Linux Initiative (MLI), which also seeks to optimize and standardize Linux for mobile phones, but which confines its focus to the Linux kernel. LiPS also cooperates with CELF (Consumer Electronics Linux Forum), and with important mobile phone industry groups such as the OMTP (Open Mobile Terminal Platform) and the OMA (Open Mobile Alliance).

Current LiPS members include FT / Orange, Telecom Italia Mobile, Cellon, Huawei, Purple Labs, Texas Instruments, ZTE, Access/PalmSource, FSM Labs, Jaluna, MIZI Research, Montavista Software, Open-Plug, Longcheer, Spreadtrum, A-la-Mobile, ARM, Esmertec, McAfee, and Movial Oy.

A mini-interview with LiPS officials

To learn more about the organization's objectives and recent activities, spoke with two representatives of LiPS. Michel Gien is vice president of the LiPS Executive Committee, and co-founder and Executive Vice President of Corporate Strategy at Jaluna, a developer of real-time virtualization software for connected devices. John Ostrem is a member of the the LiPS management team, and Lead Scientist at PalmSource, a developer of software for mobile devices.

Here are a few excerpts…

Q1. Congratulations on your new members.

Michel Gien

Gien — Thank you. We have basically doubled our membership in the last six month. This shows the momentum and progress we've made.

All of these companies attended as observers for a couple of meetings, then decided it was worthwhile to join. One is an operator, one a semiconductor vendor, and one a big OEM. In addition to these three, several smaller software companies have also joined.

Q2. LiPS started almost the same time as the OSDL's MLI (Mobile Linux Initiative). Have the groups been able to work together?

Gien — Yes, we have been working together with the OSDL, and have made it clearer what is the focus of each, and how they can complement each other.

The OSDL is focusing on the kernel, and making the kernel adequate for mobile phones, similar to the Carrier Grade Linux initiative.

LiPS's focus is on middleware, the application environment, and services particular to a phone, to provide a complete application stack, including telephony APIs, graphical user interface, application security, and an addressbook.

Q3. How far along are the LiPS specifications?

Gien — Our specifications are still in review, but they will be going out in the coming months, or perhaps weeks, in the case of the video working group. We have not decided how all this will go out, and how it will be published. We hope to publish specifications early, but we have not decided in which order to publish them.

Q4. How do you see the new effort announced earlier this month by Motorola, NEC, DoCoMo, Panasonic, Samsung, and Vodafone?

Gien — I can not say a lot, because it is not clear from the announcement what they are going to do. So, it is early for us to position with regard to this initiative.

That said, it shows that Linux is hot, and that people get excited about Linux in the phone area. There are lots of activities there. From the LiPS perspective, we are open to collaborating with any organization that intends to promote Linux and avoid fragmentation.

Q5. Some LiPS members seem to have competing technologies. How will that work out?

Gien — LiPS is defining standard APIs, and the process is as open as possible. They are not defined by one company, but by a set of companies.

The LiPS specification will not endorse the products of any vendor. Some LiPS APIs or approaches may imply a product, though. If a vendor's implementation needs to be compatible, they may need to change their APIs.

LiPS is not trying to develop new APIs from scratch. The goal is to have vendors talk to each other, to avoid fragmentation. It's really a classical standardization effort.

Q6 — Do you envision that any of these APIs, or making use of any of these specifications, will require a license or royalties?

Gien — Well, the way we'll deal with the intellectual property is that the essential patents should be known about before people contribute, and then there should be terms and conditions that are fair and non-discriminatory.

Q6a: So that means, in cases where there are patents, there would need to be the signing of a license agreement and perhaps a nominal royalty?

Gien — Right, but in that case the organization may choose to take other approaches that do not require a patent

Q6c: For that reason, I was wondering if there is a policy on that?

Gien: The policy, right now, is that we don't want to take ourselves out of APIs that [involve] patents, because they might be implementing something important that becomes an industry standard, but there is a will to try to have APIs that are as open as possible, possibly with open-source reference implementations, and not to have to deal with patents.

So there are two things: the organization wants to have APIs that are as open as possible, but at the same time we want to acknowledge, if there are some areas that we like to establish APIs and for which there are patents associated with it, that the patent holder agrees in advance to the licensing terms that are fair and nondiscriminatory and reasonable.

Q7 — The OSDL, with Carrier Grade Linux, does not add things to the spec unless there is an open source implementation. Would a similar approach make sense for LiPS?

Gien — A lot of innovation is going on, but open source implementations are usually not first. So we want to still be open to defining some APIs and services for which there's no open source.

Q8 — [Addressing John Ostrem] Your company is a potential user of LiPS specs. Have LiPS activities influenced PalmSource's and Access's Linux stack?

John Ostrem

Ostrem — We're looking at modifying our material to make it more LiPS compliant. So, certainly, in specific areas.

Q9 — User-installable native applications, or the lack of them for Linux phones, have recently been in the news. Is that an area of interest for LiPS?

Ostrem — It has been discussed, and it is an area of interest, although it will not be part of the initial specification rounds.

Q10 — The user interface is one of the most critical areas, in terms of look and feel. Will the LiPS specification still allow companies to customize the UI? Also, Trolltech has one look and feel (in Qtopia), and PalmSource has another (in Palm OS). How can LiPS's UI services integrate those into a standard?

Ostrem — The whole LiPS Forum is sensitive to being able to customize interface, download applications, and support services that operators want.

Pretty much any UI needs certain basic services. The LiPS specification doesn't specify the actual UI, but rather the underlying services.

We would like Trolltech to contribute to LiPS specifications, but we don't know if they intend to make their middleware LiPS-compliant. LiPS is defining APIs to all of these services, so it would be a matter of using the LiPS APIs.

LiPS is working with GTK, which was developed for the desktop. So, a lot of it isn't needed. We're taking some stuff out, and adding some more capabilities.

Q11 — Nokia uses GTK in their 770 Internet tablet and VoIP phone. Is there any overlap there?

Ostrem — Nokia currently is not a member of LiPS, but we would love to have them join.

Q12 — What's the biggest challenge for LiPS?

Ostrem — The issue of fragmentation worries us all in this area. Trying to resolve that issue is the biggest challenge we have.

The good news is that there are more and more companies interested in working on this. Everyone sees in Linux a way to keep their stake in the phone market. Everyone is interested to make it work, because it's in the interests of everyone to avoid fragmentation. And, LiPS is a leader in this area.

Q13 — Thank you for speaking with us!

This article was originally published on and has been donated to the open source community by QuinStreet Inc. Please visit for up-to-date news and articles about Linux and open source.

Comments are closed.