Collaborative Development for the future of Mobile
•Descargar como ZIP, PDF•
0 recomendaciones•998 vistas
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Collaborative Development for the future of Mobile
Similar a Collaborative Development for the future of Mobile (20)
Más de Andrew Savory
Más de Andrew Savory (14)
Último
Último (20)
Collaborative Development for the future of Mobile
- 1. Collaborative development for the future of mobile Fachkonferenz, 3rd December 2008
- 3. Why LiMo?
- 5. 1 2 2.1 2.11 2.12 3.0 4.0 4.1 4.2 5.0 5.2.318 (6) 5.2.19202 (6.1) 5.2.20757 (6.1.4)
- 14. What is LiMo?
- 16. Not a standards body
- 21. 52 members
- 24. Goals
- 27. What makes LiMo especially attractive for Mozilla is that it’s all about code, where previous efforts around mobile Linux have been more focused on developing standards. - Jay Sullivan, Mozilla
- 30. 2003
- 31. 2003
- 34. Free from business model conflicts
- 35. Free from business model conflicts
- 36. Free from business model conflicts
- 38. Content Applications User Interface Operating System
- 39. Content Applications User Interface LiMo Platform Middleware Limited scope for competitive differentiation but high strategic Operating System importance due to potential to be used as a control point within a wider business agenda and very high switching costs
- 40. Content Applications User Interface User Interface As selected by the handset maker / network operator LiMo Platform Middleware Limited scope for competitive differentiation but high strategic Operating System importance due to potential to be used as a control point within a wider business agenda and very high switching costs
- 41. Content Applications Applications As selected by the mobile consumer User Interface User Interface As selected by the handset maker / network operator LiMo Platform Middleware Limited scope for competitive differentiation but high strategic Operating System importance due to potential to be used as a control point within a wider business agenda and very high switching costs
- 42. Content Content As selected by the mobile consumer Applications Applications As selected by the mobile consumer User Interface User Interface As selected by the handset maker / network operator LiMo Platform Middleware Limited scope for competitive differentiation but high strategic Operating System importance due to potential to be used as a control point within a wider business agenda and very high switching costs
- 43. Open Governance
- 48. Open access to source code by LiMo Members
- 49. Open access to source code by LiMo Members
- 50. Open APIs
- 57. Member intends to contribute
- 58. Member intends to contribute Requirements Council evaluation
- 59. Member intends to contribute Requirements Council evaluation Contribution of the code
- 60. Member intends to contribute Requirements Council evaluation Contribution of the code Working Group evaluation
- 61. Member intends to contribute Requirements Council evaluation Contribution of the code Working Group evaluation Architecture Council classification
- 63. Licensing models
- 64. Licensing models
- 65. Licensing models
- 67. Common
- 68. Common Non-Common
- 69. Common Non-Common Foundation Member Public License Projects (Common Capable)
- 70. Common Non-Common Foundation Member Public License Projects (Common Capable) Open Source Open Source License Projects
- 71. Common Non-Common Foundation Member Public License Projects (Common Capable) Open Source Open Source License Projects
- 72. Common Non-Common Foundation Foundation Member Member Public License Public License Projects Projects (Common Capable) (Non-Common Capable) Open Source Open Source License Projects
- 73. Common Non-Common Foundation Foundation Member Member Public License Public License Projects Projects (Common Capable) (Non-Common Capable) Open Source Member Open Source License Proprietary License Projects Projects
- 74. Common Non-Common Foundation Foundation Member Member Public License Public License Projects Projects (Common Capable) (Non-Common Capable) Open Source Member Open Source License Proprietary License Projects Projects
- 75. Common Non-Common Foundation Foundation Member Member Public License Public License Projects Projects (Common Capable) (Non-Common Capable) Open Source Member Open Source License Proprietary License Projects Projects
- 76. Common Modules Framework Core, hardware independent and geographic-market independent functionality for a certain type or class of Modules Non-Common Modules Plugin Plugin Plugin Proprietary license Open Source license FPL
- 77. Common Modules Framework Core, hardware independent and geographic-market independent functionality for a certain type or class of Modules Non-Common Modules Plugin Plugin Plugin Proprietary license Open Source license FPL
- 78. IP Safe Harbour
- 80. Applications Foundation API Framework Framework Framework API Plugin Plugin Plugin Plugin Linux Kernel Chipset Architecture
- 81. Applications Foundation API Framework Framework Framework API Plugin Plugin Plugin Plugin Linux Kernel Chipset Architecture
- 82. Applications Foundation API Framework Framework Framework API Plugin Plugin Plugin Plugin Linux Kernel Chipset Architecture
- 83. Strong
- 84. Balanced
- 86. Common Non-Common Foundation Foundation Public License Public License (Common Capable) (Non-Common Capable) Open Source License Proprietary License
- 87. Common Non-Common Foundation Foundation Public License Public License (Common Capable) (Non-Common Capable) Open Source License Proprietary License Full patent non-assert including commercial distribution to non-members
- 88. Common Non-Common Foundation Foundation Public License Public License (Common Capable) (Non-Common Capable) Open Source License Proprietary License Full patent non-assert Patent non-assert including commercial limited to distribution distribution to non-members between members
- 89. Common Non-Common Foundation Foundation Public License Public License (Common Capable) (Non-Common Capable) Open Source License Proprietary License Full patent non-assert Patent non-assert including commercial limited to distribution distribution to non-members between members Industry Standards and pooled patents are excluded from the scope of the IPR policy
- 90. Common Non-Common Foundation Foundation Public License Public License (Common Capable) (Non-Common Capable) Open Source License Proprietary License Full patent non-assert Patent non-assert including commercial limited to distribution distribution to non-members between members Industry Standards and pooled patents are excluded from the scope of the IPR policy Combinations are excluded from the scope of the IPR policy
- 94. Board
- 95. Board Backing
- 97. Release 1
- 98. Release 1
- 100. R1 Platform Scope
- 101. Application Layer Application / UI Framework & Application Engine Layer Middleware Layer Kernel Layer
- 102. Application Layer Application / UI Framework & Application Engine Layer Middleware Layer Linux Kernel Device Drivers Modem Interface
- 103. Application Layer Application / UI Framework & Application Engine Layer System Telephony Networking Security Multimedia Database Services Framework Framework Framework Framework Engine Dev Mgmt Location Accessory Data Sync Logging DRM Java VM Framework Framework Framework Framework Framework Framework Linux Kernel Device Drivers Modem Interface
- 104. Application Layer Application / UI Framework & Application Engine Layer Terminal Services API System Telephony Networking Security Multimedia Database Services Framework Framework Framework Framework Engine Dev Mgmt Location Accessory Data Sync Logging DRM Java VM Framework Framework Framework Framework Framework Framework Linux Kernel Device Drivers Modem Interface
- 105. Application Layer Application Application Internet Messaging Database Future Manager UI Framework Framework Services Expansion Framework Framework Terminal Services API System Telephony Networking Security Multimedia Database Services Framework Framework Framework Framework Engine Dev Mgmt Location Accessory Data Sync Logging DRM Java VM Framework Framework Framework Framework Framework Framework Linux Kernel Device Drivers Modem Interface
- 106. Application Layer Application Manager & UI API Application Engine API Application Application Internet Messaging Database Future Manager UI Framework Framework Services Expansion Framework Framework Terminal Services API System Telephony Networking Security Multimedia Database Services Framework Framework Framework Framework Engine Dev Mgmt Location Accessory Data Sync Logging DRM Java VM Framework Framework Framework Framework Framework Framework Linux Kernel Device Drivers Modem Interface
- 107. Application Phone Browser MMS/SMS PIM Utilities Camera SIM toolkit Manager Applications Data Multimedia Other Settings Contacts Java App Email & IM Applications Applications Applications Application Manager & UI API Application Engine API Application Application Internet Messaging Database Future Manager UI Framework Framework Services Expansion Framework Framework Terminal Services API System Telephony Networking Security Multimedia Database Services Framework Framework Framework Framework Engine Dev Mgmt Location Accessory Data Sync Logging DRM Java VM Framework Framework Framework Framework Framework Framework Linux Kernel Device Drivers Modem Interface
- 108. 23 handsets
- 109. SDKs
- 110. SDKs
- 111. Native, Web, Java
- 112. Challenges
- 118. As the development community looks at how best to bring new applications to the marketplace, they should check out LiMo and Linux Mobile first. - Kyle Malady, Vice President of Network for Verizon
- 119. As the development community looks at how best to bring new applications to the marketplace, they should check out LiMo and Linux Mobile first. - Kyle Malady, Vice President of Network for Verizon
- 122. Sharing of code
- 124. Reciprocal flow of innovation
- 127. GTK Bellagio GStreamer GConf D-Bus Linux
- 128. Challenges for engineers
- 129. Work in progress
- 130. Conclusion
- 131. Conclusion • An industry-driven initiative • An innovative IPR model tailored to foster collaboration at the code level • Based on Open Source principles
- 132. Thank you! andrew.savory@limofoundation.org http://www.limofoundation.org/
Notas del editor
- Good afternoon, thank you for inviting me here to speak today about the LiMo Foundation. 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.
- I’d like to start by looking at the mobile world a couple of years ago, to answer the question: 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/
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- For many years there has been extensive mobile platform proliferation. 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
- But it’s more complicated than just dozens of platforms with dozens of versions. 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.
- Developing for every platform and for every operator quickyl leads to increasingly unmanageable complexity. 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.
- Wouldn’t it be great if all the handset manufacturers, network operators and software developers got together to work on reducing this fragmentation? If we had convergence around a few common platforms, we would significantly reduce the burden of development, maintenance and support.
- That’s exactly what happened. 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.
- The initial founders were soon joined by more core members, including the most prominent names in the mobile industry, ranging from hardware manufacturers, software vendors to network operators.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- Today LiMo has 52 members, spanning chipset, handset manufacturers, operating system and software companies, open source organisations, network operators and many others.
- So, what exactly is LiMo? I briefly outlined a common goal, to reduce diversity, but now it’s time to look in more detail at what the foundation is.
- Firstly, what LiMo is not: 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.
- Firstly, what LiMo is not: 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.
- Firstly, what LiMo is not: 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.
- Firstly, what LiMo is not: 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.
- Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets. 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.
- Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets. 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.
- Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets. 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.
- Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets. 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.
- Industry consortium: joint venture between all these members, working together to deliver an open, linux-based software platform for handsets. 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.
- And that is what LiMo is. 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?
- So, LiMo’s goals. Other than solving the problem of platform proliferation, what else is LiMo about? I’d like to outline those goals now for you.
- Goal #1: provide a competitive platform 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?
- We make it a competitive platform by going beyond specifications. 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.
- We make it a competitive platform by going beyond specifications. 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.
- We make it a competitive platform by going beyond specifications. 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.
- We make it a competitive platform by going beyond specifications. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- LiMo is also about proven technology. 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.
- based on published roadmap FIXME References to published roadmap? http://www.limofoundation.org/images/stories/pdf/limo%20foundation%20overview%20-%20may08-ext.pdf
- LiMo is about Copyleft. 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.
- LiMo is also about the commercial success of our members. 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.
- Goal #2 is to be free from business model conflicts. 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.
- Goal #2 is to be free from business model conflicts. 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.
- Goal #2 is to be free from business model conflicts. 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.
- Goal #2 is to be free from business model conflicts. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Let’s look at LiMo graphically. 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.
- Goal #3 of LiMo is Open Governance. 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.
- How does LiMo governance compare with other mobile initiatives? 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.
- How does LiMo governance compare with other mobile initiatives? 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.
- How does LiMo governance compare with other mobile initiatives? 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.
- How does LiMo governance compare with other mobile initiatives? 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.
- How does LiMo governance compare with other mobile initiatives? 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.
- collectively developed platform FIXME redo graphic
- As part of our open governance, we are an open organisation. 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.
- As part of our open governance, we provide open access to source code. All our source code contributed under the FPL is available to any company agreeing with the terms of our IP safe harbour.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Any developer can use our APIs to develop applications for the LiMo Foundation Platform and benefits from the safe IP harbour around such APIs. 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.
- Architectural and technical decisions are made collectively according to the process defined in our bylaws. I’d like to explain the process to you now.
- This diagram exemplifies the contribution process for our members. 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.
- This diagram exemplifies the contribution process for our members. 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.
- This diagram exemplifies the contribution process for our members. 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.
- This diagram exemplifies the contribution process for our members. 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.
- This diagram exemplifies the contribution process for our members. 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.
- Another goal of LiMo is to adopt a collaborative approach to development - inclusive of all licensing models.
- Finding the right licensing model is a balancing act, managing the commercial concerns of traditionally very closed businesses with the need for collaborative development. 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.
- Finding the right licensing model is a balancing act, managing the commercial concerns of traditionally very closed businesses with the need for collaborative development. 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- There are two sets of code within LiMo: 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.
- The intention of common modules is to contain core, hardware-independent and geographic-market independent functionality. 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.
- Another Goal of Limo: an IP Safe Harbour. LiMo provides a balanced but strong IP safe harbour for development, intended to foster collaboration and innovation whilst respecting the rights of members.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- This is how the LiMo middleware platform stacks together taking into account areas for collaboration within the safe harbour. 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.
- Foster collaboration and sharing of source code: any member can inspect freely the core of the platform, can share source code, without any risk of being sued for patent infringement from another member 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)
- So any member can create their own innovative products on the top of the platform without losing control of their innovation I’d like to show you how the various IPR and license policies are managed now.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- Here’s how it’s balanced: if you use or contribute common code, which is the most open, you benefit from the most open rights with a full patent non-assert including commercial distribution to non-members. If you write applications against the LiMo API (which is common), you also benefit. 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.
- What’s the state of play: where is LiMo since the start in 2007?
- Our 4th Goal: to have strong industry backing. 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.
- Our 4th Goal: to have strong industry backing. 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.
- Our 4th Goal: to have strong industry backing. 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.
- Our 4th Goal: to have strong industry backing. 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.
- Our 4th Goal: to have strong industry backing. 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.
- We have already had the first release - this is a reference release of the API accompanied by those 23 handsets on the market with type 1 compliance. http://www.limofoundation.org/en/technical-documents.html
- We have already had the first release - this is a reference release of the API accompanied by those 23 handsets on the market with type 1 compliance. http://www.limofoundation.org/en/technical-documents.html
- This diagram illustrates the scope of the LiMo platform.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- This diagram shows the common code scope of R1, and gives an indicator of what may be in the forthcoming R2. 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.
- 23 type 1 handsets available today, from Motorola, NEC, Panasonic, Aplix, LG, Purple Labs ref: http://www.limofoundation.org/en/limo-handsets.html
- SDKs will be available. 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.
- SDKs will be available for building applications natively (GTK, Linux, C) 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/
- Challenges for developers: - 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
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- There are lots of other platforms out there - Some have more handsets currently - Some have more developers currently - Some have more marketing budgets currently Bet on the penguin and industry momentum.
- LiMo is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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 is solidly grounded in Open Source principles 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
- leverages existing standards and open source projects to accelerate the development and acceptance of the Platform.
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- What unusual technologies can be found in LiMo phones? - none It’s the linux desktop software stack
- Platforms, SDKs are work in progress Full development environments will be available early 2009
- Industry-driven initiative: representing most of the players of the mobile industry, broad support from all sectors 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.