Collaborative Development for the future of Mobile
by Andrew Savory on Jun 14, 2010
- 301 views
Accessibility
Categories
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 0
- Downloads
- 3
- Comments
- 0
- Embed Views
- Views on SlideShare
- 300
- Total Views
- 301
My name is Andrew Savory, I’m the Open Source Manager for the LiMo Foundation, I joined at the start of October.
I hope I can give you an insight into what LiMo is, and why it’s essential to the future of mobile.
You might ask what does an Open Source Manager do:
- educate our members on the benefits of open source
- keep track of our open source usage, and of other relevent open source projects (e.g. Gnome Mobile)
- ensure our compliance with open source licenses
- encourage our members to give back to open source to get the virtuous cycle of OS usage
- talk to the world about LiMo, the future of mobile, and Open Source.
Why does the world need LiMo?
Two years is a long time ago in this industry: for example it was before iPhone (announced MacWorld Jan 2007), and before Android (announced Nov 2007).
References:
http://www.techcrunch.com/2007/01/09/macworld-announcements-real-time/
http://gigaom.com/2007/11/05/google-launches-mobile-phone-platform-android/
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
Here’s just 7 of the major platforms, there are of course many more.
It seemed like every time a new phone is released, it comes with a new operating system.
This does not take into account specific versions of operating systems: looking at Microsoft’s Pocket PC / Handheld PC / Web-enabled telephone / Palm-size PC / Smartphone 2002 / Windows Mobile 2003 / Windows CE / Windows Mobile 6, there’s been more than a dozen different releases.
Of course, diversity is important to a healthy ecosystem and allows competition and stimulates innovation. But the situation was beyond diversity and into fragmentation - with too many different platforms to have to pick from as a handset manufacturer or software developer.
References:
http://www.pocketpcfaq.com/wce/versions.htm
There are also many different network operators. Each operator usually insists on their own customisation requirements for phones on their networks.
This allows them to tie products into specific features of their network, or to help them manage the support of handsets deployed on their network.
So you don’t just have to test across a dozen platforms - you also have to test across a dozen networks too.
Suddenly from 7 operating systems and 7 operators you have nearly 50 targets to manage.
Obviously this is not sustainable for anyone - neither operators, manufacturers, nor developers.
If we had convergence around a few common platforms, we would significantly reduce the burden of development, maintenance and support.
In 2007, a number of mobile industry leaders got together try to solve this problem
Motorola, NEC, NTT DoCoMo, Panasonic, Samsung, Vodafone and Orange founded LiMo, with the idea of developing a mobile platform drawing on the expertise and experience of members and pooling resources around a common set of code.
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
It is NOT a standards body. It is directly connected to the real business of delivering next generation handsets, applications and services, drawing on the combined experiences of our members.
It is NOT an end-to-end platform. LiMo provides middleware OS only, thus avoiding conflicts with operators, handset vendors and content providers by not providing the UI or content.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
52 members: representing a broad cross-section of the mobile ecosystem, brings together all the partners needed to collaborate on the platform. You need this diversity to ensure all views are represented and that the platform delivered meets the right requirements.
Independent foundation: neutral third-party, not dominated by any one member. This is crucial to ensuring a viable developer ecosystem without the fear that contributions are going directly to competitors, and the success of independent foundations as a method to ensure this can be seen by the proliferation of open source foundations such as the FSF, ASF, Gnome, Mozilla, Python, Eclipse, and Linux Foundation.
In just two years it has grown to be a safe haven for collaborative mobile development, sharing best practice and experience to provide a common mobile platform.
Beyond that, what are the aims and aspirations of LiMo, the goals, the roadmap for the future?
Other than solving the problem of platform proliferation, what else is LiMo about?
I’d like to outline those goals now for you.
This is not just about collaboration to reduce fragmentation, it’s about taking the experience of our members and combining it with key open source components to create a truly competitive platform:
“middleware best of breed”
How do we do this?
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
As I said before, LiMo is not a standards body.
It is not about simply saying how a phone should work.
It is not about unproven software that’s never been shipped in the marketplace.
This quote from Jay Sullivan of the Mozilla Foundation sums it up best: LiMo is about proven code.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
Unlike some other platforms, LiMo is based on what members have been doing in the marketplace for years.
For example: in 2003, one of our members released the first mass-market linux phone in western markets (Motorola A760). So LiMo members were shipping linux phones over 5 years ago! That’s a lot of experience in the marketplace and a lot of proven technology.
Since then, dozens of LiMo handsets have been released.
So LiMo is about drawing on member experiences to put together a solid secure platform.
FIXME References to published roadmap?
http://www.limofoundation.org/images/stories/pdf/limo%20foundation%20overview%20-%20may08-ext.pdf
Fixes and modifications within the platform are shared in order to avoid fragmentation.
Very strong copyleft at the platform and API level, with an obligation of each Member to contribute back just before the commercialisation.
We are not open source: whilst we would love to be completely open source, pragmatism dictates that to get the widest engagement and contribution of existing code, a hybrid model is required. We do however have a policy of using open source where suitable and of actively contributing back to open source projects and being good citizens within the open source communities.
We expect that commercial innovations on top of the platform may be retained.
Because LiMo is not a complete stack but instead is focussed on middleware, it does not specify for example the user interface.
This provides a solid platform upon which members can build differentiation.
Which takes us to goal number 2.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
If we asked all members to work on a complete end-to-end platform, there would be conflicts of business models and it would erode the commercial plans of some members.
For example, some members like to offer customised UI experiences.
Because LiMo is only middleware, that provides plenty of opportunity for differentiation and for different UI offerings.
We also supports intra-member business opportunities: for example some members might want to sell plugins, for example video codecs, to other members.
This is also exemplified in our platform layout: we have two distinct areas of contribution, common code and non-common code. Common code is a mandatory inclusion in the platform, and must be contributed under our foundation public license. Non-common code can be commercial, is not expected to be available on all LiMo implementations, and could be considered as somewhat like an internal library of functionality optionally available between members on commercial terms.
I will cover in more detail common / non-common code later.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
You can see that the middleware layer of the operating system clearly allows freedom of choice within the UI, application and content layers for mobile manufacturer, network operator and consumer alike.
A successful community requires a clear set of rules and boundaries to work within, and so we have an open, inclusive and published governance structure.
We have shared leadership and shared decision making: no one dictator to determine the route the platform should take. Discussion is based on technical merit and experience.
We also aim to provide a safe and empowering IP safe harbour: everyone can contribute without fear of reprisals through patent lawsuits etc.
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
In this excellent and timely article from VisionMobile, you can clearly see how LiMo is positioned with respect to other Open Source initiatives.
It’s interesting to note that although LiMo is way up in the proprietary community license axis, many major components (or possible future components) fall under other licenses - linux, GTK, Mozilla, WebKit.
FIXME redo graphic
Any company or person can join LiMo, as a Core or an Associate member.
Any Member can contribute to the platform, have access to minutes of all meetings, and participate in our various elections.
All our source code contributed under the FPL is available to any company agreeing with the terms of our IP safe harbour.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
Visit the LiMo website at the URL displayed to find a rich source of information on Release 1, with a complete API reference available as an archive containing all the PDFs, or as individual PDFs or HTML files.
I’d like to explain the process to you now.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
The first stage is to signify intent to contribute some code, and to state under what license the code will be contributed. The choice of license is the member’s alone, and will determine how widely the code may be used - with open source and FPL being more likely to be included in the LiMo common platform, and more restrictive licenses more likely to be used through commercial agreements amongst members.
The requirements council evaluates any offered contribution to be sure it is of value to the platform (the equivalent of an open source model where an offer to contribute a patch is made and sometimes accepted).
The working groups evaluate contributed code to determine the quality of the code and to verify fitness for purpose and other pre-determined metrics.
The architecture council classifies the code initially based on the licensing regime: only contributions under patent and copyright royalty free licenses (e.g. open source or FPL CC)_ can be adopted as common code or framework. This decision is ratified by LiMo board.
As previously mentioned when talking about Copyleft, LiMo is not completely open source.
But we do:
- use a lot of open source software
- with strong interaction with open source communities
- define a development and licensing model based on open source best practise
- “collaborative source development”
- copyleft license within the foundation
- inclusive of other licensing models above the level of commodity
I’d like to explain how this works now.
As previously mentioned when talking about Copyleft, LiMo is not completely open source.
But we do:
- use a lot of open source software
- with strong interaction with open source communities
- define a development and licensing model based on open source best practise
- “collaborative source development”
- copyleft license within the foundation
- inclusive of other licensing models above the level of commodity
I’d like to explain how this works now.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Common (for code that is expected to be a part of all releases)
Non-common (for code that may not be a part of all releases due to commercial terms)
Code is submitted to common from member projects (under FPL)
Code is also submitted to common from open source projects (under original open source license)
Important to note we expect fixes and optimisations made within common to be contributed back to contributors or projects: reciprocal flow of innovation and responsible attitude to open source communities.
Non-common: code comes in the same way from member projects
(Not likely to be open source projects as these contributions are typically associated with proprietary licensing models).
Non-common either under FPL (non-common) or proprietary license.
Interesting to note: by default, proprietary licenses are by default automatically converted to FPL.
Non-common modules are typically platform-specific or geographic-specific.
Depending on market selection, a plugin may enrich the functionality of a Framework and become Common Code.
LiMo provides a balanced but strong IP safe harbour for development, intended to foster collaboration and innovation whilst respecting the rights of members.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Highlighted in green are the common modules: a commodity layer available to all.
Here, contributions must be made on a patent and copyright royalty free basis under either the Foundation Public License (Common Capable derivative) or an Open Source License. These common modules must be available in a device if it is to be LiMo-compliant. For this code base, the full patent non-assert applies for anyone developing against the code (members and non-members).
Highlighted in yellow, non-common modules, an optional layer.
Contributions can be made under the Foundation Public License (Non-common-capable derivative) or a proprietary license on reasonable and non-discriminatory terms. These modules are not required on LiMo-compliant devices, but may be there. Only a limited patent non-assert applies.
Build a common and shared software platform offered to all members at a competitive price (mutualisation of the costs through membership fees rather than royalties)
I’d like to show you how the various IPR and license policies are managed now.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
If you use or contribute non-common code, the patent non-assert is limited to only between members, not for commercial external distribution.
Caveats: existing ecosystems are not affected by such safe IP harbour limited to LiMo. For example, industry standards and pooled patents are excluded. If you combine common and non-common, you are excluded from the non-assert.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
Since inception, we are approaching 1 billion subscribers managed by carrier members.
How did we get strong industry backing?
First, you need a strong and balanced Board, with all parts of the mobile value system represented
Second, you need backing based upon committed engagement (through membership and active participation)
Third, you need the capacity to rapidly deliver real handsets to consumers - something our handset manufacturer members have a strong track record of.
accompanied by those 23 handsets on the market with type 1 compliance.
http://www.limofoundation.org/en/technical-documents.html
accompanied by those 23 handsets on the market with type 1 compliance.
http://www.limofoundation.org/en/technical-documents.html
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
Note that for Linux Kernel and System Services, no code is contributed but minimum version of 2.6.x and 2.4.x were specified.
By the end of the year all the frameworks identified for R2 will have been contributed; the platform will continue to evolve based on market and member requirements in 2009 and beyond.
ref: http://www.limofoundation.org/en/limo-handsets.html
Members will be releasing SDKs that will allow you to create applications on their handsets by Mobile World Congress in March 2009.
Later in 2009 we anticipate SDKs that allow a higher degree of application portability.
Also SDKs for Web and Java.
Reference:
http://www.engadgetmobile.com/2008/03/31/limo-platform-release-1-gets-loosed-r2-to-come-later-this-year/
- differentiation means there’s not one common interface across all handsets
- but only apple guarantee this, and they have small market share
- even android may be fragmented
- requires knowledge of linux software stack
- but existing desktop skills transferable
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
- Some have more handsets currently
- Some have more developers currently
- Some have more marketing budgets currently
Bet on the penguin and industry momentum.
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
LiMo strongly believes in the value of collaborative development through sharing of code and ensuring reciprocal flow of innovation as the way to drive innovation in our Platform
- none
It’s the linux desktop software stack
- none
It’s the linux desktop software stack
- none
It’s the linux desktop software stack
- none
It’s the linux desktop software stack
- none
It’s the linux desktop software stack
- none
It’s the linux desktop software stack
Full development environments will be available early 2009
Innovate IPR model: collaborative source development approach. Inclusive of all licensing models.
Open Source principles: code as a commodity with open access to source and with patent / copyright protection for developers.