Open development/Why the closed packages

(List of outstanding requests that are still relavent: fix some typos, format links)
(List of outstanding requests that are still relevant)
Line 106: Line 106:
* Support for non-standard WPA keys or passphrases. Relavent bugs are [https://bugs.maemo.org/show_bug.cgi?id=9864 9864] and [https://bugs.maemo.org/show_bug.cgi?id=1002 1002]. Code that needs releasing is source for connui-iapsettings, connui-iapsettings-wlan and connui-conndlgs-internet (plus their dependancies) as these are the libraries that relate to setting the WPA key. http://www.internettablettalk.com/wiki/index.php/HOWTO:_WPA-PSK_when_you_only_have_the_64-hexit_PSK,_no_passphrase claims that its possible to manually set the key via gconf editing so all we need is to be able to change the UI for this. Opening the connectivity UI (control panels, status widgets etc) would also allow other useful enhancements such as improved output of signal strength for WiFi and cellular. [https://bugs.maemo.org/show_bug.cgi?id=11923 Bug 11923] is a related bug for the UI stuff.
* Support for non-standard WPA keys or passphrases. Relavent bugs are [https://bugs.maemo.org/show_bug.cgi?id=9864 9864] and [https://bugs.maemo.org/show_bug.cgi?id=1002 1002]. Code that needs releasing is source for connui-iapsettings, connui-iapsettings-wlan and connui-conndlgs-internet (plus their dependancies) as these are the libraries that relate to setting the WPA key. http://www.internettablettalk.com/wiki/index.php/HOWTO:_WPA-PSK_when_you_only_have_the_64-hexit_PSK,_no_passphrase claims that its possible to manually set the key via gconf editing so all we need is to be able to change the UI for this. Opening the connectivity UI (control panels, status widgets etc) would also allow other useful enhancements such as improved output of signal strength for WiFi and cellular. [https://bugs.maemo.org/show_bug.cgi?id=11923 Bug 11923] is a related bug for the UI stuff.
* Proper ability to query all aspects of battery status (including on MeeGo). Relevant bug is https://bugs.maemo.org/show_bug.cgi?id=11922 11922]. Requires releasing development package for libbmeipc so we can talk to that library (which exists on both maemo and MeeGo) and do things like getting information on what sort of charger is connected, how much juice is in the battery etc. Anything sensitive (i.e. "use this the wrong way and you could damage the battery") could be removed when publishing this package.
* Proper ability to query all aspects of battery status (including on MeeGo). Relevant bug is https://bugs.maemo.org/show_bug.cgi?id=11922 11922]. Requires releasing development package for libbmeipc so we can talk to that library (which exists on both maemo and MeeGo) and do things like getting information on what sort of charger is connected, how much juice is in the battery etc. Anything sensitive (i.e. "use this the wrong way and you could damage the battery") could be removed when publishing this package.
-
*Better control over which network the phone will connect to (e.g. letting you set a "home" WiFi network that it will always connect to no matter what. Relavent bug is [https://bugs.maemo.org/show_bug.cgi?id=11924 11924]. What needs to be opened up is the source for (and required headers for) the ICD2 policy plugins (libicd_policy_*) so we can understand how they work and modify/enhance them (or write our own new policy plugin).
+
*Better control over which network the phone will connect to (e.g. letting you set a "home" WiFi network that it will always connect to no matter what. Relavent bug is [https://bugs.maemo.org/show_bug.cgi?id=11924 11924]. What needs to be opened up is the source for (and required headers for) the ICD2 policy plugins (libicd_policy_*) so we can understand how they work and modify/enhance them (or write our own new policy plugin). Having this source code may also allow [https://bugs.maemo.org/show_bug.cgi?id=8460 Bug 8460] to be solved (i.e. gaining control of how the code determines which GPRS APN it chooses to connect to). It may be that the policy plugin infrastructure is not fine-grained enough for this in which case the entire source code to the ICD daemon may be required.
*Better control of various hardware components such as accelerometer, keypad lighting, status LED, vibrator, screen brightness and others. Relevant bug is [https://bugs.maemo.org/show_bug.cgi?id=11794 11793]. There is open source code for this [http://meego.gitorious.org/meego-middleware/mce in the MeeGo repositories] but it is not a match for the Maemo version and is missing pieces required to use it with Maemo.
*Better control of various hardware components such as accelerometer, keypad lighting, status LED, vibrator, screen brightness and others. Relevant bug is [https://bugs.maemo.org/show_bug.cgi?id=11794 11793]. There is open source code for this [http://meego.gitorious.org/meego-middleware/mce in the MeeGo repositories] but it is not a match for the Maemo version and is missing pieces required to use it with Maemo.
-
*Ability to support features of the cellular modem not currently supported by the telephony stack in use (whether that stack is the maemo stack, ofono on MeeGo, ogsmd on FreeSmartPhone or otherwise). The relevant bug is [https://bugs.maemo.org/show_bug.cgi?id=11921 11921]. What needs to be opened at a minimum is permission to use the header files we already have but ideally release of correct headers for the N900 cell modem (the headers we have are not a 100% match in a number of cases)
+
*Ability to support features of the cellular modem not currently supported by the telephony stack in use (whether that stack is the maemo stack, ofono on MeeGo, ogsmd on FreeSmartPhone or otherwise). The relevant bug is [https://bugs.maemo.org/show_bug.cgi?id=11921 11921]. What needs to be opened at a minimum is permission to use the header files we already have but ideally release of correct headers for the N900 cell modem (the headers we have are not a 100% match in a number of cases such as SMS)
*firmware image file format and flash tool source. Relevant bugs include [https://bugs.maemo.org/show_bug.cgi?id=7964 7964], [https://bugs.maemo.org/show_bug.cgi?id=4871 4871] and [https://bugs.maemo.org/show_bug.cgi?id=11809 11809]. Seems like there was interest in opening up some/all of this stuff (flashing tool, firmware image format, firmware builder) in the past from Nokia but there was no community interest at the time. Not sure if there is still community interest but it might be worth having this. Would allow porting to OSs not supported by Nokia (such as x86_64 linux) as well as potentially enhancing the tools.
*firmware image file format and flash tool source. Relevant bugs include [https://bugs.maemo.org/show_bug.cgi?id=7964 7964], [https://bugs.maemo.org/show_bug.cgi?id=4871 4871] and [https://bugs.maemo.org/show_bug.cgi?id=11809 11809]. Seems like there was interest in opening up some/all of this stuff (flashing tool, firmware image format, firmware builder) in the past from Nokia but there was no community interest at the time. Not sure if there is still community interest but it might be worth having this. Would allow porting to OSs not supported by Nokia (such as x86_64 linux) as well as potentially enhancing the tools.
[[Category:Development]]
[[Category:Development]]
[[Category:Community]]
[[Category:Community]]

Revision as of 10:09, 17 February 2011

Contents

Reasons

Open source is the licensing model preferred by Nokia in the development of Maemo. There are some reasons to have exceptions, though.

  • Brand: Nokia wants to keep a strong brand and identity avoiding any risks of dilution.
  • Differentiation: Nokia wants to gain competitive advantage in certain areas by keeping the related software closed.
  • Legacy: Nokia keeps some components minimally maintained - the work of opening them has an unclear outcome.
  • IPR & licensing issues: Nokia avoids serious risks brought by patents, copyrights or complicated licensing situations.
  • Security: Nokia avoids safety risks and liabilities that could be caused by freeing access to certain hardware components.
  • Third party: Nokia does not own the code and therefore does not decide on the license.

Specific reasons for packages

This list needs update as it mostly refers to Maemo 4.1.

  • tablet-browser-ui: At the beginning there was a proprietary browser. In Maemo 4.0 the Mozilla based browser came, with an open engine (MicroB) but still a closed UI provided by tablet-browser. The main reason was the default rule to have the Maemo applications UI closed for differentiation. The context in mobile browsing has changed significantly and now there are better reasons to offer also an open browser UI. This is the plan for Fremantle.
  • Bookmark manager: Closed because of legacy and the default rule to have the UI application layer closed. However, the licensing of this component is being reviewed and it could be opened in Fremantle. Filing an enhancement request and seeing the interest and potential use cases would be something the community could do. Deadline: Fremantle beta SDK release.
  • Media player: Currently closed because of the default criteria of UI differentiation. In progress, though. The engine is being opened in Fremantle, in the form of a Media Application Framework also available for third parties. The UI is open for discussion, as you can see in the Comment #5 of the enhancement request. For instance, it would count a lot seeing a will to converge efforts and contribution from the many third party media player projects.
  • Connection applet: Legacy. The applet itself is not much but it unveils all the Connectivity middleware which is also closed. The whole Connectivity framework is having major changes in Fremantle and Harmattan, and the resould could be a much open framework altogether (applet included). Too soon to tell.
  • Display applet: Legacy. Opening it could be considered if really needed. From the comments in the bug report it looks like the need is not that big though?
  • Location framework: Differentiation. Nokia is investing heavily in location software and services, that are planned to be implemented in Maemo during Fremantle and Harmattan.
  • libmetalayer: Legacy. Substituted in Fremantle by open source upstream Meta Tracker. See this comment about the possibility to open it still.
  • osso-dsp-modules: DSP component provided by Texas Instruments. Note that the DSP packages provided by Nokia are open source: osso-dsp-loader, osso-dsp-headers. If you are interested in open source DSP development then DSP Gateway (developed by Nokia) might get your attention. However, the introduction of PulseAudio in Fremantle gives an opportunity to platform developers to forget about the DSP completely.
  • dsme: This component covered many areas including power management, which is considered a differentiation area by Nokia. The component has been redesigned and the sensitive functionality has moved to mce, allowing to distribute dsme (soon) with an open license together with related tools and plugins: bootstate, dsmetool, waitfordsme, libdsme.so, libhwwd.so, liblifeguard.so, libprocesswd.so, libstartup.so and libstate.so. Then libtemperature.so will be replaced by another component consisting of several dsme open source plugins. Finally, libcalmodule.so will be dropped.
  • bme - Battery Management Entity: Security. A misuse of the could lead to serious battery damages that could result in liabilities for Nokia. hald-addon-bme is a related package, also closed.
  • mce - Mode Control Entity: Initially closed for differentiation because of its impact in battery life, an area where Nokia strives to excel. Nowadays the differentiation aspect is lighter but legacy plays a role as well.

Not in the device but also relevant:

  • Flasher: Utility to flash the device from a Linux computer. Currently closed for legacy, considering the move to an open project to ease and encourage the development of versions not supported by Nokia e.g. Mac OS X and PowerPC.

Requesting the opening of closed components

If you want a Nokia closed component to be open, please see Open_development/Licensing_change_requests

The chances of success of your proposal will probably depend on how it fits within the following reasons for a relicensing:

  1. Fixing a bug: The package is in non-free although it looks like it's actually an open piece of software. In this case forget about Brainstorm and simply file a bug and CC maemo.org distmaster on carsten.munk at gmail.com.
  2. Nurturing application development: There is a strong argument proving that opening a component will bring more and better apps for end users.
  3. Spread of Maemo driven technologies to other platforms: A component fits well in a gap existing in other Linux/OSS based projects and there is a concrete interest on collaborating and contributing to a component if it's opened.
  4. Community maintenance: A component is receiving low attention from the official maintainers even if it has high attention from the community and there are developers volunteering to contribute to it if the source code is available.
  5. Better architecture: Probably covered by 2 or 3 but just in case. A closed component is sitting in the midle of open components making things more difficult that needed to developers interested in that area.

Waiting list

If you want to know the specific reasons for a package to be closed please list it below and the Maemo team will answer as time permits. You can also add comments to a certain package to drive attention/priority to it.

Requested at Bug 1584 including comments:

  • File Manager
  • activate_panel
  • bt-cal
  • cal-tool
  • fb-chaimage
  • text2screen
  • wlan-cal
  • wlan-fw-update
  • retu-time
  • show_image
  • battest
  • dspctl - this is available in the open osso-dsp-loader package.
  • the script linuxrc
  • libbmeic.so
  • libcal.so
  • libppu.so
  • libactivitymonitor.so
  • libinactivity-blank.so
  • libperipheral.so
  • BME
  • libi18n-locale-resolver0

These packages are included in the nokia-binaries metapackage offered with the Maemo SDK:

  • hildon-task-navigator-bookmarks
  • osso-bookmark-menu->osso-bookmark-engine->osso-bookmark-user
  • osso-browser-translations-dev
  • libaccounts-dev ->libaccounts0
  • libaccounts-doc
  • libosso-abook-dev ->libosso-abook
  • libosso-rtcom-accounts-dev ->libosso-rtcom-accounts0
  • libosso-rtcom-accounts-doc
  • osso-addressbook ->libcontact-importexport
  • osso-contact-plugin-dev ->osso-contact-plugin
  • osso-mission-control ->libplayback-1-0 ->libimlogger0
  • libconbtui0 ->
  • liblocation-dev ->liblocation0
  • libossoproductinfo0 ->libdsme0
  • libgpsbt-dev ->libgpsbt
  • libgpsmgr-dev ->libgpsmgr
  • libogs1.2-dev ->libogs1.2-1 ->libosso-filemanager-interface
  • id3search -> libmetalayer0 ->libgisds-gtk-dialog0 ->libgisds0
  • osso-global-search
  • osso-applet-certman ->certs ->osso-clock
  • libosso-certman-dev ->libosso-certman1
  • osso-help-ui

Other Requests:

  • mnotify (Webmail Notifier) - Open source could allow it to support other webmail providers, and fix minor issues like bug 2066 as it is apparantly low priority for Nokia. Note: mnotify was dropped for Maemo5 by Nokia.
  • telepathy-spirit - This connection manager might be useful for people using Telepathy framework and Skype on desktop computer.
  • getbootstate
  • Calendar - will remain closed for Fremantle and MeeGo.

Opened

List of outstanding requests that are still relevant

  • Cell Broadcast SMS support. Relevant bugs are 8347 and 10870. Code that needs releasing is source for libsms and libcsd-sms (plus headers needed to compile it). For the userspace bits, it would be ideal (but not essential) to have source code or -dev packages for the connectivity UI shared libraries (libconnui, libconnui-cellular etc). Opening up the SMS code would allow other enhancements (such as a low level method to filter SMSs before they even get written to any permanent storage). Bug 11923 is the relevant bug for the UI stuff.
  • Support for non-standard WPA keys or passphrases. Relavent bugs are 9864 and 1002. Code that needs releasing is source for connui-iapsettings, connui-iapsettings-wlan and connui-conndlgs-internet (plus their dependancies) as these are the libraries that relate to setting the WPA key. http://www.internettablettalk.com/wiki/index.php/HOWTO:_WPA-PSK_when_you_only_have_the_64-hexit_PSK,_no_passphrase claims that its possible to manually set the key via gconf editing so all we need is to be able to change the UI for this. Opening the connectivity UI (control panels, status widgets etc) would also allow other useful enhancements such as improved output of signal strength for WiFi and cellular. Bug 11923 is a related bug for the UI stuff.
  • Proper ability to query all aspects of battery status (including on MeeGo). Relevant bug is https://bugs.maemo.org/show_bug.cgi?id=11922 11922]. Requires releasing development package for libbmeipc so we can talk to that library (which exists on both maemo and MeeGo) and do things like getting information on what sort of charger is connected, how much juice is in the battery etc. Anything sensitive (i.e. "use this the wrong way and you could damage the battery") could be removed when publishing this package.
  • Better control over which network the phone will connect to (e.g. letting you set a "home" WiFi network that it will always connect to no matter what. Relavent bug is 11924. What needs to be opened up is the source for (and required headers for) the ICD2 policy plugins (libicd_policy_*) so we can understand how they work and modify/enhance them (or write our own new policy plugin). Having this source code may also allow Bug 8460 to be solved (i.e. gaining control of how the code determines which GPRS APN it chooses to connect to). It may be that the policy plugin infrastructure is not fine-grained enough for this in which case the entire source code to the ICD daemon may be required.
  • Better control of various hardware components such as accelerometer, keypad lighting, status LED, vibrator, screen brightness and others. Relevant bug is 11793. There is open source code for this in the MeeGo repositories but it is not a match for the Maemo version and is missing pieces required to use it with Maemo.
  • Ability to support features of the cellular modem not currently supported by the telephony stack in use (whether that stack is the maemo stack, ofono on MeeGo, ogsmd on FreeSmartPhone or otherwise). The relevant bug is 11921. What needs to be opened at a minimum is permission to use the header files we already have but ideally release of correct headers for the N900 cell modem (the headers we have are not a 100% match in a number of cases such as SMS)
  • firmware image file format and flash tool source. Relevant bugs include 7964, 4871 and 11809. Seems like there was interest in opening up some/all of this stuff (flashing tool, firmware image format, firmware builder) in the past from Nokia but there was no community interest at the time. Not sure if there is still community interest but it might be worth having this. Would allow porting to OSs not supported by Nokia (such as x86_64 linux) as well as potentially enhancing the tools.