Re: Input Method Development
(keeping [EMAIL PROTECTED] and communitylist in the loop) Hehe, This is totally understandable. :) We will explain to you the best as we can. If you want to make a korean keyboard with a key for each letter then you'll need a keyboard with... (sit down before next line) ... 11,172 letters, ie from \uAC00 to \uD7A3 + 24 single letters or jamos ! see here: http://en.wikipedia.org/wiki/Hangul http://en.wikipedia.org/wiki/Hangul#Syllabic_blocks Of course there is a special method. The korean keyboard layout is a single qwerty, each key with a jamo (single letters). The 11172 syllabes are made of combined jamos , and a state machine can be used to track which keys have been pressed, and how they have to be combined. See my previous messages for an explanation. However when I searched the Internet for my use, I did not find a lot of information on this, so I did the research. About you soft keyboard, I think the problem can be solved with the use of plugins, ie a method that takes keystrokes and outputs characters. For European scripts, the routine will be quite trivial, but for other scripts, this is needed. With such plugins, we can also imagine support for other complex scripts such as chinese or indian or whatever. An input method will then be made of an XML file describing the layout, and a .so to hold the key-character translation algorithm. Sebastien 2008/2/7, Jeremiah Flerchinger [EMAIL PROTECTED]: Please forgive me for not putting much thought into the problem before. I'm really only familiar with European languages none of this work is in my area of expertise. I have started some reading on IME and other input methods. I'll have to think about the issue and what extensions would eventually need to be made. Jeremiah Flerchinger wrote: The idea behind what I started is that you can make a soft keyboard with any number of rows keys. Each key could be assigned any arbitrary utf-8 value. If more symbols are needed a file can be created describing another keyboard layout with additional keys. Maybe it's impractical to have a key for each character place them all into different keyboard layouts. Any insight to the problem and how keyboards are typically used/configured in Korea would be appreciated. Even though I would be unable to do localization, I could try to rethink the current design to further meet international needs. Sébastien Lorquet wrote: Hi, nicely done, this program is complementary with what I did! But a Korean IME engine will require additions to your program, it's not only a matter of xml layout. Maybe a plugin system that receives key presses and emits characters. Basically it's a state machine that will read latin letters and output korean letters according to combinations. I have a small keypress stack and a ~60KB next states file. for example, you type b a and you get a ba syllabe as a single Unicode character. Not to mention we will need to add a korean font in the neo. I'm happy with this project. I'm OK to help, if needed. Sebastien -- Sébastien LORQUET - 이세영 (李世榮) Ingénieur ENSPG 2006 / ENSIMAG-ASI 2007 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Input Method Development
Sorry for the imprecision, and thanks for the correction. I spoke too fast. The backtracking should be trivial to implement with my prototype. I'm cleaning it a little before giving it to you. I'm also concerned with copyright. Is there any patent problem with this input method as with T9 (for mobiles) ? What I made is reverse engineering. I plan to release it under GPLv3 to be protected from software patents, will this be useful? What do you think? Sebastien. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Input Method Development
Am Do 7. Februar 2008 schrieb dda: I agree that a system of plugins/callbacks could do fine, if it can handle resetting output: eg typing gks bkspc f would output successively: ㅎ - 하 - 한 - 하 - 할 [Unicode 0x1112, 0xd558, 0xd55c, 0xd558, 0xd560]. Being able to backtrack is quite necessary in this case. The exact behaviour of BS, DEL, and cursor keys is yet to be defined to make this a complete spec. What happens when i press BS e.g. 8 times? What, when i press LEFT DEL END BS? Obviously BS should edit last sylable, but can you edit completed sylables (needs back-translation unicode-keystrokes!), and how does cursor movement affect closing sylables? just my 2 cents j ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Input Method Development
for what I recall, backspace starts by removing *letters* from the last syllable, then entire syllabes. Moreover, hitting a directional key like LEFT RIGHT or any key that changes the caret position terminates composition of the current syllabe. In fact, when you type, the currently composed syllabe appears in blinking inverted video, and a SPACE or the end of possible composition (ie, no more letters can be combined into a valid syllabe) terminates the sequence. At this point, the real syllabe is displayed normally as a unicode character and composition starts again. I noticed that in some editors where this blinking character cannot appear (e.g. in a cmd.exe console), the current combination is displayed in the corner of the current window in a small frame. Writing a complete spec is a good idea ;) seb ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WiP: dfu-util for Windows
When you port Dfu-util to windows keep all the switches the same(not that i thought you would change them) and I can write the UI this weekend, It will call on dfu-util, so any changes to dfu can be easily applied to the UI without the need to recode anything, let me know the name of your project and ill join (krisabsinthe/chris earl) if you want me to do the UI. Joachim Steiger [EMAIL PROTECTED] 02/07/08 7:41 AM The Shonko Kid wrote: --- Torsten Schlabach [EMAIL PROTECTED] wrote: Besides that, couldn't you upload your Win32 binary (.exe) as well? Sure I can, I'm not entirely sure where to put it though... I think that would make a nice interim solution until we collectively figured out how to make the build work. That was my intention when I got it working, but it wasn't immediately obvious where I should upload it to :-) just put it on projects.openmoko.org kind regards -- Joachim Steiger developer relations/support ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Sean Moss-Pultz wrote: What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. Are there any existing options available to us now? Does anyone know of existing companies or organizations with a similar strategy that we can seek guidance or partnership. http://www.patent-commons.org/ is the one that I'm aware of ... -- Rod ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
On Feb 7, 2008 1:00 PM, Sean Moss-Pultz [EMAIL PROTECTED] wrote: What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. This sounds like a great idea. I think what you mean is that if a competitor sues OpenMoko for allegedly infringing its patent, then OpenMoko can counter-sue saying BTW you are infringing this one of ours too and then it gets settled out-of-court by cross-licensing, right? But I can't think of a way to legally bind the patent to be used for defensive purposes only. Whatever method you come up with would have to work in multiple countries, right? One technique I know of for the US is the provisional patent. My understanding is that you pay a small fee to file a sort of pre-patent which will be accepted immediately without review. Then you have one year in which to finish the real patent application, but the date will be set to that of the earlier provisional patent; so the intent is that if the competition is in hot pursuit, you can make sure your patent date is earlier than theirs, even if the patent application is not yet finished. But, if you fail to complete the full patent application within one year, the ideas contained in the provisional patent become unpatentable! because the USPTO (supposedly, if they aren't too lazy) always review prior patents before granting a new one... and that includes provisional patents. So ever since I heard of it, this has always seemed to me a good low-budget way (within reach of individual free software developers, even) to protect an idea from being patented by someone else later on. But I haven't personally tried to do that (although one company where I worked did) and I would sure like to see an opinion of an actual IP lawyer on how strong the protection is when you do that. It's basically just a form of prior art which is highly accessible to the USPTO, and less likely to be ignored than just publishing the prior art somehow. (Then you'd typically have to go to court to show the prior art and get the new patent overturned, right? Whereas with a provisional patent you have the chance to prevent competing patents from being granted.) If that technique does not protect us enough, then maybe real patents are better. But what is to stop OpenMoko, or some future company that buys OM, or some company to which the patents are cross-licensed, from using them in non-defensive ways? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
what about posting this exact question at groklaw? On Feb 7, 2008, at 1:00 PM, Sean Moss-Pultz wrote: Dear Community, Most of you know that OpenMoko is a fully independent company at this point. With this great opportunity comes many challenges. Today I would like to share one with you all and ask for some advice. We need to file patents for our hardware as well as software designs. While my personal views on software patents are inline with people like Eben Moglen, as a company, we are forced to play by the rules of the game. What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. Are there any existing options available to us now? Does anyone know of existing companies or organizations with a similar strategy that we can seek guidance or partnership. Again, I want to emphasize that we only want our patents to be used in defense. And what constitutes defense is something that we want to be able to define (and potentially even redefine when new threats arise). Thanks in advance for the help. Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Patents and OpenMoko
Dear Community, Most of you know that OpenMoko is a fully independent company at this point. With this great opportunity comes many challenges. Today I would like to share one with you all and ask for some advice. We need to file patents for our hardware as well as software designs. While my personal views on software patents are inline with people like Eben Moglen, as a company, we are forced to play by the rules of the game. What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. Are there any existing options available to us now? Does anyone know of existing companies or organizations with a similar strategy that we can seek guidance or partnership. Again, I want to emphasize that we only want our patents to be used in defense. And what constitutes defense is something that we want to be able to define (and potentially even redefine when new threats arise). Thanks in advance for the help. Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Patents and OpenMoko
I'd get in touch with the Linux Foundation/Software Freedom Law Center and discuss their patent commons with them. Write me off-list, Sean, and I can get you in touch with the right folks, I think... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Moss-Pultz Sent: Thursday, February 07, 2008 12:00 PM To: List for OpenMoko community discussion Subject: Patents and OpenMoko Dear Community, Most of you know that OpenMoko is a fully independent company at this point. With this great opportunity comes many challenges. Today I would like to share one with you all and ask for some advice. We need to file patents for our hardware as well as software designs. While my personal views on software patents are inline with people like Eben Moglen, as a company, we are forced to play by the rules of the game. What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. Are there any existing options available to us now? Does anyone know of existing companies or organizations with a similar strategy that we can seek guidance or partnership. Again, I want to emphasize that we only want our patents to be used in defense. And what constitutes defense is something that we want to be able to define (and potentially even redefine when new threats arise). Thanks in advance for the help. Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Patents and OpenMoko
http://www.patent-commons.org/ is the one that I'm aware of ... This is what I was referring to... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
This sounds like a great idea. I think what you mean is that if a competitor sues OpenMoko for allegedly infringing its patent, then OpenMoko can counter-sue saying BTW you are infringing this one of ours too and then it gets settled out-of-court by cross-licensing, right? Well I am not too sure about that... I would guess and prefer that the patent is used to ensure that no one else patents this and sues fic/openmoko. Otherwise it would not be a really free thing.. Am I right? So what is this defence tactic now Sean? Or do you have to figure out that as well? Hope you find a solution which is good in the FOSS sense like you often do! Just to say it ones more: you do a great job at FIC/OM! -- Mit freundlichen Grüssen / Best Regards Esra Kummer Address: Schaffhauserstrasse 133, 8400 Winterthur, Switzerland Fon: 0041 78 756 69 74 2nd Mail: [EMAIL PROTECTED] Skype: tuxfux.ch, MSN: [EMAIL PROTECTED], ICQ: 262647196 Fotos: www.flickr.com/photos/tuxfuxch Orkut: Esra Kummer ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
I think that we all agree here that the patent system is completely broken. By filling patent, even for defense only, you are playing the rule. What I've seen so far is that small companies that cannot afford a lawyer department simply choose to ignore the rules and just ignore completely the patent system. In the essence of the law, as long as you don't obviously *stole* an idea, you 've nothing to fear. But the system has becomed crazy when you can infringe a patent without even knowing it. That's completly wrong with the moral behing patent itself ! Have you already tried to fill a patent ? Have you tried to make a study on prior art ? I did for a few weeks and I didn't succeed. All is patented ! All, completely ! Patents are as general as possible and cover everything you could believe. It's nearly patents for things that do stuffs. So whatever you do, you could be sued. I don't know the ressources of OpenMoko but patenting, writing and submitting is a full-time job ! It would be shame (IMHO) to waste ressources in this way. More : you have to fill the patents in different countries !!! As OpenMoko does Free software, doing this, even for defensive purpose, will have a terrible PR impact in the Free Softwware community. You have the opportunity to just move, to ignore those silly things and to build something new. On the other hand, if you are under a patent attack without any patents, I think that the Free Software Fundation gives legal help in that kind of case. I really hope that OpenMoko will not be covered by any patents. (but I'm sure that there's a patent for a device allowing wireless communication somewhere) On Feb 7, 2008 9:43 PM, David Schlesinger [EMAIL PROTECTED] wrote: http://www.patent-commons.org/ is the one that I'm aware of ... This is what I was referring to... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
On Feb 7, 2008 3:35 PM, Steven Milburn [EMAIL PROTECTED] wrote: As a first step, get anything you think is patent worthy documented and dated. In the US, a common practice is to write up your concept and mail it to yourself in a sealed envelope. You don't open the envelope until you Or get the document itself notarized. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Forgot to add this link. This will outline the American procedure for patenting. http://www.inventionpatent.net/patent/process.cfm Steven Milburn [EMAIL PROTECTED] 02/07/08 5:35 PM As a first step, get anything you think is patent worthy documented and dated. In the US, a common practice is to write up your concept and mail it to yourself in a sealed envelope. You don't open the envelope until you need to and you do it with a lawyer present. The postmark on the envelope holds up very strongly to prove the date of the material. --Steve ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
proprietary firmware
Dear Community, Some of our chips or chipsets contain proprietary firmware in flash memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM chipsets. Ideally, we would have liked to use chipsets for which even the firmware code would be free, but they don't exist right now. So we accepted proprietary firmware, as long as it was in flash or ROM. Then we ran into problems when bugs were found in the firmware, and we wanted to update handsets out in the field. The vendors would give us firmware updates and reflashing tools, but they wouldn't let us redistribute those tools to our users. We asked for special licenses to allow us to distribute those flashing tools to our users, and got them in some cases, after months of licensing negotiations. Next we discovered that those reflashing tools had further issues: for example, they would only allow loading cryptographically signed firmware into the chipset flash memory. The tools do this because vendors are worried that people would disassemble, patch, and reassemble the firmware, triggering regulatory reclassification of their chipsets (software controlled radio). Furthermore, we see that for upcoming chipsets, vendors are switching from storing the firmware in flash memory to loading the firmware into RAM at run time. One reason for this is that RAM needs less power and is cheaper. In this case the firmware, whether original or updated, has to be loaded each time the device boots, requiring that the binary- only, restrictively licensed firmware updater be included in the OpenMoko distribution. This got quite frustrating, until we met Richard Stallman last weekend. And he cleared it up for us rather quickly :-) He suggested we treat any chipset with proprietary firmware as a black- box, a circuit. He suggested we ignore the firmware inside. If the firmware is buggy and the vendor needs the ability to update the firmware, we instead ask the vendor to reduce the firmware to the bare minimum, so that it can be very simple and bug free, and move the rest of the logic into the GPL'ed driver running on the main CPU. This way we completely avoid the issue of distributing proprietary firmware updates and binary firmware updaters with restrictive licensing that load only cryptographically signed firmware. We liked his advice. It speeds up our decision making and allows us to focus on what we do best: Developing Free Software that is available in full source code, running on the main CPU, that we and anyone else can modify and optimize. There are downsides: We will no longer offer reflashing tools to update proprietary firmware, under any license. For critical firmware bugs, we will accept returns, or in some cases fix the bug in-house. We will push vendors to simplify the functionality of their proprietary firmware, so we can implement more of this on the main CPU as Free Software. Maybe some vendors will even open up firmware for Free Software development, that would be the ideal outcome we are working towards. We hope this helps clarify OpenMoko's current position on proprietary firmware: Ignore them while they stay inside of a chip or chipset, and refuse to touch them. Focus on what Free Software can do. Feedback and comments are always very welcome. Best Regards, Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I dont know why I was surprised
captive stylus..anyone? :) the new N810 stylus looks like it might almost fit! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
On Thu, 2008-02-07 at 17:35 -0500, Steven Milburn wrote: As a first step, get anything you think is patent worthy documented and dated. In the US, a common practice is to write up your concept and mail it to yourself in a sealed envelope. You don't open the envelope until you need to and you do it with a lawyer present. The postmark on the envelope holds up very strongly to prove the date of the material. What prevents you from mailing yourself an unsealed envelope? -Arthur ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
On Feb 7, 2008 4:45 PM, Arthur Britto [EMAIL PROTECTED] wrote: What prevents you from mailing yourself an unsealed envelope? Why would you want to do that? The point is to get a reliable date stamp associated with the material inside the envelope. And as the other link pointed out, it doesn't hold up well in court, and could also be used against you to say that this idea was not being implemented... was just sitting on a shelf until you got around to filing the patent or defending against one. I think the notary method would be better because the stamp is right on the invention diagram/description; and not being sealed, they can't say it was necessarily sitting on a shelf. Some companies take lab notebooks seriously for the same reason - if you have a practice of dating and signing every page, and the book is a hardcover bound one, and it stands up to reasonable scrutiny that the notebook could not have been constructed and bound later on, then maybe some courts would be convinced that the idea struck you on that date... because it fits into the timeline of the other writings in that book, some of which could probably be corroborated via other sources. (Since I don't like the process of writing on paper though, that's one habit I haven't taken up very much.) More about the notary method here http://robertplattbell.blogspot.com/2007/10/poor-mans-patent.html and here http://books.google.com/books?id=7G5A2pyvCQUCpg=PA137lpg=PA137dq=notary+establish+date+of+inventionsource=webots=dEnJJyMR-msig=piJSbDkPsCkKJOmMd_XtzcwISmQ but I'm not proposing it's anywhere near as good protection as an actual patent... just for a prior art defense. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
+1 Software by its nature is easier to fix than hardware or even firmware; this approach does the Right Thing: vendors win because the firmware layer just got a whole lot easier to write and the rest of the world wins because we get as much control as legally permissible of our hardware. On Friday, Feb 8, 2008, Wolfgang Spraul writes: Dear Community, Some of our chips or chipsets contain proprietary firmware in flash memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM chipsets. Ideally, we would have liked to use chipsets for which even the firmware code would be free, but they don't exist right now. So we accepted proprietary firmware, as long as it was in flash or ROM. Then we ran into problems when bugs were found in the firmware, and we wanted to update handsets out in the field. The vendors would give us firmware updates and reflashing tools, but they wouldn't let us redistribute those tools to our users. We asked for special licenses to allow us to distribute those flashing tools to our users, and got them in some cases, after months of licensing negotiations. Next we discovered that those reflashing tools had further issues: for example, they would only allow loading cryptographically signed firmware into the chipset flash memory. The tools do this because vendors are worried that people would disassemble, patch, and reassemble the firmware, triggering regulatory reclassification of their chipsets (software controlled radio). Furthermore, we see that for upcoming chipsets, vendors are switching from storing the firmware in flash memory to loading the firmware into RAM at run time. One reason for this is that RAM needs less power and is cheaper. In this case the firmware, whether original or updated, has to be loaded each time the device boots, requiring that the binary- only, restrictively licensed firmware updater be included in the OpenMoko distribution. This got quite frustrating, until we met Richard Stallman last weekend. And he cleared it up for us rather quickly :-) He suggested we treat any chipset with proprietary firmware as a black- box, a circuit. He suggested we ignore the firmware inside. If the firmware is buggy and the vendor needs the ability to update the firmware, we instead ask the vendor to reduce the firmware to the bare minimum, so that it can be very simple and bug free, and move the rest of the logic into the GPL'ed driver running on the main CPU. This way we completely avoid the issue of distributing proprietary firmware updates and binary firmware updaters with restrictive licensing that load only cryptographically signed firmware. We liked his advice. It speeds up our decision making and allows us to focus on what we do best: Developing Free Software that is available in full source code, running on the main CPU, that we and anyone else can modify and optimize. There are downsides: We will no longer offer reflashing tools to update proprietary firmware, under any license. For critical firmware bugs, we will accept returns, or in some cases fix the bug in-house. We will push vendors to simplify the functionality of their proprietary firmware, so we can implement more of this on the main CPU as Free Software. Maybe some vendors will even open up firmware for Free Software development, that would be the ideal outcome we are working towards. We hope this helps clarify OpenMoko's current position on proprietary firmware: Ignore them while they stay inside of a chip or chipset, and refuse to touch them. Focus on what Free Software can do. Feedback and comments are always very welcome. Best Regards, Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: proprietary firmware
+1 Good and smart decision from my point of view. On Feb 8, 2008 11:58 AM, Paul Jimenez [EMAIL PROTECTED] wrote: +1 Software by its nature is easier to fix than hardware or even firmware; this approach does the Right Thing: vendors win because the firmware layer just got a whole lot easier to write and the rest of the world wins because we get as much control as legally permissible of our hardware. On Friday, Feb 8, 2008, Wolfgang Spraul writes: Dear Community, Some of our chips or chipsets contain proprietary firmware in flash memory. For example, in GTA02 these include the Wi-Fi, GPS, and GSM chipsets. Ideally, we would have liked to use chipsets for which even the firmware code would be free, but they don't exist right now. So we accepted proprietary firmware, as long as it was in flash or ROM. Then we ran into problems when bugs were found in the firmware, and we wanted to update handsets out in the field. The vendors would give us firmware updates and reflashing tools, but they wouldn't let us redistribute those tools to our users. We asked for special licenses to allow us to distribute those flashing tools to our users, and got them in some cases, after months of licensing negotiations. Next we discovered that those reflashing tools had further issues: for example, they would only allow loading cryptographically signed firmware into the chipset flash memory. The tools do this because vendors are worried that people would disassemble, patch, and reassemble the firmware, triggering regulatory reclassification of their chipsets (software controlled radio). Furthermore, we see that for upcoming chipsets, vendors are switching from storing the firmware in flash memory to loading the firmware into RAM at run time. One reason for this is that RAM needs less power and is cheaper. In this case the firmware, whether original or updated, has to be loaded each time the device boots, requiring that the binary- only, restrictively licensed firmware updater be included in the OpenMoko distribution. This got quite frustrating, until we met Richard Stallman last weekend. And he cleared it up for us rather quickly :-) He suggested we treat any chipset with proprietary firmware as a black- box, a circuit. He suggested we ignore the firmware inside. If the firmware is buggy and the vendor needs the ability to update the firmware, we instead ask the vendor to reduce the firmware to the bare minimum, so that it can be very simple and bug free, and move the rest of the logic into the GPL'ed driver running on the main CPU. This way we completely avoid the issue of distributing proprietary firmware updates and binary firmware updaters with restrictive licensing that load only cryptographically signed firmware. We liked his advice. It speeds up our decision making and allows us to focus on what we do best: Developing Free Software that is available in full source code, running on the main CPU, that we and anyone else can modify and optimize. There are downsides: We will no longer offer reflashing tools to update proprietary firmware, under any license. For critical firmware bugs, we will accept returns, or in some cases fix the bug in-house. We will push vendors to simplify the functionality of their proprietary firmware, so we can implement more of this on the main CPU as Free Software. Maybe some vendors will even open up firmware for Free Software development, that would be the ideal outcome we are working towards. We hope this helps clarify OpenMoko's current position on proprietary firmware: Ignore them while they stay inside of a chip or chipset, and refuse to touch them. Focus on what Free Software can do. Feedback and comments are always very welcome. Best Regards, Wolfgang ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Patents and OpenMoko
Sean Moss-Pultz wrote: What I want is for a our company's patents to be freely available, for anyone, but for defensive purposes only. Aside from patent-commons, which is just a way to allow mutual defense for fellow FOSS projects (assuming I understood this correctly), what I know of is to give irrevocable, transferable non-exclusive license to anyone to use your patents for any software released under the GPL. Such a license is GPLv3 compatible, is proof against acquisition, but does not diminish the defensive aspect of the patent. Bear in mind - I am not a lawyer. Shachar ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
now Koolu makes a phone too ;-)
http://koolu.com/Koolu-WE-Appliance/WE-Phone.html looks kinda familiar ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OpenMoko Wireless Chip
Hello OpenMoko has a wlan chip? Joiku brings in a hostpot: http://www.computerwelt.at/detailArticle.asp?a=114126n=1 http://www.joiku.com/?action=productsmode=productDetailsproduct_id=310 A better idea is to bring in BATMAN protocol for meshed wireless... https://www.open-mesh.net/batman So if a wireless chip is in Openmoko, please add the batman protocol? Thanks ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: how to enable usb host mode?
Can any one suggest me how to use usb host mode with GTA01. On Feb 6, 2008 11:38 AM, Phani Kumar Kancharala [EMAIL PROTECTED] wrote: yes, my plan is to work with a self powered USB hub. Is it possible to work with 2.6.22 kernel?? On Feb 5, 2008 10:26 PM, Christopher Earl [EMAIL PROTECTED] wrote: Add a powered Hub, and there you go, also somewhere on the Wiki is how to Mod the GTA01 to add Bus power Mikko J Rauhala [EMAIL PROTECTED] 02/05/08 11:21 AM On ti, 2008-02-05 at 16:01 +, JW wrote: if you are talking about GTA01 then there is no host mode (I believe). Bzzt, there is, though it is unpowered (and therefore nonstandard as-is), requiring power to be fed from the side via eg. a three-pronged cable (or the device not to care about seeing power on the bus, which might be rare). -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: now Koolu makes a phone too ;-)
On Feb 8, 2008 6:29 AM, Doug Jones [EMAIL PROTECTED] wrote: http://koolu.com/Koolu-WE-Appliance/WE-Phone.html looks kinda familiar The specs look alike to the letter, you mean... Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: now Koolu makes a phone too ;-)
Yes, Koolu is a distributor. Michael Doug Jones wrote: http://koolu.com/Koolu-WE-Appliance/WE-Phone.html looks kinda familiar ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
another interview about OpenMoko
Our friend Steve Lake interviewed me the other day: http://www.raiden.net/?cat=2aid=374 I'm afraid he caught me just as my two mugs of morning espresso kicked in, and my sentences are a little long, for which I apologize. Hopefully you can read past that and sense my enthusiasm for this project. Regards, Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: now Koolu makes a phone too ;-)
Subject: Re: now Koolu makes a phone too ;-) Date: gio 07 feb 08 11:30:53 -0800 Quoting Michael Shiloh ([EMAIL PROTECTED]): Yes, Koolu is a distributor. mmm. They offer pre-order and quote a price of US$399. Available to developers this March. And the phone becomes a Works Everywhere (TM) Phone. No mention of Openmoko, FIC, Freerunner... Will you eventually favour distributors to direct sale (in terms of early production batches)? Carlo -- * Se la Strada e la sua Virtu' non fossero state messe da parte, * K * Carlo E. Prelz - [EMAIL PROTECTED] che bisogno ci sarebbe * di parlare tanto di amore e di rettitudine? (Chuang-Tzu) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
