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: Jon Kirwan on 7 Mar 2010 21:33 On Mon, 08 Mar 2010 03:03:55 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >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. Sometimes, it takes that to move mountains. >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. Through my foggy glasses, I've seem motion from the early days that seem to demonstrate that RMS does "see" the issue. It's more that he doesn't buy the whole deal, but has made some small accomodations over time. >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. Yes, I agree. I'd like it if Stallman's attorneys came up with something like that. However, I know why they don't. It's because they have a clear mission to oppose restrictions on users imposed by software developers. Your own comments about Linksys argues well in favor of that mission, I think. They don't see why they should write something that doesn't move one inch in that direction. Of course, that's not MY mission. I like the fact that they exist and their mission is clear and has a good purpose. But my own interest, when I have much of one at all, is really just to help out a little bit here and there. To achieve software freedom in RMS' sense, they have to use force on _developers_ (not users) to fight the proprietary developers' forces. Which is why the licenses exist, I gather. But maybe as the 'stone soup' improves, it becomes less a matter of arm-twisting and more a matter of voluntary cooperation as all boats may be lifted somewhat together by the result. I don't imagine such grand ideas, myself, and seek humbler ones. >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. ><snip> Oh, cripes. RMS _hates_ being associated with "open source," which he sees as confusing their own message and making them less effective in their efforts. So I've read him say, anyway. Jon
From: D Yuniskis on 7 Mar 2010 22:00 Frank Buss wrote: > Jon Kirwan wrote: > >> Partly, I think, because I'm not yet even sure what I want. > > That's the first thing you have to solve :-) > > Maybe a short explanation can help: LGPL allows other developers to build a > library from your source code and this library can be used in closed source > programs, but the library source and all changes to the library has to be > made public. If it is GPL, anything which uses it has to be public and GPL, > too. I think the LGPL also requires that the balance of your code maintain the "linkability" with a drop in replacement for the LGPL'd code? > For most public projects, I prefer the BSD license: Do whatever you want > with it, but add some credits of the original author to your documentation. Agreed. "If I didn't want you to have it, then why did I disclose it?"
From: D Yuniskis on 7 Mar 2010 22:07 Jon Kirwan wrote: > On Sun, 7 Mar 2010 20:45:21 +0100, Frank Buss > <fb(a)frank-buss.de> wrote: > >> Jon Kirwan wrote: >> >>> So what does this mean? If I put out some routines that get >>> directly linked into the code as a separate project file >>> within a project, it's not really part of a "library" per se >>> but really part of the project as a whole, just like any >>> other module file may be. Does this mean the entire project >>> must be disclosed? If not, why not? >> I'm not a lawyer, but I think the idea is that the library has to be >> provided as some dynamic link library, > > By "dynamic link library" do you mean this in the way that > Windows used it -- something loaded by the operating system > as a separate file of routines without its own stack, but > accessible to a calling program? If so, that pretty much > excludes all embedded systems I work on. DLL's are called different things in different worlds. Basically, "binding" (to the symbols exported by the 'DLL') is deferred until run/load time (whereas when you static link, all of these bindings happen at "compile"/link time). A DLL can be replaced WITHOUT altering the "main program" (I am playing fast and loose with terminology here). So, you can distribute your "binary" and I can replace the 'DLL' with something functionally equivalent and your program (your binary + this DLL) will still operate correctly. In some (paranoid) circles, this is viewed as leaving your \ program open to (easy) reverse engineering -- since it exposes all of the calls *into* that/those DLLs. And, provides a controlled means for a modified DLL to peek back *into* your running program (big deal... a good debugger can do this anyway) <shrug> Regardless, it is still an "encumbrance". Something "extra" that you have to do for the privilege of using the LGPL'd code. >> so in theory the user can replace it >> easily. > > Well, that would certainly be true for DLLs under Windows if > the user had all the necessary source code required to > regenerate the DLL (or VxD, I suppose.) That DLL is the LGPL'd code that you are *using* -- so, they *do* have "all the necessary source code required". That's the whole point. :> >> Linking staticly to a program is not allowed with LGPL > > Somehow, although I've seen that discussed here, I simply > have missed this in reading the license. But it is probably > because I'm confused. > >> (I think >> then the resulting program is GPL'ed). E.g. that's one reason why Qt is >> provided as LGPL and as a commercial license: With the LPGL license you >> have to deploy DLLs, the commercial license allows you to link all in one >> executable-file. For details read the LGPL text, but maybe you'll need a >> lawyer to understand it. > > Yeah. I tried to read it more carefully today and I'm still > not "getting it."
From: Jon Kirwan on 7 Mar 2010 22:17 On Mon, 08 Mar 2010 03:13:14 +0100, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: >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. Hehe. I wish I knew. I don't want them suing _me_. That's one thing for sure, though. >If someone >modifies your code, do you want end users or others to be able to have >access to those modifications? If someone donates their own time to modify them and make the resulting code available to others, I'm fine with that. if they choose not to, I'm probably fine with that, too. I am assuming by "end users" you mean "we programmer types." >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. The Apache license 'looked good' to me, except that it also (like eCos) is targeted at their specific situation. They want Apache modifications, if used in an implementation that has public exposure, to be made available (as I gather it.) But once again, my situation isn't straddling between an operating system or complex environment of common tools and someone's PHP code or cgi scripts running on it. Or binary tools developed to run under it. It's just your basic "here's my code and welcome to it" with the caveat that I don't want to be bothered over it for any reason I don't choose. >> 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. Well, there is a point. Except that wiser heads than mine are worth reading from, I imagine. They have more experience in the "real world" than I do and perhaps it is wise to rely more upon their crafted advice and my vague meanderings. >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. Well, it's probably like most folks who just want to occasionally put out some small bit in the hopes it may help one or two others from time to time and to not have to deal with mean-spirited types if they don't want to. Jon
From: whygee on 7 Mar 2010 21:54
David Brown wrote: > The LGPL says that you must LGPL any code that includes the LGPL'ed code ??? where is it written in the original texts ? > It not that complicated, if you follow simple rules. well, these are the rules as you have understood them. > 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). note the "should", not "must" : this is easier for you, but not what the LGPL intends. > 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). (same remark as above) >> Whoops -- reading other comments I'm reminded that the LGPL may >> 'poison' the licensing of this code a bit more than I had thought. why use the term "poison" ? a poison is a poison, it's bad, that's all. Codes that come under (L)GPL have some advantages, they are a bit picky, that's all. > 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! let's simply ask RMS... just to see how he replies :-) > 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. So following this idea, Jon can add a licence notice that : " this code is released under LGPL, with the exception that you can #include these source files in whatever code you develop" It should be ok, i've seen it done already for other cases. I'm using Affero GPL for a project, which is just GPL with an additional section about networked code. yg -- http://ygdes.com / http://yasep.org |