[maemo-developers] Double checking free/nonfree packages

[From: Christopher Allan Webber]

So first of all, I'd like to note that I was very happy to wake up to
thse replies, particularly this one.  It does raise a lot of confidence.

> Can it be that we start having several iniciatives like this spread in
> different places? At the end the goal is the same: Maemo as open as
> technically possible being still stable and full featured.
>
> It would be really useful to have the one and only list of closed
> components prioritized by community interest. An openness backlog for
> people like me to work on.

Yes, I agree, forking this kind of documentation is not ideal .  I think
Nokia has made it clear that it sees free and open source software as a
means, whereas I and some others see it as an ends in itself.  However,
it would be to the benefit to all of us if we collaborate here.  I will
move my list over to the Maemo wiki tonight, when I am done with work.

For now there seem to be two main pages on which the documentation of
what is free/nonfree is:
 - http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Architecture/Top_Level_Architecture
 - http://wiki.maemo.org/Why_the_closed_packages

The first contains that rather informative graph, but I suspect that the
intended purpose of that page would be made less useful if we put all of
the documentation of free/nonfree components on there.  The second one
seems to be a good start, but I think the naming of that particular page
helps defeat our purpose, as it seems to say "here is why these are
closed" as just an explanation, and does not indicate "this is a record
of pieces that we are working to free."  So, unless there are any
objections, I think it would be better to start a page with a name such
as Free_Maemo or something similar that indicates a kind of "free and
open source todo-list" that I think everyone here seems to want.  I'll
work on incorporating the "Why the closed packages" page within that
document, and if that proves to be satisfactory, we can probably have
the Why_the_closed_packages page redirect to the new one.

> The criteria to prioritize components could be (improvising a bit, feel
> free to suggest improvements):
>
> 1. Fixing a bug. I mean a real objective bug: package is in non-free
> although it looks like it's actually an open piece of software.
>
> 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.

These seem reasonable points.  I'll be sure to have that guide indicated
on the page.

> There is no problem having the source file public, but the good solution
> is to simply update the source image and link to it instead of forking
> it. Otherwise the chances of you having a version different to the one
> in the official documentation is high, when there should not be any
> reason to show anything different.

Yes, I think that if we are going to be keeping things on the maemo
wiki, it makes sense to have one image there.  Then both the "Top Level
Architecture" and the "Free Maemo" (or whatever) page can both share the
same image.

Thanks for the great responses, all!  I'll work on documenting this
tonight.
 - cwebb