• Intro
• Downloads
• Community
• Development
• News
• TALK

Open development/Licensing change requests

Please note that this process is effectively dead. Please see http://talk.maemo.org/showpost.php?p=784443 for details. Summary: Nokia doesn't have a Maemo distmaster anymore to process these requests, and does not plan to allocate further resources for Maemo to change this, rather than just trying to make the corresponding Meego components open.

Note: *Nothing* was ever opened via this process.

[edit] The licensing change requests queue

The idea of the licensing change request queue, is to have the ability to prioritise what components should be sent through the machinery that in the end decides if something is open sourced or not and in which order.

The idea is that we need to get licensing change requests prioritised in an order as to make it possible for a Nokian to be able to look at a page, select one or more of the top licensing change requests and then without bigger effort send this through the internal machinery for open sourcing and hence getting it to happen (or a decision made that the change won't happen).

Keep in mind such a process can take quite a while.

See the current licensing change request queue here.

The ones with most votes and highest priority will be considered first to be sent into the internal machinery. Click the linked numbers to see which licensing requests match the priority and votes. There's a bug so there's no summary of how many bugs a link covers. Will be fixed.

When being sent into the internal machinery, they move to the list below:

Current licensing requests being considered

Requests already considered

[edit] Submitting a licensing change request

These requests are based on the maemo.org bugzilla. To enter a request, click here. You will need to create a bugzilla account.

We kindly ask you to use this form (answer the questions) instead of the provided one in Bugzilla. Requests won't be evaluated otherwise. Remove the previous 'Description:' contents in the form and copy and paste this and fill it in:

Which component(s) or source packages is the licensing change request about?

Which area is the component in (if you know)? (See the openness progress reports at http://mer-project.blogspot.com/2010/02/mapping-openness-of-maemo-50-pr11-and.html)

What is the current licensing of the component?

What licensing would you like it to be and why? Examples can be:
open source and openly developed (move to gitorious), open source (select a license), non-free but redistributable, non-free, published in nokia-binaries, document the functionality, etc.

Which project(s) would benefit from this licensing change request?

What technical purpose do you/your project(s) have for wanting the licensing change?

[edit] What happens when you have submitted a request

The maemo.org distmaster (Stskeeps/Carsten Munk) will then:

• Verify if a request has already been filed (marking DUPLICATE if so) or evaluating if we need to reevaluate the licensing request due to changed circumstances.

• Evaluate the technical purpose and see if the end result of open sourcing the component would actually make this possible (marking INVALID if it doesn't make this possible and encouraging filing a request against another component that has the functionality)

From then on, the idea is to determine the priority of the request (High, Medium, Low)

• If open source replacements exist (making licensing change less of a priority)

• If it aids the implementation of open source replacements (making licensing change more of a priority)

• Give a preliminary evaluation on potential problems regarding reasons in the 'Reasons for closed packages' - these reasons make licensing change less of a priority unless it's worth exploring if it is actually problematic.

• Give a preliminary evaluation on the technical purpose regarding reasons mentioned at the Relicensing reasons section - these reasons make licensing change more of a priority.

• Is there one or more projects that would have benefit of this? (more of a priority)

Based on the queue, a Nokian picks off the items and pushes them into the internal machinery, assigning the bug to him/herself. General rule is taking high priority change requests combined with votes. You will be notified when distmaster evaluates and when the change request has been passed into the internal machinery.

[edit] Reasons for closed packages

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.

[edit] Relicensing reasons

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.