Extended Hamming encode/decode
in [Embedded]
|
Prev: Announcement: New version of UML state machine code generator available
Next: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Computer Design (CDES'10), USA, July 2010
From: steve_schefter on 7 Mar 2010 20:40 David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > To use LGPL'ed code with your own code, anyone receiving your code must > have access to the LGPL'ed code, be able to change and recompile that > code, then link it along with the rest of the binary and run that > software instead. For non-embedded systems (or "big" embedded systems), > that typically means the LGPL'ed code is part of a dynamic library. To > use LGPL code in a (typically statically linked) embedded system means > that the end user will need access to your source code, or at least > compiled and linkable object files. Since that is impractical or > impossible for most embedded systems, the rough conclusion is that pure > LGPL code is very seldom suitable for embedded systems. Okay, thanks. I guess where we differ is in the opinion that dynamically linked apps are not suitable for embedded systems. The ones I work on (Linux-based) tend to use dynamically linked apps more than statically linked ones. In the early days, I've even had to force the apps to be dynamically linked to fit everything in flash (several apps linked with the same library). Steve
From: David Brown on 7 Mar 2010 20:53 Tim Wescott wrote: > Tim Wescott wrote: >> David Brown wrote: >>> On 07/03/2010 01:56, Jon Kirwan wrote: >> -- snip -- >> >>>> I've isolated these into three short modules -- one for each >>>> of the three data types required. There's an encode and >>>> decode routine in each. If anyone is interested in the >>>> results, here's a link to the code. >>>> >>>> http://www.infinitefactors.org/misc/hamm.zip >>>> >>>> A very short demo program that tests the routines and >>>> illustrates their use is also included. There is a small >> -- snip some more -- >>>> Jon >>> >>> Hi Jon, >>> >> -- snip even more -- >> >>> Why did you pick the LGPL? It basically means that people here can >>> use your code in test code, but can't (legally) use it in any >>> "production" code. >> >> -- and yet more -- >> >> Uh, no. The "GPL" part means that if someone incorporates it into a >> bit of production hardware they need to publish the parts of Jon's >> code they used. The "L" part means that they _don't_ have to publish >> any code that they wrote to link against Jon's code (unlike the "full" >> GPL, which includes the source of anything you link against). >> Plain GPL means that any code that connects to the GPL'ed code, /including/ by dynamic linking, must also be GPL'ed (and thus the source must be made available to anyone who receives a copy of the binary). Thus the GPL "spreads" from the GPL'ed code to /your/ code. The LGPL says that you must LGPL any code that includes the LGPL'ed code (such as a new version of the code, but excluding code that simply #include's the library's header files), and you must allow the end user to replace the LGPL'ed code in the working system. Thus the LGPL is really just about the LGPL'ed library code - but to give the end user their rights under the LGPL, you will have to provide object code if you statically link to the LGPL'ed code. >> There are products out there that ship under GPL and LGPL -- witness >> the older Linksys routers, which ran Linux and for which there is a >> web page with full source --> for the 'regular' Linux parts <-- >> available. >> LinkSys shipped routers whose code was almost entirely written by other people and mostly released under the GPL, and then tried to keep it all secret. It took quite a bit of legal pushing to make them realise that they were breaking the law by doing this (as well as shooting themselves in the foot - open source development for code like this has huge advantages). After that, they published the code. They were somewhat surprised to find that the more actively they supported the open development community around this code, the more people contributed back to the LinkSys base and the more they bought LinkSys hardware. I have bought perhaps a dozen LinkSys WRT54GL routers, all of which run OpenWRT - a Linux distribution that can trace its lineage back to LinkSys's release, and which has been actively supported by LinkSys. >> Granted, many companies aren't willing to include _anything_ that has >> a GPL or LGPL license, because they don't want to go to the trouble of >> sorting out what's what and publishing the "gotta publish" bits >> without publishing the "we want this a secret" bits. >> It not that complicated, if you follow simple rules. If you have an OS that can run separate binary applications, the OS and each application are considered separately. To use GPL'ed code, that application must be entirely GPL'ed. If you use LGPL'ed code in a dynamically linked library, it's license does not affect other code using that library. If you use LGPL'ed code statically linked, you should (L)GPL the rest of that application (this makes it much easier to follow the rules). If you have an OS that is statically linked with the applications, or no OS at all, then the whole lot must be GPL'ed if you use any GPL'ed code, and the whole lot /should/ be LGPL'ed if you use any LGPL'ed code (again, that's to make it easier). The (L)GPL does not affect any standard libraries or code that comes with the compiler, tools, or operating system, as long as such code is available to end users who want them (cost price is not an issue here). If you can't apply the (L)GPL to other code as required (say, if you have other third-party code that you can't relicense), then you can't use the GPL'ed code in your application. The result of these rules is that pure (L)GPL'ed code is seldom suitable for small and statically-linked systems. >> Change "legally" to "for most commercial purposes given today's >> corporate culture" and you'll be 100% correct. >> >> Were Jon willing to go to the trouble and pain _himself_, this would >> be a prime candidate for a dual licensing scheme. >> > Whoops -- reading other comments I'm reminded that the LGPL may 'poison' > the licensing of this code a bit more than I had thought. > I'm glad you corrected yourself here. These LGPL threads will be a lot easier when "heavyweights" like yourself understand the license. /I/ can post what I like, but people /believe/ the guy who wrote the book, so you'd better get it right! > What of licenses such as that for eCos or other open-source RTOS's? > Those also must be linked against, but have licenses that one hopes are > well thought out. > The licence for eCos and FreeRTOS basically says that the code provided in the OS is under the GPL, but with an exception that you can statically link your own code to the OS (and libraries) without it the (modified) GPL "spreading" to your own code.
From: David Brown on 7 Mar 2010 21:03 Jon Kirwan wrote: > On Mon, 08 Mar 2010 01:45:14 +0100, David Brown > <david.brown(a)hesbynett.removethisbit.no> wrote: > >> Jon Kirwan wrote: >>> On Sun, 07 Mar 2010 20:23:26 +0100, David Brown >>> <david.brown(a)hesbynett.removethisbit.no> wrote: >>> >>>> steve_schefter(a)hotmail.com wrote: >>>>> Hi David. >>>>> >>>>>> Why did you pick the LGPL? It basically means that people here can use >>>>>> your code in test code, but can't (legally) use it in any "production" code. >>>>> This isn't my impression of LGPL. Can I ask what leads you to that >>>>> conclusion? >>>>> >>>>> Steve >>>> To use LGPL'ed code with your own code, anyone receiving your code must >>>> have access to the LGPL'ed code, be able to change and recompile that >>>> code, then link it along with the rest of the binary and run that >>>> software instead. >>> In this case, though, the files stand alone. So all the code >>> is there and anyone is able to change and recompile it. >>> >>> I'm still confused, I suppose. >>> >>>> For non-embedded systems (or "big" embedded systems), >>>> that typically means the LGPL'ed code is part of a dynamic library. >>> But in this case, it's a stand alone set of files that can be >>> included into the project as another module. It is just what >>> it is, and no more than that. >>> >>> I'm still confused about what this means to small or large >>> systems or why it would make any difference. >>> >>>> To >>>> use LGPL code in a (typically statically linked) embedded system means >>>> that the end user will need access to your source code, or at least >>>> compiled and linkable object files. >>> But since I'm providing all of the source, they have all >>> that. Right? >>> >>>> Since that is impractical or >>>> impossible for most embedded systems, the rough conclusion is that pure >>>> LGPL code is very seldom suitable for embedded systems. >>> I wish I followed from your premises to your conclusion here. >>> This is where I'm stuck. I think I can almost understand >>> your earlier points -- maybe -- but if I do, your conclusion >>> doesn't follow from them. So I must not understand them. >>> Which means I still can't reach the conclusion. I feel dumb >>> about this, but there it is. >>> >>>> Of course, in some cases that is exactly what the code supplier is >>>> intending - the end user is able to use the code for evaluation and >>>> testing, and in non-commercial systems (and also for internal use), but >>>> for a commercial system they would get a separate license from the code >>>> supplier. That's a valid way of licensing code to developers. But I >>>> don't think that was Jon's intention here. >>> No, it's not. You are right on that point. >>> >>>> This has been covered endlessly in previous threads in this newsgroup - >>>> please let's not have another one unless someone has new points that >>>> were not covered recently. >>> yeah. And I still can't say I am better informed than >>> beforehand. Probably just me. But I can use some hand >>> holding from those who imagine they follow all this well. >>> >>> Jon >> At some point, you're going to get an "ah-ha" moment and wonder why you >> couldn't see it earlier... > > I am sure that is so. :) > >> The problem is not with your code - it is with other people's. >> >> Suppose I make a little wireless sensor that uses your hamming code as >> part of the software. I've got other modules for reading the sensor, >> making the obligatory LED blink, and so on. Since the hamming code is >> under the LGPL, I give the end user a copy of your hamming code (or a >> written offer, valid for three years, etc., etc., according to the >> LGPL). The end user finds a bug in the hamming code, and corrects it. >> He wants to use this new version in the sensor instead of the old one. >> The LGPL gives him the right to do this - I therefore have to pass him >> the source code, or at least linkable object files, for the rest of my >> code. Note only does he have the right to such code, along with >> whatever information is needed to be able to compile, link, download and >> run the new binary, but he is free to pass everything along to anyone else. > > Hmm. > > I had read this: > http://www.gnu.org/licenses/why-not-lgpl.html > It seems to actually recommend that I release it under the > GPL, not LGPL and says near the top, "using the Lesser GPL > permits use of the library in proprietary programs" which is > about what I want. > Please, don't read anything written by RMS unless you like deep philosophy. Great things have come from RMS and his dedication to free software, including the GPL, the gnu project, Linux as it is today, and endless pieces of software. But he is more than a touch fanatical, and takes an unmovable position that keeping any software closed or restricted in any way is morally wrong. That makes a lot of sense for a lot of software on PC's and servers, but is impractical and unreasonable for most embedded systems - RMS steadfastly refuses to see this issue. This is a shame - it would not take much effort to produce an ELGPL (Embedded Library GPL) that specifically allowed static linking with non-(EL)GPL'ed code, making it an ideal choice for code such as your hamming code library. An "official" GPL variant like that would encourage more open source in embedded development - perhaps not as "free" as RMS would like, but certainly more open and free than a lot of embedded code is today. > But I have to say reading the LGPL text didn't improve things > for me. > >> /Now/ do you see why embedded developers can't (in general) use LGPL'ed >> code, unless there is an explicit exception such as is used in eCOS and >> FreeRTOS licenses? > > Well, given your explanation of it, yes. Of course. > > Jon
From: David Brown on 7 Mar 2010 21:07 steve_schefter(a)hotmail.com wrote: > David Brown <david.br...(a)hesbynett.removethisbit.no> wrote: > >> To use LGPL'ed code with your own code, anyone receiving your code must >> have access to the LGPL'ed code, be able to change and recompile that >> code, then link it along with the rest of the binary and run that >> software instead. For non-embedded systems (or "big" embedded systems), >> that typically means the LGPL'ed code is part of a dynamic library. To >> use LGPL code in a (typically statically linked) embedded system means >> that the end user will need access to your source code, or at least >> compiled and linkable object files. Since that is impractical or >> impossible for most embedded systems, the rough conclusion is that pure >> LGPL code is very seldom suitable for embedded systems. > > Okay, thanks. I guess where we differ is in the opinion that > dynamically linked apps are not suitable for embedded systems. The > ones I work on (Linux-based) tend to use dynamically linked apps more > than statically linked ones. In the early days, I've even had to > force the apps to be dynamically linked to fit everything in flash > (several apps linked with the same library). > > Steve I try to be careful to make the distinction between small statically linked embedded systems, where the (L)GPL is almost useless, and "large OS" embedded systems with dynamic linking, which often have LGPL and GPL code. But I don't always manage to make it clear. So we don't actually differ in opinion at all. mvh., David
From: David Brown on 7 Mar 2010 21:13
Jon Kirwan wrote: > On Sun, 07 Mar 2010 15:12:28 -0800, I wrote: > >> On Sun, 07 Mar 2010 22:08:03 +0100, David Brown >> <david.brown(a)hesbynett.removethisbit.no> wrote: >>> <snip> >>> I'd go for a FreeRTOS-style modified GPL saying that the original >>> "library", and any changes made to it, must be released under the same >>> license, while other code linked to the "library" that only uses the >>> library's public interface is not bound by the license. eCOS has a >>> similar license: >>> >>> <http://ecos.sourceware.org/license-overview.html> >> Thanks, I'll look it over (and hope I understand it better >> than I did the LGPL.) > > Okay. I took a look. It really seems targeted squarely at > eCos. I'm not sure I can use it. Its circumstances are > quite different. They want modifications made to eCos to > benefit all, but they don't want to force people to release > their own application code that runs under it. This license > would seem to solve a problem for a situation that doesn't > apply to my case. It's more like the Apache license, > perhaps? > It depends on what you want people to do with your code. If someone modifies your code, do you want end users or others to be able to have access to those modifications? If so, you want a "copy-left" license such as eCos or other modified GPL style licenses. If you are happy for people to use your code as they want, including modifying it, insisting on nothing much more than that they retain your copyright notices, then you want a "non-copy-left" license, or BSD-style license, of which the Apache license is a good example. > Still struggling. > I always believe it is important to state your wishes for a license - make it clear to the code's users what you mean by the license, rather than just copying some existing legalise that is hard to follow. You must first decide what rights and obligations you want to attach to your code, before it is possible to pick (or modify) an existing license. |