Extended Hamming encode/decode

Agreed. I hate this stuff. It should be easier than it has become. I don't like not understanding the legal ramifications, but I don't.

I think I'll re-release it when I figure out how.

Thanks, I'll look it over (and hope I understand it better than I did the LGPL.)

Yeah. The old way of doing things.

I'll hope to hear from others on this topic, rather than just jumping forward and either accepting or rejecting this argument. I have my habits and, for now, I can afford to keep them. But you've put me on notice.

If I agreed. But that jury is still out. For now, I'll leave it as is. Others will, of course, be free to do as they please. But you aren't talking about "this code" but about my future writing style, David. And that is a lot bigger issue than just this case and involves a profound change of earlier habits, as well. It warrants more thought and some research and probably some listening to others.

Ah. Back to templates and c++.

As I mentioned already, had I been writing in c++ I would have used templates. And your arguments would carry more weight, I think.

Regardless of your writing here that I should consider c++ when writing c, in this case it is so much better to use templates if using c++ that I just don't imagine the code I'm writing here will ever find much purchase in c++. It's just so much better as templated code that most anyone would rush to that point and not use what I wrote, except as at most some guide or test comparison.

See above comments.

I'm still on C90 for almost everything I do. And I can absolutely assure you, right here and now, that I will _not_ write code that requires C99 compliance even when writing c. Not yet, anyway. Perhaps when C99 becomes more widely supported. Writing for C90 means it will work in C99. Writing for C99 does NOT mean it will work with a C90 compiler.

Well, you have my answer to that. Someone else's job, if they want it. C90 remains the "portable" standard for me for embedded use. Not C99. Not c++.

Well, we will simply have to leave this unresolved between us, then. I can follow your argument, but I don't embrace it.

hehe. It's not. But... that means I then need to provide that and they need to stuff it into the right directory (if I use instead of "".) More work.

However, this discussion has convinced me to remove hamm_def.h completely. It's really more of an annoyance than a help and I think you've convinced me of that much. New code is reposted, already.

... Oh, well.

No, C90 is the best. C99 isn't always there.

I use gcc only rarely in my applications.

No, C90.

hehe. What would you consider to be pretty?

Hmm. okay. I changed that. More ugliness, but what the heck. __HAMM_CHECK_T is used throughout, now. ;)

Oh, something like this:

#if sizeof( __HAMM_VALUE_T ) == 2

might be useful. There is code that is either needed, or not needed, depending on the word size. It would be nice to modify code depending upon the number of check bits required and the size of the data word.

That's all.

:) I'm still back on C90.

I've enjoyed this and you've made me think a little and change a few things in the process. Plus, I'm still hoping to learn something about various licenses, too.

So all to the good, I think. I'm very glad you took me to task. It's improved things, already. (I also found a bug caused by some last second changes I'd made for silly efficiency reasons and I owe you for that.)

Jon

Reply to
Jon Kirwan
Loading thread data ...

But that *is* Hamming.

VLV

Reply to
Vladimir Vassilevsky

Okay. Of course. I guess I meant as separate from reed solomon and gegenbauer. Which is why I mentioned the dates you removed from my post in replying.

Jon

Reply to
Jon Kirwan

At some point, you're going to get an "ah-ha" moment and wonder why you couldn't see it earlier...

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.

/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?

mvh.,

David

Reply to
David Brown

Huh? Reed-Solomons are nonbinary; as for Gegenbauer, he is from different bookshelf :)))

VLV

Reply to
Vladimir Vassilevsky

formatting link

Jon

Reply to
Jon Kirwan

It doesn't /have/ to be a dynamic library, but that's the typical case.

Yes, that's what he means by "dynamic library" - DLL for windows, .so shared library in Linux, etc.

There is no requirement in the LGPL that replacement should be /easy/, just that it is possible.

Static linking is allowed, but it's not straightforward to be compliant while linking statically - dynamic linking makes it much easier. With static linking, you have to supply linkable object files along with any other files or instructions needed for the end user to be able to re-compile the LGPL'ed files and re-link with the rest of your object files.

Reply to
David Brown

code.

I am sure that is so. :)

Hmm.

I had read this:

formatting link
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.

But I have to say reading the LGPL text didn't improve things for me.

Well, given your explanation of it, yes. Of course.

Jon

Reply to
Jon Kirwan

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?

Still struggling.

Jon

Reply to
Jon Kirwan

,

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

Reply to
steve_schefter

Write the way that is most comfortable for you. Just be

*consistent*. I've honed my writing style over the past 30 years to something that works well for me, is easy for others to understand, and works with *every* toolchain I've ever had to use. Change? Why?? :>

Agreed. I think this is also the case in much of the "open software" community -- folks doing things in whatever way is "best for them" and not necessarily "best" or "best for others". After all,

*they* are solving *their* problem and being kind enough to share their solution with "others" -- what right do those others have to define *how* they go about this task? :>

Agreed. Too often, there *is* a need to back-port things. If you make it harder to do so, then you condemn old designs to languish when they could, otherwise, benefit from "new work".

I have a little C interpreter that I wrote back in the 80's. It runs in *old* single-chip devices. It's really nice to be able to take a code fragment and move it into that environment without having to make silly, time wasting syntactic changes *just* to get it to run in that "old context".

And, I haven't seen any newly released compilers for Z180's,

6809's, 8x300's, etc. "Sure, I can make those changes to that old codebase for you -- but, you'll have to find someone who makes a more modern compiler for that processor because I *really* like using // comments..."

Agreed.

Be careful -- sizeof isn't "valid" in preprocessor context! (though many compilers will "do the expected thing" here)

Because char is a misnomer. It should have been called "small" or something else (byte). There is a difference between how char, signed char and unsigned char behave. And, sometimes a cost to using one variant over another (in terms of code generation)

Because you are assuming "char" is an abbreviation of "character". typedef it to "small" and then, suddenly, there *is* some sense to having signed and unsigned "smalls".

I opt for a BSD license on most things that *I* own and release. If I didn't want others to use it, then why would I release it? And, why would I want to impose other conditions on the rest of the code? If you use it, fine. Don't be alarmed if one of your competitors ALSO uses it, etc.

Reply to
D Yuniskis

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.

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.

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.

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!

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.

Reply to
David Brown

code.

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.

Reply to
David Brown

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

Reply to
David Brown

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.

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.

Reply to
David Brown

code.

Sometimes, it takes that to move mountains.

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.

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.

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

Reply to
Jon Kirwan

??? where is it written in the original texts ?

well, these are the rules as you have understood them.

note the "should", not "must" : this is easier for you, but not what the LGPL intends.

(same remark as above)

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.

let's simply ask RMS... just to see how he replies :-)

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
Reply to
whygee

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?

Agreed. "If I didn't want you to have it, then why did I disclose it?"

Reply to
D Yuniskis

ok, so why read the licences and their intents at all ? let's just put a (c) at the top of each file and ... whatever happens happens...

why don't you start this effort ? look at the affero GPL : it's a similar derivation and idea.

formatting link
what is great with freedom is it's even better when you can use it, along with the tools developped for it. RMS has his own windmill, and you bark at another pole... but you CAN affect things, the GPL is one choice among others.

I salute Jon's ideas of thinking about, and using the LGPL, even though there may be reasons not to do it. But 1) he wrote the code 2) releases it openly 3) listen to other's comments. If in the end 4) eGPL is written, then that would be even better. It's not my pole but i'll help you bark if you want.

just. do. it.

it's not about RMS.

yg

--
http://ygdes.com / http://yasep.org
Reply to
whygee

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)

Regardless, it is still an "encumbrance". Something "extra" that you have to do for the privilege of using the LGPL'd code.

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. :>
Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.