[maemo-developers] ... and QA of closed source applications?
From: Jeremiah Foster jeremiah at jeremiahfoster.comDate: Wed May 6 13:52:16 EEST 2009
- Previous message: ... and QA of closed source applications?
- Next message: ... and QA of closed source applications?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On May 6, 2009, at 12:33, Henrik Hedberg wrote: > Quim Gil wrote: > >> In the "QA from extras-devel to extras-testing" thread we are >> discussing >> a community quality process that relies heavily on the fact that the >> source code of an application and its dependencies is available. But >> happens with the closed source applications? > > This is a very important question, and even if some members of the > maemo.org community may be hard core open source software I am one of those I'm afraid. > enthusiastic > using only free software in their devices, the reality is that there > are > even more opportunities to get very good software for the devices if > we > allow also non-free software to be a part of our community supported > extras repository. Do you have some examples? I am sure you are right, I just would like to know which apps. > >> There have been very popular and even community friendly apps that >> were >> not open source, like Mauku or Canola. > > Just to clarify: Mauku was a closed source software at the very > beginning, but the source code has been available and licensed under > APLv2 since November 8, 2007. See http://garage.maemo.org/projects/mauku This is very interesting, why did you open the source? What did you see as the advantages? > >> - Keep the same QA process where availability of source code is not >> determinant, > > I think the QA process of free and also non-free packages will be > based mainly on usage of the software. The source code is not so > important in either situation. Earlier, there were some thoughts about > packages that are maintained by a maintainer who do not know the > programming language of the software they are packaging. > Respectively, I > claim that the most of future extras testers will not be able to track > the functionality of the software they are testing into source code > level (they do not know the language, the source code is too > complicated, there are too many lines to read, they have not enough > time > etc.). For example, how many of Mauku users have really checked what > kind of dirty tricks I am doing with their Jaiku and Twitter accounts > even if the source code has been available for a long time? > > Let's see, your criteria for extras applications were: > >> - Install and deinstall flawlessly. >> - Don't bring conflicts in dependencies. How do we know they are not violating the GPL if they rely on GPL'd libraries but don't ship their source? Those 'dependencies' may require them to ship the source, that is a major conflict. >> - Their info in the app manager is complete (icon, summary, URL to >> project, updates info). >> - Have decent page in maemo.org/downloads. >> - Have a place to report issues to the developers. >> - Don't crash or freeze systems. >> - Don't drain batteries. >> - Are feature complete: everything inside works. >> - Have been tested by someone trusted before. > > None of these criteria requires the source code to be available. Thus, > the QA for non-free packages in extras should be the same than for > free > packages. There are some problems still. For example, will Nokia face a patent lawsuit if it ships software which violates patents? How do you know the software does not violate patents if you do not have the source? Quim, could you explain Nokia's position on patented software in closed applications available for Maemo? Are they cognizant that even with a disclaimer they may be subject to a patent lawsuit like the recent TomTom case? In most cases patents only bring uncertainty and risk, this is why having the source code matters. Jeremiah
- Previous message: ... and QA of closed source applications?
- Next message: ... and QA of closed source applications?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]