Re: Corporate ownership of open source projects [LWN]
ext Marcin Juszkiewicz [EMAIL PROTECTED] writes: Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. Lauro Venancio wrote a patch to support wpa_supplicant: https://garage.maemo.org/pipermail/cx3110x-devel/2007-November/05.html -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Searching informations (was Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN]))
Thats a great site for searching the archives BTW, thanks! Allow me another plug for tabletSearch: http://www.google.com/coop/cse?cx=014783630360138230012%3A5hwd9yj0uno This is a Google Custom Search Engine (CSE) that I put up and maintain. It allows specific searches for Maemo/NIT-related information; I find it extremely handy whenever I look for anything in this domain. As an example of your needs, just search for dsme and look at the results :-) In addition, I also made a plugin for the Internet Search Applet on the Hildon Home screen. You can get it here: http://tomch.com/wp/?page_id=63 Best regards -Tom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Hello! On Wed, May 7, 2008 at 3:45 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: nick loeve wrote: Yep, I have been reading the archives and have compiled a shortlist of info based on past discussions (mainly that you have started! ). I guess I might start documenting what is known already and try and get it all in one place. Yes, please do if you can. https://maemo.org/community/wiki/poweranddevicemanagement/ At the moment it is just a link dump and i intend to summarize some of the info in that page. If you anyone has more useful links/info just dump them on the page or send them in this thread. Cheers I am guilty of not doing it myself over years. I'm sure people on this list can fill some gaps. Apart from examining dsme, its modules and dsmetest in initfs (and its runtime behaviour using strace), check also powerlaunch http://powerlaunch.garage.maemo.org/ It is replacement of mce (also closed). mce talks to dsme too and is done in similar modular way so it can help with some understanding. Powerlaunch imitates some mce-dsme communication, see dsme.c,h at https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/powered/?root=powerlaunch As for bme and figuring out how battery charging works, one could strace it and see what tahvo/retu register it uses, some bits are mentioned in kernel headers (not sure about name now, something like tahvo_retu_user.h) and there is also this info http://marc.info/?l=linux-omapm=120752529631862w=2 Frantisek -- Nick Loeve ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Tue, May 6, 2008 at 5:33 PM, Sarah Newman [EMAIL PROTECTED] wrote: Are you asking for more examples of non-kernel code that we can't modify? Unless I just haven't found them, there's also no way to build the dsp gstreamer plugins (lack of osso-dsp-headers-rx-44.) It is possible to build the gstreamer plugins with a homemade fake-osso-dsp-headers-rx-44 package (see http://www.linuxtogo.org/~ph5/n810/dsp/) based on the released older osso-dsp-headers-0.1 (http://repository.maemo.org/pool/maemo/ossw/source/o/osso-dsp-headers/). I have not tested if they actually work on the device. I filed a bug related to the behavior of these plugins, and I don't know enough to be certain the bug is inside the dsp plugins themselves, but it would be easier to poke around if they could be repackaged to run on a live system. Kees Jongenburger wrote: On Tue, May 6, 2008 at 5:36 AM, Igor Stoppa [EMAIL PROTECTED] wrote: Till here you are not really providing much of a proposal for getting things done, just generic complaints that historically are proven to not work. Hello Igor and others, From reading this thread I have the feeling we are pretty close to getting into a workable situation Most of the disc spawns around the kernel. it looks to me like all sides are ready to make some concessions if that means that we can have a self compiled kernel. One other threads proposed to put the different known kernel hacks and patches into a garage project and nokia seams ready to search for a pragmatic solution to what the looked like the biggest problem to methe binary wlan kernel module. is this only a feeling? greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers regards Philipp ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Corporate ownership of open source projects [LWN]
About silence, in fact a lot of it has not to do with confidentiality but lack of priority (or too many top priorities in the hands of us able to respond). Sounds promising :) What about a short term plan with common objectives: - Raise in a structured way the topics that matter to you where you feel there is a lack of response from Nokia. Now it is difficult to follow everything even to people like me spending a lot of time here, leave alone the average lead developer, project manager or product manager in the house. - Tag silences i.e. ToDo (answer will come when we have time), Planning (still undecided, working on it), Later or Depends on XXX (other events need to come first), Confidential (the stuf we really cannot talk about, probably less than you think). - Prioritize the items you want answered first. Proposal for actions: - Niels (web tools), Dave (web content) and Andre/Karsten (to be introduced officially as bugmasters) are your kind of representatives and they have lots of hours funded by Nokia to work for you. They are the ones prioritizing the tasks that are relevant to the community. Make sure they see how important is the thing you want to push. Avoid private communications unless your stuff is private: lobby here, in bugzilla, in planet maemo... - This prioritization should be visible somewhereand people should be able to impact it directly. Someone proposed to have some kind of ideastorm where the community could make visible the stuff that really matters. Voting bugs in bugzilla kind of does it but kind of not. Let's work on this, starting soon and simple - then improve. Give us the hottest topics in the main areas and let's concentrate on those. What's the easiest way for you chaps to look at the points we bring up? Wiki page? Or a similar process to the original roadmap items - we email the list succinctly with a question and the item information are placed on a locked wiki page for all to see? From my point of view, there are probably 3 lists that we as the community should be providing here. They may or may not be interlinked, but I think they could probably be handled separately if that would make life easier: 1. Items we'd like to know the status of (e.g. SBC DSP task, IVA, PowerVR) 2. Things we'd like to see open sourced and a reason why (e.g Hildon desktop, RSS reader, BME, DSME) 3. Other miscellaneous issues to be addressed (library versioning and request for specific libraries to be bumped, though this might make more sense for the bugtracker?) My interest is mainly in the first two, so I have probably neglected the last one. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
ext Dave Neary wrote: We could do this in a wiki page, or we could put creating a brainstorm-type site in the TODO list for May, and use that. We discussed this possibility at https://garage.maemo.org/pipermail/maemo2midgard-discussion/2008-April/000258.html In the short term, a mailing list thread here, which I could summarise into a wiki page, seems like a good way for us to get started. Indeed. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Hi Dave, Let's use this list as a template, then. Can people identify very specific things (and please, assume I don't know what the acronyms mean, and don't know the history behind the issues ;) and I'll get started on a wiki page? Okay, I'll get started then: 1. DSP SBC task - In the roadmap there used to be (what I interpreted as) mention of implementing a DSP task to handle encoding audio for A2DP use (where A2DP stands for Advanced Audio Distribution Protocol and is a Bluetooth protocol for sending data to Bluetooth stereo headsets [1]). SBC stands for subband codec, which is the default encoding method required by A2DP hardware. At the moment this encoding must be carried out by the ARM in software, but if the task could be offloaded to the DSP it would free up the ARM to do other things (such as decoding video better). This is really just a yes/no, are Nokia doing anything as if they are, I won't bother. 2. PowerVR MBX driver [2] and OpenGL implementation. We have PowerVR MBX chips sat in our N8x0 machines, doing, afaict, not a lot. It would be nice if it worked (think OpenGL loveliness in games, and I would hope some frivolous but eye catching snazzy desktop features - prettier UI = more publicity = more sales; perhaps...). There are Linux 2.6.x kernel drivers available, though not for the right kernel version and for the OMAP2430 rather than OMAP2420. It would be nice to know if Nokia are pursuing this, and if not, what the limitation is - if it's hardware could we know, as otherwise we might try fiddling with the existing driver and see if we get anywhere (though that will be a long road). 3. IVA - this is part of the OMAP2420 and stands for Imaging and Video Accelerator chip. Its abilities are described at the end of this document [3], in the specifications. It looks like it could do some useful acceleration. There is however no real information available (from Ti or elsewhere) about what it is, and how to program it, though there are some hints, e.g. [4]. The DSP gateway (which is the bridge software between the ARM and the DSP) has been expanded to allow it to interface with the IVA, but the patches say that there's no driver for the IVA itself [5]. Is this being pursued (as there's little we can do about it as we have no information) and if not, why not? 4. AGPS - Assisted GPS [6]. We have an AGPS chip in the N8x0, it doesn't use the assistance feature. Is this being worked on? This is something we as the community could do some work on, if we had some sort of API to allow us to inject the updated almanac/ephemeris data (leave how to work these out as part of the challenge ;)). Obviously if Nokia come out with an all encompassing system (e.g. giving us a way of talking to supl.nokia.com to provide us with the almanac/ephemeris data that I presume it provides for mobile phones), then that would be good (though probably less fun for hacking purposes ;)) And last but not least, all my questions should be read with pretty please added to them rather than as demands, and thanks (to Dave and Nokia) for taking this on. Cheers, Simon [1] http://en.wikipedia.org/wiki/A2DP#Advanced_Audio_Distribution_Profile_.28A2D P.29 [2] http://www.imgtec.com/factsheets/powervr/POWERVR_MBX_IP_Core_Family_%5B1.0%5 D.pdf [3] http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf [4] http://osdir.com/ml/linux.ports.arm.omap/2006-08/msg00177.html [5] http://osdir.com/ml/ports.arm.omap/2006-09/msg00067.html [6] http://en.wikipedia.org/wiki/AGPS ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
On May 7, 2008, at 14:18, Simon Pickering wrote: 1. DSP SBC task - In the roadmap there used to be (what I interpreted as) mention of implementing a DSP task to handle encoding audio for A2DP use (where A2DP stands for Advanced Audio Distribution Protocol and is a Bluetooth protocol for sending data to Bluetooth stereo headsets [1]). SBC stands for subband codec, which is the default encoding method required by A2DP hardware. At the moment this encoding must be carried out by the ARM in software, but if the task could be offloaded to the DSP it would free up the ARM to do other things (such as decoding video better). This is really just a yes/no, are Nokia doing anything as if they are, I won't bother. AFAIK no. However, you might want to take a look at the recent optimizations that have been made to the SBC codec that comes as part of BlueZ. Several of the optimizations specifically target arm so the value of pushing the encoding to the DSP side is less than it was e.g. one year ago (however it might still have enough value for being worth doing if you have the time and interest). Johan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Hi! On Wed, May 7, 2008 at 1:18 PM, Simon Pickering [EMAIL PROTECTED] wrote: Hi Dave, Let's use this list as a template, then. Can people identify very specific things (and please, assume I don't know what the acronyms mean, and don't know the history behind the issues ;) and I'll get started on a wiki page? Okay, I'll get started then: Here is my list (which only outlines subjects not touched below): 1. Binary only wifi modules Is there any work being done to make this open completely (definitively)? Or is it possible for Nokia to supply it in object form or at least updated as the kernel API changes over time? 2. Is it possible to at least get some basic documentation of what bme and dsme are doing (beyond obvious basics)? That way if the code from Nokia cannot be opened we have a starting point for an alternative implementation. 3. (my own personal interest) is it possible to document the serial pins for the n8x0 devices? Thats if they differ from the 770 which is documented (kind of, its hidden on a wiki page somewhere). Thats my questions... Im looking forward to the irc meeting and also talking to Nokia/maemo people at linuxtag. By the way, thank you Nokians for being as open as you have and creating a great device. I really see that there is room for compromise from both sides in the recent discussions. Cheers 1. DSP SBC task - In the roadmap there used to be (what I interpreted as) mention of implementing a DSP task to handle encoding audio for A2DP use (where A2DP stands for Advanced Audio Distribution Protocol and is a Bluetooth protocol for sending data to Bluetooth stereo headsets [1]). SBC stands for subband codec, which is the default encoding method required by A2DP hardware. At the moment this encoding must be carried out by the ARM in software, but if the task could be offloaded to the DSP it would free up the ARM to do other things (such as decoding video better). This is really just a yes/no, are Nokia doing anything as if they are, I won't bother. 2. PowerVR MBX driver [2] and OpenGL implementation. We have PowerVR MBX chips sat in our N8x0 machines, doing, afaict, not a lot. It would be nice if it worked (think OpenGL loveliness in games, and I would hope some frivolous but eye catching snazzy desktop features - prettier UI = more publicity = more sales; perhaps...). There are Linux 2.6.x kernel drivers available, though not for the right kernel version and for the OMAP2430 rather than OMAP2420. It would be nice to know if Nokia are pursuing this, and if not, what the limitation is - if it's hardware could we know, as otherwise we might try fiddling with the existing driver and see if we get anywhere (though that will be a long road). 3. IVA - this is part of the OMAP2420 and stands for Imaging and Video Accelerator chip. Its abilities are described at the end of this document [3], in the specifications. It looks like it could do some useful acceleration. There is however no real information available (from Ti or elsewhere) about what it is, and how to program it, though there are some hints, e.g. [4]. The DSP gateway (which is the bridge software between the ARM and the DSP) has been expanded to allow it to interface with the IVA, but the patches say that there's no driver for the IVA itself [5]. Is this being pursued (as there's little we can do about it as we have no information) and if not, why not? 4. AGPS - Assisted GPS [6]. We have an AGPS chip in the N8x0, it doesn't use the assistance feature. Is this being worked on? This is something we as the community could do some work on, if we had some sort of API to allow us to inject the updated almanac/ephemeris data (leave how to work these out as part of the challenge ;)). Obviously if Nokia come out with an all encompassing system (e.g. giving us a way of talking to supl.nokia.com to provide us with the almanac/ephemeris data that I presume it provides for mobile phones), then that would be good (though probably less fun for hacking purposes ;)) And last but not least, all my questions should be read with pretty please added to them rather than as demands, and thanks (to Dave and Nokia) for taking this on. Cheers, Simon [1] http://en.wikipedia.org/wiki/A2DP#Advanced_Audio_Distribution_Profile_.28A2D P.29 [2] http://www.imgtec.com/factsheets/powervr/POWERVR_MBX_IP_Core_Family_%5B1.0%5 D.pdf [3] http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf [4] http://osdir.com/ml/linux.ports.arm.omap/2006-08/msg00177.html [5] http://osdir.com/ml/ports.arm.omap/2006-09/msg00067.html [6] http://en.wikipedia.org/wiki/AGPS ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Nick Loeve ___ maemo-developers mailing list maemo-developers@maemo.org
Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Hello, On Wed, 2008-05-07 at 12:18 +0100, ext Simon Pickering wrote: ... 4. AGPS - Assisted GPS [6]. We have an AGPS chip in the N8x0, it doesn't use the assistance feature. Is this being worked on? This is something we as the community could do some work on, if we had some sort of API to allow us to inject the updated almanac/ephemeris data (leave how to work these out as part of the challenge ;)). Obviously if Nokia come out with an all encompassing system (e.g. giving us a way of talking to supl.nokia.com to provide us with the almanac/ephemeris data that I presume it provides for mobile phones), then that would be good (though probably less fun for hacking purposes ;)) I saw some Nokia-internal A-GPS SW for N810. Can't say anything about the SW maturity, nor release dates, though. Somebody in Nokia seems to be working on it. BR, Kimmo And last but not least, all my questions should be read with pretty please added to them rather than as demands, and thanks (to Dave and Nokia) for taking this on. Cheers, Simon [1] http://en.wikipedia.org/wiki/A2DP#Advanced_Audio_Distribution_Profile_.28A2D P.29 [2] http://www.imgtec.com/factsheets/powervr/POWERVR_MBX_IP_Core_Family_%5B1.0%5 D.pdf [3] http://focus.ti.com/pdfs/wtbu/TI_omap2420.pdf [4] http://osdir.com/ml/linux.ports.arm.omap/2006-08/msg00177.html [5] http://osdir.com/ml/ports.arm.omap/2006-09/msg00067.html [6] http://en.wikipedia.org/wiki/AGPS ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Hi! On Wed, May 7, 2008 at 2:43 PM, Frantisek Dufka [EMAIL PROTECTED] wrote: nick loeve wrote: 2. Is it possible to at least get some basic documentation of what bme and dsme are doing (beyond obvious basics)? There is a lot of info. Search list archives for dsme (or bme) http://www.gossamer-threads.com/lists/maemo/ If you still have some specific question not answered, ask again, maybe someone knows, maybe not. I'm not sure what 'obvious basics' means to you. Yep, I have been reading the archives and have compiled a shortlist of info based on past discussions (mainly that you have started! ). I guess I might start documenting what is known already and try and get it all in one place. Thats a great site for searching the archives BTW, thanks! -- Nick Loeve ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
nick loeve wrote: Yep, I have been reading the archives and have compiled a shortlist of info based on past discussions (mainly that you have started! ). I guess I might start documenting what is known already and try and get it all in one place. Yes, please do if you can. I am guilty of not doing it myself over years. I'm sure people on this list can fill some gaps. Apart from examining dsme, its modules and dsmetest in initfs (and its runtime behaviour using strace), check also powerlaunch http://powerlaunch.garage.maemo.org/ It is replacement of mce (also closed). mce talks to dsme too and is done in similar modular way so it can help with some understanding. Powerlaunch imitates some mce-dsme communication, see dsme.c,h at https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/powered/?root=powerlaunch As for bme and figuring out how battery charging works, one could strace it and see what tahvo/retu register it uses, some bits are mentioned in kernel headers (not sure about name now, something like tahvo_retu_user.h) and there is also this info http://marc.info/?l=linux-omapm=120752529631862w=2 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: dsme, Re: Would like to know the status of (was RE: Corporate ownership of open source projects [LWN])
Frantisek Dufka [EMAIL PROTECTED] writes: As for bme and figuring out how battery charging works, one could strace it and see what tahvo/retu register it uses, I did this once for the 770 (by modding the kernel, same basic results). There are some undocumented RETU and TAHVO ports that control the charge circuit. They're undocumented because setting them wrong causes the battery to overheat and possibly explode. Read at your own risk! retu interrupt mask 0x0100 is a 5 second timer used for charge timing. the ADCs are documented in that link you mentioned. retu register 9 has bits that control the charge process but I never decoded them fully. reg 15 and 16 are also involved in controlling the regulator. reg 20 mask 0x1000 is set when the charger is plugged in tahvo register 4 is the charge control frob. Values from 0 (disable charging) to 255 (maximum charge rate) can be written. Must coordinate with ADC values or the battery goes boom! tahvo reg 8 controls charging but I don't know exactly what the bits do (except that mask 0x0001 global-enables the charger). Same for reg 12. tahvo reg 13 is a signed 16 bit ADC that tells you the current flowing into the battery (positive when charging, negative when running). I don't know the scale. The overall charge process is one of setting the charge current to try to get a specific voltage (i.e. constant current (max) at first, followed by variable current (mostly reducing) to get constant voltage) and periodically shutting down the charger to read the idle voltage/current. When you need to set the charge to zero current to get the right voltage, you're done. This is a standard lithium charge cycle. I'm guessing the periodic shutdown helps it deduce charge time ETA. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
(Excuse me, many of you saw the follow-ups to this mail earlier, but I posted from an unsubscribed address, so resending for posterity) Hi Simon, Simon Pickering wrote: What about a short term plan with common objectives: - Raise in a structured way the topics that matter to you where you feel there is a lack of response from Nokia. - Tag silences i.e. ToDo (answer will come when we have time), Planning (still undecided, working on it), Later or Depends on XXX (other events need to come first), Confidential (the stuf we really cannot talk about, probably less than you think). - Prioritize the items you want answered first. Proposal for actions: - Niels (web tools), Dave (web content) and Andre/Karsten (to be introduced officially as bugmasters) are your kind of representatives and they have lots of hours funded by Nokia to work for you. They are the ones prioritizing the tasks that are relevant to the community. Make sure they see how important is the thing you want to push. Avoid private communications unless your stuff is private: lobby here, in bugzilla, in planet maemo... - This prioritization should be visible somewhereand people should be able to impact it directly. Someone proposed to have some kind of ideastorm where the community could make visible the stuff that really matters. Voting bugs in bugzilla kind of does it but kind of not. Let's work on this, starting soon and simple - then improve. Give us the hottest topics in the main areas and let's concentrate on those. What's the easiest way for you chaps to look at the points we bring up? Wiki page? Or a similar process to the original roadmap items - we email the list succinctly with a question and the item information are placed on a locked wiki page for all to see? Since this is an ongoing thing, a mailing list thread probably isn't the most appropriate. We could do this in a wiki page, or we could put creating a brainstorm-type site in the TODO list for May, and use that. In the short term, a mailing list thread here, which I could summarise into a wiki page, seems like a good way for us to get started. From my point of view, there are probably 3 lists that we as the community should be providing here. They may or may not be interlinked, but I think they could probably be handled separately if that would make life easier: 1. Items we'd like to know the status of (e.g. SBC DSP task, IVA, PowerVR) 2. Things we'd like to see open sourced and a reason why (e.g Hildon desktop, RSS reader, BME, DSME) 3. Other miscellaneous issues to be addressed (library versioning and request for specific libraries to be bumped, though this might make more sense for the bugtracker?) My interest is mainly in the first two, so I have probably neglected the last one. Let's use this list as a template, then. Can people identify very specific things (and please, assume I don't know what the acronyms mean, and don't know the history behind the issues ;) and I'll get started on a wiki page? Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi, ext Marcin Juszkiewicz wrote: Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? I'm not sure whether they are available for 770, but at least I've seen posts about somebody compiling them to N8x0. They don't have that many HW dependencies you know... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Dnia Tuesday, 6 of May 2008, Eero Tamminen napisał: Hi, ext Marcin Juszkiewicz wrote: Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? I'm not sure whether they are available for 770, but at least I've seen posts about somebody compiling them to N8x0. They don't have that many HW dependencies you know... I can agree if you want to run them under OS2008. But if you want to use whole system from own build then it starts to be a problem - dsme, bme etc are closed. -- JID: hrw-jabber.org OpenEmbedded developer/consultant catholic god himself invented autotools just for amusement first there was the great flood, then the plague, now autotools ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Corporate ownership of open source projects [LWN]
A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. Not an ideal model, but one that solves the problem of legacy hardware that vendors will not allow releasing info on. Indeed; I also think it would not be a big deal to setup daily/nightly builds of this module, once the source trees have been identified - I don't expect them to be too many. That's something much more practical and easier to achieve than release all the code, including what is not under your direct control. If the solution to ease the pain of development is one script away, i guess it shouldn't be too hard to implement and too unreasonable to demand that Nokia provides it as proof of goodwill. While we're talking about graphics drivers, I wonder if we could have more information about certain decisions, the PowerVR for one. It would be nice to know why we don't have a driver. Could this slot into a similar release a binary blob sort of scheme, or is there some other limiting factor? There is certainly frustration in the community that parts of the system are not open source, both for specific developmental reasons and non-specific evangelical reasons. From my own point of view, the main frustration is that we lack information about what's going on behind the scenes - whether certain aspects are work-in-progress, too low a priority so will never get done, impossible due to hw limitations, etc. (e.g. would WiFi binary blob be considered - we know the unofficial answer to this now, PowerVR driver, SBC encoder task). I don't expect Nokia to give me everything they have, but I would like to know if it's worth working on certain things (e.g. if there are hardware issues or Nokia is already doing work on them). This might create some expectation problems, but I'm not sure that would be worse than our frustration at not knowing anything at all. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Are you asking for more examples of non-kernel code that we can't modify? Unless I just haven't found them, there's also no way to build the dsp gstreamer plugins (lack of osso-dsp-headers-rx-44.) I filed a bug related to the behavior of these plugins, and I don't know enough to be certain the bug is inside the dsp plugins themselves, but it would be easier to poke around if they could be repackaged to run on a live system. Kees Jongenburger wrote: On Tue, May 6, 2008 at 5:36 AM, Igor Stoppa [EMAIL PROTECTED] wrote: Till here you are not really providing much of a proposal for getting things done, just generic complaints that historically are proven to not work. Hello Igor and others, From reading this thread I have the feeling we are pretty close to getting into a workable situation Most of the disc spawns around the kernel. it looks to me like all sides are ready to make some concessions if that means that we can have a self compiled kernel. One other threads proposed to put the different known kernel hacks and patches into a garage project and nokia seams ready to search for a pragmatic solution to what the looked like the biggest problem to methe binary wlan kernel module. is this only a feeling? greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Corporate ownership of open source projects [LWN]
Thanks for the discussion and the many good ideas. About silence, in fact a lot of it has not to do with confidentiality but lack of priority (or too many top priorities in the hands of us able to respond). What about a short term plan with common objectives: - Raise in a structured way the topics that matter to you where you feel there is a lack of response from Nokia. Now it is difficult to follow everything even to people like me spending a lot of time here, leave alone the average lead developer, project manager or product manager in the house. - Tag silences i.e. ToDo (answer will come when we have time), Planning (still undecided, working on it), Later or Depends on XXX (other events need to come first), Confidential (the stuf we really cannot talk about, probably less than you think). - Prioritize the items you want answered first. Proposal for actions: - Niels (web tools), Dave (web content) and Andre/Karsten (to be introduced officially as bugmasters) are your kind of representatives and they have lots of hours funded by Nokia to work for you. They are the ones prioritizing the tasks that are relevant to the community. Make sure they see how important is the thing you want to push. Avoid private communications unless your stuff is private: lobby here, in bugzilla, in planet maemo... - This prioritization should be visible somewhereand people should be able to impact it directly. Someone proposed to have some kind of ideastorm where the community could make visible the stuff that really matters. Voting bugs in bugzilla kind of does it but kind of not. Let's work on this, starting soon and simple - then improve. Give us the hottest topics in the main areas and let's concentrate on those. - Diablo is coming. Let's pick the components in this software release and let's make a table where packages are organized in a clear way to show where they sit in the platform and what functionality they provide. Then let's look at the closed components and let's work on the why are they closed and what is the plan about them. - Roadmapping the open source components of the platform. Should be doable in most cases, specially those libraries developers care about. -- Quim Gil marketing manager, open source maemo software @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
On Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrt ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
My dear friend,software fromhttp://approsoftware.com/is exactly declared as Linux open software product.Unfortunately its offered as a commercial product at high chargeas hardware lock key is installed to make itnot to function without hardware lock key installed.I have already contacted Free Software Foundationasking for kind explanationif it objects or notto have GNU Open Source software to be commercializedby installation of hardware lock key in embedded products.Nokia Internet Tablet is one of such productsand acting that way Nokia can disable some libraries, functions or proprietary/non-proprietary applications, installing hardware lock keymaking GNU open source software disabled without payingextra fee/charge.If this is just the case, GNU open source is no more free open source softwareunder GNU lincense as to run it on embedded device one will have to pay unreasonable extra fee.As any Linux open source project/software is based on community past and present workcommercialization of hardware lock key protected new Linux softwareis exactly making profit and money on community workaccessed for free.Asking community to work for free to let few guys to make real money on commercialized Linux software products.So there is no instead, as the software product offered byApprosoftware.comis exactly described as open source.And demo version is for free, commercial Linux open source version is for fee.Just download and install it to see the problem.DariusJust--- On Mon, 5/5/08, Raphaël Jacquot [EMAIL PROTECTED] wrote:From: Raphaël Jacquot [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Cc: maemo-developers@maemo.org, "Luca Olivetti" [EMAIL PROTECTED]Date: Monday, 5 May, 2008, 9:22 AMOn Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrtSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi Andrew, Andrew Flegg wrote: On the back of my post, maemo.org: what next?[1], it was interesting to read in yesterday's LWN that the community around OpenSolaris feels very much shut out of internal Sun development processes: http://lwn.net/SubscriberLink/280452/8f5b64d861d8f79e/ Indeed - an interesting read. He quoted some very good sources ;-) Reading this, it was very striking the number of similarities with Nokia's situation with maemo and the maemo community. The above is a free link, but I strongly recommend you subscribe to LWN[2] if you haven't already. While I'm still getting to know the maemo community, I think tyhat the difference is in the goals, and in the means that Nokia are putting at the disposition of the community to achieve those goals. Yes, Nokia employees were behind most of the early maemo work. But they also chose to hire small companies with established free software credentials (OpenedHand, Imendio, OpenIsmus, Nemein, Kernel Concepts, the list goes on) to do much of the work. Even though these guys were working in the beginning under NDA, that's a good sign that Nokia wanted to work with upstream projects, rather than create a walled garden. There's also the way that Nokia is now investing in people like myself Niels, and André and Karsten to ensure that weak points of interaction between the community and any Nokia technology are identified and eliminated. I have not been asked to sign any NDAs, and all the work I do will be out in the open, using information available to the community (or I will be asking for that information to be made available). Nokia's goals appear, at least to me, to be clear (but I have no more information on this than anyone else). Their goal is to make a commercially successful tablet product, using as much free software as possible, and providing an open development platform for developers, thereby creating a vibrant ecosystem of application developers targeting the maemo platform. I expect Nokia to keep some control of Hildon and all of the components on which they build their commercial products. But control comes in many forms. Just employing a maintainer doesn't imply control (just ask Josh Berkus or Linus Torvalds) nor does it imply that significant community contributions are unwelcome. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
Please read the followingfromhttp://approsoftware.com/en/aboutus.htmlopen-source software based on Linux OS is being sold as a commercial producthttp://approsoftware.com/en/howtobuy.html About us Alfanet sp. z o.o. is a Wroclaw-based Polish company, operating since 1996 as an ISP, as well as provider of solutions based on Open-Source Software and Linux operating system. We offer to our customers such services as Web hosting, domain registration and maintenance, design of Web applications and Web pages, network security and wireless Internet access. Alfanet also designs and sells specialized APPro software for Access Points based on ***RTL8186 and Atheros chipsets. This software increases functionality and value of Access Points. APs with the new firmware can replace more expensive Access Points as well as other network devices (bandwidth managers, firewalls, watchdogs). This can bring significant savings related not only to hardware purchases, but also the time needed to work with this extra hardware. Our software also increases network security and its performance. Additionally APPro makes it possible to customize ISP's offer to current demands, which translates to better customer satisfaction. Alfanet, SP. z o.o. ul. Bulwar Ikara 29A/2 54-130 Wrocław Poland Tel. +48 71-79 56 000 Fax +48 71-79 56 500 Last update: Tuesday, 02 October 2007--- On Mon, 5/5/08, Raphaël Jacquot [EMAIL PROTECTED] wrote:From: Raphaël Jacquot [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Cc: maemo-developers@maemo.org, "Luca Olivetti" [EMAIL PROTECTED]Date: Monday, 5 May, 2008, 9:22 AMOn Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrtSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Dnia Monday 05 of May 2008, [EMAIL PROTECTED] napisał:
[EMAIL PROTECTED] wrote:
unfortunately the closed part (umac.ko) is full kernel module not
linkable object file so it too depends on kernel version and sadly
even specific kernel configuration
So close, and yet so far away. I would say that umac.ko should
definately be reworked so it is not distributed as a complete kernel
module, but just an object, umac.o, that can be linked to an open
source driver, perhaps even hooked directly to cx3110x.ko.
There is a trick to get umac.ko built for other kernels then default one.
Have a look at [1] and [2]. You need to have umac.ko from device and
remove some sections from it. Then cx3110x 1.x driver can be compiled for
it (I did not tried it with 2.0.15).
cp ${WORKDIR}/umac.ko ${S}/src/binary_umac.o
${OBJCOPY} ${S}/src/binary_umac.o -R __ksymtab
${OBJCOPY} ${S}/src/binary_umac.o -R __ksymtab_strings
${OBJCOPY} ${S}/src/binary_umac.o -R .gnu.linkonce.this_module
${OBJCOPY} ${S}/src/binary_umac.o -R .modinfo
${OBJCOPY} ${S}/src/binary_umac.o -R .init.text
${OBJCOPY} ${S}/src/binary_umac.o -R .exit.text
1.
http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/OE1/revision/file/d4a97f257158aba4fde91347580030110ef215bf/packages/c3110x/cx3110x_1.1.bb
2.
http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/OE1/revision/file/d4a97f257158aba4fde91347580030110ef215bf/packages/c3110x/files/umac_binary.patch
Method with open source driver + firmware blob would be better but this
will rather do not happen as 770 and n8x0 are already on market so Nokia
wont spent any extra money on rewriting driver.
--
JID: hrw-jabber.org
OpenEmbedded developer/consultant
Any smoothly functioning technology will have the appearance of magic.
-- Arthur C. Clarke
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Dnia Saturday 03 of May 2008, Igor Stoppa (Nokia) napisał: Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. The padlock is on many things which got limited just because no one took a moment to discuss things with community (guess). -closed SW: Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. At least ability to *read* battery status without Nokia *closed* binaries should be possible. There is battery class now in kernel... Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. This also blocks Nokia tablets from being usable with non-maemo systems. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. This is not a solution. There are many closed components (some of them were open in older releases) and one person will never get request queue cleaned in acceptable time. I will not mention that many of those closed components looks like closed just because Nokia was able to close it -- other ideas do not came to my brain now. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. I hope that one day (during this year not 2012) few Nokia developers/managers will take a list of maemo components and triple check which one should be closed and which not. Then releasing sources for second ones and reasons of closing for others. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. People are doing lot of low kernel development on misc palmtops with only serial cables (some try even without them). Having measuring tools, special boards is handy but such setups not always are the same as final devices. -- JID: hrw-jabber.org OpenEmbedded developer/consultant It might look like I'm doing nothing, but at the cellular level I'm really quite busy! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Mon, 2008-05-05 at 22:30 +0200, ext Marcin Juszkiewicz wrote: Dnia Saturday 03 of May 2008, Igor Stoppa (Nokia) napisał: Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. The padlock is on many things which got limited just because no one took a moment to discuss things with community (guess). -closed SW: Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. At least ability to *read* battery status without Nokia *closed* binaries should be possible. There is battery class now in kernel... Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. This also blocks Nokia tablets from being usable with non-maemo systems. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. This is not a solution. There are many closed components (some of them were open in older releases) and one person will never get request queue cleaned in acceptable time. I will not mention that many of those closed components looks like closed just because Nokia was able to close it -- other ideas do not came to my brain now. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. I hope that one day (during this year not 2012) few Nokia developers/managers will take a list of maemo components and triple check which one should be closed and which not. Then releasing sources for second ones and reasons of closing for others. Till here you are not really providing much of a proposal for getting things done, just generic complaints that historically are proven to not work. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? Ask Quim, he is the Maemo man. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. People are doing lot of low kernel development on misc palmtops with only serial cables (some try even without them). Having measuring tools, special boards is handy but such setups not always are the same as final devices. Even our developers have problems at producing proper code without these tools. It's relatively easy to get some functionality to apparently work, but getting it to work right and properly leverage the HW is a different case. And we take care that our hw boards are in sync. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. That is just additional cost caused by the closed components. Use open components and use the money for something more useful. And I thought that I was writing in good english. Poor me. I'm talking about the past and you want open components. Is Nokia supposed to go around and replace all the sold devices with open hw? No, certainly not. Please excuse _my_ bad English ;-) We all made our experiences with Linux devices entering the mass market in the last few years. Nokia played an important role here, and the internet tablet devices and the Maemo project are definitely very positive things I'm grateful for. On the other hand, the enthusiasm I had at the beginning has vanished. I found out that I cannot do whatever I like with the device because important parts are closed and proprietary. I will certainly never buy such a device again. I've an N770 and would be interested in the N810, but will not buy it for this reason. Of course I know that 99% of the internet tablet users don't want to do system programming for their devices. But even they should know that blocking programmers always means blocking (some) interesting software alternatives. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. I'll continue demanding open hardware. I'm really fed up with so-called Linux devices where I can't make the hardware work with free software. I've a similar problem ATM with the Eee PC's unsupported WLAN and its buggy BIOS... And that is good, but once certain things have happened, there is no way back. An I think I have explained what I think are the obstacles in opening specs of existing hw. Not that i wouldn't be happy to be proven wrong. OK, maybe you cannot open the specs for existing hardware, I don't know. But in general it is of course possible to design mass market hardware in a way that allows open specs. All I want to say is that I beg Nokia to actually do this the next time you design Linux compatible hardware. Hardware is Linux compatible if and only if there's a GPLed driver for it. Next time I'll check this _before_ I buy the device, I don't want to be disappointed again. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Oh, please, leave that to the people who want to do kernel development. Yeah, I happen to be one of them, sorry for the personal point of view. OTOH the fact that you don't care doesn't mean others are not interested. If you talk about an open device, it's the whole stack that should be targeted, no? No. If someone wants to build a new kernel for a device, it's pretty clear that he should know what he's doing, that he might render the device unusable, and so on. And he should also be able to judge if he has all the skills and equipment he will need for this kind of work. That's the personal decision of each individual programmer. Your note about special boards sounded to me like an effort to keep people away from low-level programming. That would certainly be easier for you, because then nobody needed open hardware specs... Nobody in the community has such setup, How do you know that? I compile kernels for ARM devices almost every day and also build the bootloaders for them. But not our own boards, i guess. If you do it would be interesting to know how you have obtained one. Compiling for your custom or eval board means very little. To give you an example, every pad must be checked so that it has the right idle configuration depending on what is connected to it, or high currents can be
Re: Corporate ownership of open source projects [LWN]
Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch [EMAIL PROTECTED] wrote: Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. Cheers And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. That is just additional cost caused by the closed components. Use open components and use the money for something more useful. And I thought that I was writing in good english. Poor me. I'm talking about the past and you want open components. Is Nokia supposed to go around and replace all the sold devices with open hw? No, certainly not. Please excuse _my_ bad English ;-) We all made our experiences with Linux devices entering the mass market in the last few years. Nokia played an important role here, and the internet tablet devices and the Maemo project are definitely very positive things I'm grateful for. On the other hand, the enthusiasm I had at the beginning has vanished. I found out that I cannot do whatever I like with the device because important parts are closed and proprietary. I will certainly never buy such a device again. I've an N770 and would be interested in the N810, but will not buy it for this reason. Of course I know that 99% of the internet tablet users don't want to do system programming for their devices. But even they should know that blocking programmers always means blocking (some) interesting software alternatives. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. I'll continue demanding open hardware. I'm really fed up with so-called Linux devices where I can't make the hardware work with free software. I've a similar problem ATM with the Eee PC's unsupported WLAN and its buggy BIOS... And that is good, but once certain things have happened, there is no way back. An I think I have explained what I think are the obstacles in opening specs of existing hw. Not that i wouldn't be happy to be proven wrong. OK, maybe you cannot open the specs for existing hardware, I don't know. But in general it is of course possible to design mass market hardware in a way that allows open specs. All I want to say is that I beg Nokia to actually do this the next time you design Linux compatible hardware. Hardware is Linux compatible if and only if there's a GPLed driver for it. Next time I'll check this _before_ I buy the device, I don't want to be disappointed again. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Oh, please, leave that to the people who want to do kernel development. Yeah, I happen to be one of them, sorry for the personal point of view. OTOH the fact that you don't care doesn't mean others are not interested. If you talk about an open device, it's the whole stack that should be targeted, no? No. If someone wants to build a new kernel for a device, it's pretty clear that he should know what he's doing, that he might render the device unusable, and so on. And he should also
Re: Corporate ownership of open source projects [LWN]
Hi Ed, good to see you still around here! On Sun, 2008-05-04 at 11:20 -0500, ext [EMAIL PROTECTED] wrote: Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch [EMAIL PROTECTED] wrote: Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. Not an ideal model, but one that solves the problem of legacy hardware that vendors will not allow releasing info on. Indeed; I also think it would not be a big deal to setup daily/nightly builds of this module, once the source trees have been identified - I don't expect them to be too many. That's something much more practical and easier to achieve than release all the code, including what is not under your direct control. If the solution to ease the pain of development is one script away, i guess it shouldn't be too hard to implement and too unreasonable to demand that Nokia provides it as proof of goodwill. Of course those who are interested in wifi development would still have reasons to complain, but the majority of developers would see the obstacle removed. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch [EMAIL PROTECTED] wrote: Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. Not an ideal model, but one that solves the problem of legacy hardware that vendors will not allow releasing info on. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi Ed, good to see you still around here! I'm always lurking. :) On Sun, 2008-05-04 at 11:20 -0500, ext [EMAIL PROTECTED] wrote: Hi, On Sun, May 4, 2008 at 3:30 PM, Hans J. Koch [EMAIL PROTECTED] wrote: Am Sat, 03 May 2008 20:53:53 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. Proprietary modules are a GPL violation (though this is sometimes tolerated) and taint the kernel. You loose the kernel community's support if you use them. That support is more important than Nokia's support. And I doubt you can supply modules for all the kernel flavors out there. Today, I might want to use 2.6.26-rc1 (came yesterday), Linus' git tree (changes every few hours), or linux-next (changes daily). Thats pretty much the key point for me in this discussion. If you really want to be able to foster an independent linux distro (or more than one), then you need/want to be able to control and upgrade your kernel. Most of the kernel and system components are open or enough is known to provide basic usage, but an 'internet tablet' with proprietary wifi firmware that is not accessible in newer kernel version is a killer. At the moment i am happy with usb networking for my experiments with newer kernels, but the basic function of the device is crippled. Not complaining, and I do not know if it is feasible to supply builds of umac.ko for later kernel versions, but I think this is a barrier to really fostering a 'community distro'. A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. Not an ideal model, but one that solves the problem of legacy hardware that vendors will not allow releasing info on. Indeed; I also think it would not be a big deal to setup daily/nightly builds of this module, once the source trees have been identified - I don't expect them to be too many. That's something much more practical and easier to achieve than release all the code, including what is not under your direct control. If the solution to ease the pain of development is one script away, i guess it shouldn't be too hard to implement and too unreasonable to demand that Nokia provides it as proof of goodwill. Of course those who are interested in wifi development would still have reasons to complain, but the majority of developers would see the obstacle removed. It should be possible to make the public API very close to the capabilities of the chip, so even wifi developers could focus on higher level things and not be too disappointed. But the key point is that it would make it trivial for the general users to upgrade their kernel without loosing functionality. When I wrote the drivers for the Quicknet telephony cards, they initially did not want to open source the drivers, so we did a similar wrapper scheme. Later when they decided to integrate their drivers into the kernel it was a simple task of merging the previously closed object with the open kernel module. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Igor Stoppa wrote: -serial console: that can be obtained with some hacking by attaching a level shifter and a serial connector to the serial pads exposed, it would be enough to release schematic and layout (although i think there are already unofficial howtos) For 770 those pin are known, there is a schematics with pin descriptions. For N800 it is harder, there is also schematics on the net but those pins are sadly not documneted there. For N810 we even don't have schematics. Personaly I have tried it with clone of CA-42 cable http://www.dealextreme.com/details.dx/sku.446, there is PL-2302 usb to serial converter in the blue connector so in theory one could just cut nokia plug, attach rx,tx and gnd to 770 pads and connect it over USB. When I tried I had no output in terminal when booting (with rd and serial console flags) so most probably I did something wrong or my plug made from pins and rubber had bad contact or the cable was faulty or whatever. I guess I'll try some soldering next time. There are some bits that are quite trivial. I don't think anybody with some programming experience would have problem at stitching together a replacement for dsme mce, given the functional specifications. The state machines implemented are not so straightforward, but a simple start to get going is probably not too difficult to obtain. brightness, watchdog kicking, ... all relatively easy, the hardest part is IMO /usr/lib/dsme/libcalmodule or /usr/lib/libcal.so, these modules implement access to config partition /dev/mtd1. There is some sort of filesystem which stores quite interesting and vital information. It can be reverse-engineered but I fear that trying to write there can be fatal if done wrong. Hopefully current work on qemu N800 emulation will allow us to play with it safely. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. Yes, that's what I sugested here (end of mail, point 2) http://lists.maemo.org/pipermail/maemo-users/2008-April/010183.html for those who missed it (in maemo-users) whole thread relevant to this discussion is here http://www.gossamer-threads.com/lists/maemo/users/36150 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
[EMAIL PROTECTED] wrote: A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. It is almost like this but not exactly. There is cx3110x open source glue part cx3110x.ko (see http://cx3110x.garage.maemo.org/), so far so good, but unfortunately the closed part (umac.ko) is full kernel module not linkable object file so it too depends on kernel version and sadly even specific kernel configuration, see https://garage.maemo.org/pipermail/cx3110x-devel/2007-December/07.html I don't understand where the line in GPL vs binary only code in kernel lies. I'd say that using struct sk_buff should make it derived work of linux kernel and subject to GPL but of course IANAL. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
[EMAIL PROTECTED] wrote: A possible interim solution is to use one like nVidia has used for years for their closed video card drivers. Provide a binary object that implements all the core functionality of the chip, with a public API. Then have an open source kernel module wrapper that calls the funcions in the public API of the binary module. Then the open source part can be compiled for any kernel version and simply link in the closed object. It is almost like this but not exactly. There is cx3110x open source glue part cx3110x.ko (see http://cx3110x.garage.maemo.org/), so far so good, but unfortunately the closed part (umac.ko) is full kernel module not linkable object file so it too depends on kernel version and sadly even specific kernel configuration, see https://garage.maemo.org/pipermail/cx3110x-devel/2007-December/07.html So close, and yet so far away. I would say that umac.ko should definately be reworked so it is not distributed as a complete kernel module, but just an object, umac.o, that can be linked to an open source driver, perhaps even hooked directly to cx3110x.ko. I don't understand where the line in GPL vs binary only code in kernel lies. I'd say that using struct sk_buff should make it derived work of linux kernel and subject to GPL but of course IANAL. Having been there and done that before, the line is in where the core functionality of the module is from. If the module is developed completely from scratch for the purpose of driving a specific piece of hardware, or derived from a closed driver for the same hardware on a different OS, then it is tolerated as a closed source driver for Linux. Simply using Linux structures that are required to interface to the kernel, in this case sk_buff, is not sufficient to call the driver a derived work from open source, and the GPL does not apply. Ed Okerson ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
The funny thing is that steps in the right direction like opening up the hildon input framework and HE where not pick up that well(IMHO...).This while we have screamed (and thus decided that is was important) thing to do. What you are saying that there is no path in between. we need [EMAIL PROTECTED] , serial cables,and hardware specs! That would be a very interesting experiment. Right... It is like that game of 'pass the parcel' you play as kids when you unwrap a layer of a present when the music stops. It does not matter how interesting each layer is (Hildon Input Framework etc) if the final layer has a padlock around it. It would have been better to have played 'Hide and Seek' instead, you get no prize but at least you know whats gonna happen and its free. Maybe a clever solution to this would be for Nokia to take some dead product that everyone has forgotten about and completely open it. Hell, even make some marketing splash like: 'In response to community feedback we are releasing 'X' under the GPL. In its time 'X' had the most innovative power management on the market but we think that this can be improved by a 'lots of eyeballs' approach. Prove us right, do your bit for the planet and join us on maemo.org' I'd hack on it anyway Ian -- http://ianlawrence.info ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Sat, 2008-05-03 at 10:00 -0400, ext Ian Lawrence wrote: It is like that game of 'pass the parcel' you play as kids when you unwrap a layer of a present when the music stops. It does not matter how interesting each layer is (Hildon Input Framework etc) if the final layer has a padlock around it. It would have been better to have played 'Hide and Seek' instead, you get no prize but at least you know whats gonna happen and its free. Maybe a clever solution to this would be for Nokia to take some dead product that everyone has forgotten about and completely open it. Hell, even make some marketing splash like: 'In response to community feedback we are releasing 'X' under the GPL. In its time 'X' had the most innovative power management on the market but we think that this can be improved by a 'lots of eyeballs' approach. Prove us right, do your bit for the planet and join us on maemo.org' I'd hack on it anyway Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. To hack on the hardware you would need: -serial console: that can be obtained with some hacking by attaching a level shifter and a serial connector to the serial pads exposed, it would be enough to release schematic and layout (although i think there are already unofficial howtos) -undocumented HW: TI has opened some of the latest and greatest HW but afaik nothing is going on regarding older products. We have been asking them to release it since we shipped 770. So much for the Nokia can exert more pressure than a single developer mantra. One could argue that we should not have used closed HW and I respect the argument, but containing cost was one of our goals and Nokia buys gazillions of OMAPs. Guess which chip was cheaper ... Then we have some legacy Nokia ASIC that AFAIK is still in use in phones, where many more features are used than what we have in the tablet. Namely Retu/Tahvo and following variants. Again a HW design decision that had pros and cons. We have already enjoyed the pros, now it's time for the cons. Personally I doubt that we would have any real problem in releasing the specs, but when the chip is inside so many devices already on the market, lots of people get nervous (to understate it) when there might be some lawsuit on the horizon for safety threats - the chips are involved in battery charging. Or SIM handling - another hot topic with operators. -closed SW: There are some bits that are quite trivial. I don't think anybody with some programming experience would have problem at stitching together a replacement for dsme mce, given the functional specifications. The state machines implemented are not so straightforward, but a simple start to get going is probably not too difficult to obtain. Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
...(cut for clarity)One simple question referring to your thread.There is a number of manufacturers of WIFI acceess points running subset of Linux commands/ kernel.There is a company X offering some upgrade reflashing Wifi AP OS , showing new features.New flash shows no GNU Open Source Licence, no source code is provided.Is it ok ?So another proprietary, commercial Linux-based applicationoffered for fee, commercially-licensed ?DariusSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
El Sat, 03 May 2008 17:47:08 +0300 Igor Stoppa [EMAIL PROTECTED] escribió: TI has opened some of the latest and greatest HW but afaik nothing is going on regarding older products. We have been asking them to release it since we shipped 770. So much for the Nokia can exert more pressure than a single developer mantra. That was me ;-) and from what you tell I was obviously wrong, I apologize. I won't say what I think about TI since this is a public mailing list and I'd hate needing a lawyer :-D Bye -- Luca ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
...sorry(cut for clarity)I the meantime I was contacted and learneed that offered softwarewas opensource (no GNU Open Sourrce licence included).Unfortunately software - firmware for Wifi Access Pointsis offered hardware key lockedfrom the following web pagehttp://approsoftware.com/I would like to know your opinionif opensource software (GNU Open Source licence (not included)intended for Linux OS,can be hardware key lockedto disable its functions.Acting that way, any opensource software for Linux can be hardware key lockedand sold for fee as a commercial productrestricted access sourcees provided or not.DariusSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius Ask your lawyer and don't hijack threads. -- Ryan Pavlik www.cleardefinition.com #282 + (442) - [X] A programmer started to cuss Because getting to sleep was a fuss As he lay there in bed Looping 'round in his head was: while(!asleep()) sheep++; ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
Thanks.Exactly what I was looking for.What I mean is Wifi Access Point built and manufactured in China by AirWaveand add-on hardware key and new firmware doesn't come from Chinabut from third party, installing hardware and software in originally delivered and manufacturer sealed box.So hardware comes from factory key free, unlocked,hardware lock is installed by developer of GNU Open Source Softwareto generate profit on sale of modified product (upgraded firmware).Going the same rule, Nokia can incorporate hardware key into Nokia Internet Tabletone day as well as any other manufacturer of hardware running Linux.Dariuscomesfromhttp://www.codinghorror.com/blog/archives/001060.html" This concept of software freedom is embedded deeply into the GPL. As promised, we indeed have the freedom to see the Tivo source code, copy it, and change it. Since the Tivo's hardware validates the software, access to the Tivo software becomes effectively meaningless. You can modify the software all you want, but you'll never be able to run it on your own Tivo! You might, in fact, argue that Tivo subverted the very principles of the GPL they built their business on. Richard Stallman certainly did. He felt so strongly about this perceived subversion of the GPL that he literally went back and rebuilt the GPL license to prevent what Tivo did: ..'"--- On Sat, 3/5/08, Clarence "Sparr" Risher [EMAIL PROTECTED] wrote:From: Clarence "Sparr" Risher [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Date: Saturday, 3 May, 2008, 7:38 PMOn Sat, May 3, 2008 at 1:22 PM, Darius Jack [EMAIL PROTECTED]wrote: I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions.Google "tivoization". This is legal under GPL v2, while otherlicenses (notably GPL v3) seek to prohibit it.Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
Ok.Ask your lawyer yourself first.The thread is exactly about the same.Making money on community developed Linux based projectsand corporate ownership of such projects.Hardware key locked embedded hardware is exactly the way tox-transfer ownership of any community developed project (open source)to manufacturer of any such embedded hardware.Darius--- On Sat, 3/5/08, Ryan Pavlik [EMAIL PROTECTED] wrote:From: Ryan Pavlik [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Cc: maemo-developers@maemo.org, "Luca Olivetti" [EMAIL PROTECTED]Date: Saturday, 3 May, 2008, 7:51 PMDarius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. DariusAsk your lawyer and don't hijack threads.-- Ryan Pavlik...Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi, On Sat, 2008-05-03 at 19:58 +0200, ext Hans J. Koch wrote: Am Sat, 03 May 2008 17:47:08 +0300 schrieb Igor Stoppa [EMAIL PROTECTED]: Hi Igor, In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. You're right, I'm not satisfied. The acid test for a Linux device based on OpenSource software is that I can compile my own kernel. I want to be able to download 2.6.25 from kernel.org now, apply some hardware specific patches (GPL, of course) and compile that. With this kernel, all hardware of the device should be functional. Whenever a company designs such a device, hardware should be chosen that makes this possible. Note that I'm not talking about firmware. IMHO firmware belongs to the hardware, and there might be valid reasons to keep it closed, e.g. to fulfill legal requirements for the WLAN chip or for the battery charger you mentioned. In userspace, closed source applications are OK as long as I have all information required to write my own replacement. No help from Nokia is required, except giving us information. I accept it if I have to fix the kernel patches for a new kernel version myself. And of course I accept that it's my own problem if something doesn't work. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. I disagree. Any closed part in a Linux system forces developers to implement stupid wrappers and workarounds somewhere. If I'm forced to use a certain kernel or glibc version, it's not an open system. Probably i was not clear: i'm just saying that if a new kernel comes out and the only impediment in using it is that the proprietary module is not compliant, a new module compiuled against the new kernel should be made available. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. That is just additional cost caused by the closed components. Use open components and use the money for something more useful. And I thought that I was writing in good english. Poor me. I'm talking about the past and you want open components. Is Nokia supposed to go around and replace all the sold devices with open hw? This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. I'll continue demanding open hardware. I'm really fed up with so-called Linux devices where I can't make the hardware work with free software. I've a similar problem ATM with the Eee PC's unsupported WLAN and its buggy BIOS... And that is good, but once certain things have happened, there is no way back. An I think I have explained what I think are the obstacles in opening specs of existing hw. Not that i wouldn't be happy to be proven wrong. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Oh, please, leave that to the people who want to do kernel development. Yeah, I happen to be one of them, sorry for the personal point of view. OTOH the fact that you don't care doesn't mean others are not interested. If you talk about an open device, it's the whole stack that should be targeted, no? Nobody in the community has such setup, How do you know that? I compile kernels for ARM devices almost every day and also build the bootloaders for them. But not our own boards, i guess. If you do it would be interesting to know how you have obtained one. Compiling for your custom or eval board means very little. To give you an example, every pad must be checked so that it has the right idle configuration depending on what is connected to it, or high currents can be seen. Hard to do without schematics. so some help from Nokia for validation would still be required. What do you want to validate? I agree if my warranty is void if I use my own kernel, just let me do it. Maybe i'm too idealistic, but my idea of open source is a working model where if one has an interesting piece of code, the code can be committed back to the community. Code compile tested or boot tested should not be good enough for being included in repositories that are meant to be used for rolling kernels that will be provided to less experienced users. I don't care if you void your warranty and blow up your device, but i get interested if you start distributing such
Re: Corporate ownership of open source projects [LWN]
Hello Andrew, I found your post very interesting. The moost apealing idea I find is the community maintained hackkers edition. did the maemo people do anything wrong in that aspect? I don't really see what there is to learn from what SUN is doing. What I see is a platform that has grown and that I would call mature and perhaps a little borring? greetings On Fri, May 2, 2008 at 1:13 PM, Andrew Flegg [EMAIL PROTECTED] wrote: Hi, On the back of my post, maemo.org: what next?[1], it was interesting to read in yesterday's LWN that the community around OpenSolaris feels very much shut out of internal Sun development processes: http://lwn.net/SubscriberLink/280452/8f5b64d861d8f79e/ Reading this, it was very striking the number of similarities with Nokia's situation with maemo and the maemo community. The above is a free link, but I strongly recommend you subscribe to LWN[2] if you haven't already. Cheers, Andrew [1] http://www.maemopeople.org/index.php/jaffa/2008/04/20/maemo_org_what_next [2] http://lwn.net/ - Linux Weekly News -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Fri, May 2, 2008 at 7:31 PM, Kees Jongenburger [EMAIL PROTECTED] wrote: Hello Andrew, I found your post very interesting. Thank you :-) The moost apealing idea I find is the community maintained hackkers edition. did the maemo people do anything wrong in that aspect? I think so. For example: * The development was done by a Nokia employee. * The tools, sources and components he had access to were not (easily) available to the community. * AFAIK, most of the work was done in work hours, with no open discussion or collaboration. There were no posts to maemo-developers discussing the project, how it was going, the issues faced. * It was ultimately thrown over the wall, with comments then coming along the lines of it'd be good if the community could maintain future versions of this, without any information on how it'd been maintained to date. I don't really see what there is to learn from what SUN is doing. What I see is a platform that has grown and that I would call mature and perhaps a little borring? Oh, I wasn't suggesting there was anything really to learn from the Sun case, just that the complaints in the OpenSolaris developer community seemed to strike a chord with the problems voiced by the maemo developer community. I wonder if mature is the right way to describe the maemo platform. From the outside, to a more cynical observer, a more pejorative description might be stagnant :-( Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi, On the back of my post, maemo.org: what next?[1], it was interesting to read in yesterday's LWN that the community around OpenSolaris feels very much shut out of internal Sun development processes: I am seeing a lot of discussions around this at the moment. I really like this post http://thunk.org/tytso/blog/2008/04/26/organic-vs-non-organic-open-source-revisited/ and from it: 'If a project decides to release its code under an open source license, but nearly all the developers remain employed by a single company, it doesn't really change the dynamic compared to when the project was previously under a closed-source license. It is a necessary but not sufficient step towards attracting outside contributors, and eventually migrating towards having a true open source development community. But if those further steps are not taken, the hopes that users will think that some project is cool because it is under an open-source license will ultimately be in vain. The Generation Y/Millennial Generation in particular are very sensitive indeed to Astroturfing-style marketing tactics. My own *personal* opinion is that we either need to be open or not. If open, then open, let us root around in the guts of the source and let go. If closed. close it and put the beast out of its misery. My fear is that it is now too late for the first option as perhaps most of the 'heads' have now moved on to more fertile pastures. I am probably wrong though, open source developers are a pretty strange and a pretty forgiving bunch Ian -- http://ianlawrence.info ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Sat, May 3, 2008 at 4:43 AM, Ian Lawrence [EMAIL PROTECTED] wrote: My own *personal* opinion is that we either need to be open or not. If open, then open, let us root around in the guts of the source and let go. If closed. close it and put the beast out of its misery. My fear is that it is now too late for the first option as perhaps most of the 'heads' have now moved on to more fertile pastures. I am probably wrong though, open source developers are a pretty strange and a pretty forgiving bunch Ian The funny thing is that steps in the right direction like opening up the hildon input framework and HE where not pick up that well(IMHO...).This while we have screamed (and thus decided that is was important) thing to do. What you are saying that there is no path in between. we need [EMAIL PROTECTED] , serial cables,and hardware specs! That would be a very interesting experiment. Greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
