There are obvious difficulties to port Fremantle to the Neo900. First of all is lack of manpower.

Currently, the only development on Maemo OS is being done inside CSSU with a very small team of developers, and it's difficult to think that they will be able to maintain both CSSU for N900 and a new port for the Neo900 at the same time.

Even now, CSSU has clear problems due to lack of developers. There is a big gap between CSSU Stable and Testing, kernel is not yet part of CSSU, Thumb is maintained separately...

But also there will be a clash of interests regarding development for N900 and Neo900. For example, open source replacements for closed applications are not entering CSSU, even when they are ready for prime time, and we see that improved/upstream versions of packages are not allowed to be part of it.

That could be fine from a POV of full stability over any other consideration, but a port to a different hardware will require to rewrite as many closed source components as possible.

Because it's not just enough to run an unmodified Fremantle image on the Neo900 with a shiny new kernel. Using closed source applications from Nokia in a non Nokia device, would be illegal, and even if Nokia might not care about it now, it's a clear risk to the project as a C&D could be received at any moment.

I can only suggest that CSSU and Neo900 porting should become a single project, an upstream Maemo/Fremantle OS that could be installed in both devices and maintained at the same time with a minimum set of different packages for the most specific hardware bits. Such a project should try to replace as much closed source components as possible, one by one (unlike Mer tried building a new OS from scratch), without loosing compatibility with most existing software (maybe not 100% of compatibility is possible though).

One possible approach to the porting task, would be to start running Maemo ("Freemantle" anyone?) in other devices, instead of waiting to the Neo900 to be ready. The OpenPandora, for example, would be a perfect sandbox to try out how portable is the system. The classic versions shares most of the hardware with the N900 and it doesn't have the most difficult bits (GPS and GSM), while the new 1GHz version, is very similar to what the Neo900 will offer.

Porting "Freemantle" to the OpenPandora hardware, could also attract some of the very talented developers that they already have.

@ivgalvez check here for ports on other systems :-) http://www.omappedia.com/wiki/Maemo_...etting_Started

I just see a paradox in your argumentation, when you say we have not enough developers (despite we already gained new ones thanks to FPTF) and same post you suggest to replace as many closed bits as possible by rewritten FOSS. I also don't see how FPTF is legally linked to Neo900 and GolDeliCo, so whom to send that C&D to? Who/what is "the project"? The FPTF? I don't think they could stop us from doing what we plan to do. Neo900? Completely unrelated.
Again: GolDeliCo will not ship OS (at least not fremantle) on any Neo900
remember importing MS TrueType fonts into Linux OpenOffice, anybody?

Please notice that I haven't mentioned GolDeliCo in any place of my post. The hardware will be open and there is no problem at all with it.

But a C&D notification could be send to any organization and/or individuals, and even if it's something that could be somehow surpassed, prosecution is not a joke and I can imagine that people involved in the porting task of Maemo would not like to have problems of that nature.

The same way that we do not encourage to distribute commercial applications in this forum.

So I think that, precisely because it would be better to try to avoid as much as possible any problems with Nokiasoft, it would be wise to substitute whatever is possible for FOSS replacements, without compromising existing functionality.

I don't really think that can be done in due time for the Neo900. It would even be impossible to have a 100% free system, but the less closed components, the better.

However, as you already mentioned, such an effort would be really difficult to accomplish with such low amount of resources.

That's why I propose to avoid splitting development between CSSU (maintenance of N900) and porting to Neo900, now that it has barely started. Maybe I wasn't clear enough in my previous post on this respect.

It would be better to keep just one single direction of development for the, now upstream, "Freemantle" OS, even if that means that CSSU cannot achieve 100% compatibility with existing applications, substitute closed source applications for open replacements or increase the development pace, even if that increase the risk of instability.

You say FPTF is better doing ALL porting since it could be dangerous to do SOME porting? Sorry that doesn't make ANY sense to me. Honestly who's violating what and exactly when/by doing what? Sure anybody can send a C&D to anybody else, but the question is to what purpose. A C&D usually has a subject you instruct the other party to stop some behaviour. Please explain what subject you expect to get used in any such anticipated C&D. Again: NOBODY will ship Nokia(C) blobs to anybody. FPTF will provide means to create a system environment in which those blobs can run, we won't deploy them though, User has to get them from his old N900 or whatever other source he may find.

Honestly I don't get it
All I can see is that you try to find an argument to forbid devels doing whatever they like (here: contributing to fremantle porting), since you want to keep them in CSSU maintenance, ignoring the fact that fremantle porting actually is CSSU maintenance as well.
/j

Devil's advocate here (literally), but:

Nokia casing with NOKIA logo - can be filed down, but the next one,

Using N900 (Nokia patented design) while promising to deliver a full device - can be avoided by only shipping boards and private channel information on casing shipping/montage, but this will kill a lot of the appeal.

Marketing using Fremantle (tm) as part of product information (pulling as hard as I can from my ***, but they can better) - easy, just move to the Freemantle untrademarked term to what this will be flashable with.


I did suggest a separate thread for legal discussion, might be worthwhile to move this there and ask any legalese speaking friends if they see any problems (or can come up with some, just in case). There could be further problems if booting even debian will need Nokia's driver blobs or similar

fremantle afaik is not (C) or [TM]
Claiming that a device is XY[tm]-compatible is not violating any rule I know of.
The logos etc on casing, yep, we will remove them.

We don't need ANY closed driver blobs! For sure not to boot debian. Not even to boot fremantle. I'm not going to employ or involve any lawyers in that stage of the project - had my share of experience with anything where lawyers got involved (HiFo anybody?)
All the points listed are no argument against FPTF, they are clearly related to Neo900 and GolDeliCo. The FPTF is NOT DOING ANYTHING SUSPICIOUS.
Ivgalvez is threatening everybody contributing to FPTF with "problems of C&D and prosecution". I think that's mainly FUD and I guarantee that helping with development of compatibility layers, FOSS replacements, even analysis of API/ABI and function of closed blobs, porting fremantle (FOSS!) kernel to a new hw platform - is all perfectly legal and none of all that will cause any negative effects for any of you.

I nevertheless am all positive for moving this sub-topic incl all related posts to a new thread, since this thread is about technical aspects and clearly marked "developers only"

thanks,
jOERG

PS: we're talking about 200 units here - if we're lucky to get there. I can't see any company on this planet considering to give their lawyers a call to even figure if they could do anything about this. It doesn't pay off for them. Odds are we cease and desist long before their lawyers are ready with drafting the letter.

I think ivgalvez means that people working on porting some Maemo bits (dialer) to Neo900 could get in troubles with nokiasoft. A C&D type of troubles. Of course, probability is low, but it would be silly to be forced going "underground" with compatibility layers and stuff, release under anonymous nicks, etc.

Now, for all intents and purposes, such C&D would be meritless, but still, could scary some not-so-tought skinned devs - people just don't like to mess with lawyers of big corporations, even if claims of those corporations are absurdish. See, for example, microsh|t letters to C&D of inccluding support for handling filetype EXTENSION (.ASF) in VirtualDub. They were senseless, yet, VirtualDub dropped support for .ASF (with unofficial version with re-introduced support floating on piratebay).

Now, as I see ivgalvez's point, he mean that instead of porting existing thing, task force should focus on implementing FOSS replacements for all of them, uable on both Neo900 and N900.
---

Thats about it for cronically interpreting his words. Now, I think that while there *is* risk of C&D (if Neo900 het more widely known/manage to create some fuzz around itself, even despite low production numbers), but task of replacing all fremantle components would just take too much time, putting whole project into limbo (due to unusable features, we would get less interested people, due to less interested people, we would have less developers to work on those features - circle complete).

IMO, first we should get fremantle working 100% as planned already, *then* introduce more FOSS replacements, that were not available to date. I agree that CSSU was quite unfriendly for FOSS replacements for some time, but lately - with introducing of clock replacement into testing - situation seems to have changed.

After all, CSSU is open, and with more people interested in working on it (Neo900 may spawn some interest), no one will stop anyone from putting more foss replacements there, or even create a bleeding-edge fork, focused on getting rid of closed bits, no matter if current CSSU maintainers like it or not (BTW, considering everything that is happening, I'm rather sure that they *would* like it, rather than not).
---

Summing it up - while I love idea of FREEmantle dearly, let's not pull too many strings at once. We got only so much hands on board - solving one problem at time works best.

/Estel

I don't know of any such project of "porting dialer". The idea is 180° the opposite,
we're NOT "porting" any Nokia bits, we create a system environment where "non-ported" original Nokia bits as well as all other apps from extras* will happily run. User will install those "non-ported" original Nokia bits like dialer to her system,
the FPTF is not involved in that. Not at all. So where's the problem?
If we were planning to "port" anything from fremantle closed bits or extras repos to Neo900, we could happily discard our idea of keeping binary compatibility and just as well go straight for OMAP4 and 3.11 mainline kernel with FSO as middleware and forget about any closed blobs, and in the end why not forget about maemo at large and recompile everything in extras for debian or even - hey - for harmattan and cordia.
But we decided not to do that, and rather write FOSS replacements or compatibility layers around new incompatible kernel properties to ensure the above mentioned absolute binary compatibility. And of course many of those FOSS replacements will be usable on N900 as well, thanks to that binary compatibility. See my suggestion to develop and test fsogsmd modem "driver" (replacement for csd nokia blob) on N900 with a USB UMTS stick. Thus maintenance and development for N900 will see a boost rather than a fading-away thanks to Neo900 and FPTF project.

[offtopic] I won't even try to start on explaining what's incorrect statements and missconceptions about CSSU in the above posts. There are better places to discuss this, and actually it's been discussed and explained ad nauseum, and no repeating of incorrect assertions will make them any correct. Just so much: each user and each devel has freedom of choice, and that ends only where it limits somebody else's freedom of choice. Devels have freedom to choose between proper packaging (that allows users to have their freedom to choose whether or not to use that package) and botchy lazy packaging. Lazy packaging will not be supported by CSSU.[/offtopic]

And now could we please "clear the channel" for the technical discussion how to implement that binary-compatible fremantle on Neo900? Thanks a lot!
I'd really like to see these "legal" concerns getting discussed somewhere else, not here. It distracts devels from what they prefer to do: find technical solutions for technical problems.
/j

NOTE: I replied to szopin before reading the subsequent posts, particularly Jörg's reminder to stay on-topic. Sorry about that.

We have bought our N900s, so the hardware is ours. Meaning I can mod it like I want, including replacing the board.

I can always (if I had the time anyway build a board that could run Windows, or OS/2 for all I care. That wouldn't cause any problem with Microsoft or with IBM. I'm just building compatible hardware. The user has the freedom to install whatever OS he likes.

Just to clarify it without reference to Maemo/N900:
You could now buy a OS-less PC, replace the motherboard (or any other component), and then install (your copy of) Windows on it. Neither the PC manufacturer, seller, nor OS-vendor would have an issue with it -- except perhaps the warranty, but that's another (largely irrelevant in our case) matter.