wrong, the FSF provides tools to the coders, it's more like providing weapons to the poorer side of a war... which is not popular.
The GPL is not appreciated by a lot of people because... well, it gives the developers the means to unite in a way, and defend themselves. Nobody is "forced" but there is a choice, a bit more freedom.
Then, between the plan and its implementation, there are probably a lot of... glitches. So don't get impressed by David : read RMS's "writings" and make your *own* opinion (and yes, RMS is stubborn, but it does make him malevolent).
Hehe. I wish I knew. I don't want them suing _me_. That's one thing for sure, though.
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."
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.
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.
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.
I like _Error-Correcting Codes_ by W Wesley Peterson. No doubt out of date. But, requires a considerable math background to truly appreciate much of what is covered (field theory, etc.). And, you won't find any code snippets within. :< But, if you understand the math behind the theory, you can usually roll your own implementation fairly easily.
I will try to chase down a copy of Blahut just to see how it feels.
I was thinking about the copy-left, itself, and that it does have _legal_ force to it. It clearly must. Maybe I didn't write what I meant so well.
More options is always better.
I've read some of his writings and enjoyed them. I think his mission is "big," but I generally support and like what it has managed to carve out for itself. I would have no problem contributing, as well.
I think the reasons many (most?) embedded systems shy away from "shared objects" are twofold: resources and tools.
Small (< 1MB TEXT+DATA) systems tend to feel like they don't have the resources to spare on the dynamic binding (I think this is usually silly-talk but the folks building those systems are the ones who have the final say :> ). Personally, I find the overhead to be small and the discipline associated with developing with s.o.'s makes it a *big* win "almost always".
The other reason is often poor tools. E.g., you aren't going to find (?) an 8051 compiler/linkage editor that will support this sort of thing. So, to do it, you (the developer) have to build your own tools (this isn't very hard but *is* another step and something *you* have to support -- not the tool vendor).
I think if more folks were accustomed to this sort of run-time environment, they might be more willing to add it to their toolkit (e.g., just like adding PMMU support)
"Modest," for me, is 512 flash and 16 RAM. "Small" would be half that. "Decent" and kind of roomy is anything like 4k flash and 512 RAM. "Unbelievably big" is 40k flash and 4k RAM.
Anywhere _near_ 1Mb of anything is called "monstrously huge," or is just a "workstation" and has way way too many pins or is way too expensive or is way too power hungry or has way too many extras to worry about. Probably all of those.
My operating system, which supports pre-emption or cooperative tasking (either), and messages and sleep and semaphore queues and so on can live with singly-linked lists (everything is compile-time selectable, so you can remove what you don't want or add what you do) for the queues. It adds a little extra code and certainly some small execution time, but sometimes you want that because RAM is scarse. I can shovel it into very small devices. But the nice thing is that when I have the RAM for doubly-linked lists, it's just a change to a #define and then a recompile. Or if I want to support a lot of processes, etc. It's all compile-time stuff.
Well, if you consider The other reason is often poor tools. E.g., you aren't going to
I've had to develop my own linkers before. Twice, at least. It happens. You just don't want to make it happen if you can avoid it.
Not sure what to say to that. I understand some of the context, but not all of it, I suspect.
I liked this comment from RMS in a 2006 barcelona transcript: "In other cases, it's because the licence is so permissive that to relicense it under the GNU GPL is permitted." That would seem to make sense for me. Such a permissive license that others could modify it and then relicense that combined product under the GPL. I've no problem there, either.
See? I'm beginning to know more of what I want. But I still don't know all of what I'd like, as I am obviously just discovering more and more as I read. Nor do I know how to write it up. Oh, well.
says the same, but it says, that e.g. Richard Stallman does not interpret the LGPL in this way, so you are safe, if you ask the copyright holder of the library, before you do such things.
--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ah, that;s good to know. I inherited it MANY years ago and have found it answers most questions I ask of it. (though the typesetting is REALLY hard on the eyes! :< )
Yup. I find most of the folks who buy books with code are looking for "a routine that does....". If they can't find exactly what they need, the book is often worthless.
Ah, thanks! I will add that to my list as well.
I'm assuming your endorsement means the books are
*relatively* free of errors? (often highly technical books are proofread poorly)
Yeah, been there. Done that. Have the cramped up hands to prove it! :>
We designed a LORAN-C (precursor to GPS) plotter with 256 (or maybe it was 512?) bytes of RAM. When you consider it had to navigate anywhere around the world, take into account things like the oblateness of the globe, operate in real-time, etc. it was amazing how everything fit! I think our floats were each 6 bytes (kinda hard to do all that trig and hyperbolic math with ints!) so you can imagine how *few* of those we had!
Nowadays, 1M is almost as low power as some of the 4 and 8b machines I grew up with. My network audio client falls in this category -- mainly because of the data requirements (though the network stack is also a pig). OS is nice and lean :>
I have a really tiny, fast MTOS (doesn't do real-time guarantees -- though you can apply it to RT designs if you exercise discipline) that is a few hundred bytes (timers, etc.). It can do a context switch in ~1us on a small processor. I actually use it *inside* interrupt routines on some machines because it is *that* fast.
I span almost the entire gamut of application environments. I don't often write for the desktop, though. I think it is also a bad practice. Sort of like driving with two feet...
Nowadays, with FLASH based systems, it becomes increasingly more common to swap in bits of your application "as needed". (i.e. serial FLASH). With dynamic linking (late binding) this is a piece of cake! Load the code into RAM, make all the bindings (unresolved externals) to the "resident code", then "run". When done, throw it away and load whatever the next part of the application needs to be.
How about "Written by Jon Kirwan 2010. This file is hereby released into the public domain" ?
Otherwise, perhaps the "BSD style" license as used by other embedded-controller oriented free projects. Based on the one I just found in in avr-libc:
Copyright (c) 2010 Jon Kirwan
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of the copyright holders nor the names of contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
I have read the licenses and their intentions, faqs, and various opinion pieces by RMS.
Don't get me wrong here - I am not anti-RMS, or anti-GPL or anything of the sort. I have a lot of respect for the man, and am very grateful for the work he has done. I am glad he believes what he believes, and is so dedicated to working for those ideals.
However, that doesn't mean that I personally agree with everything he stands for. I believe there is a place for closed source software as well as open source software.
And I think it is fair to point out to people that RMS /is/ fanatical, and you have to understand that when reading his articles. He doesn't compromise well, and he is not normally interested in giving a balanced argument. So if you look in his writings, hoping to learn how to mix your closed source code with other people's free source code, you'll be told that it is wrong to try to mix it, and you should open up your own code.
RMS can be likened to the Green party in politics. I'm very glad they are there, shouting loudly when necessary and keeping other parties a little more honest. But I wouldn't want them running the country.
It is certainly true that the eGPL does not have to come from RMS, and that you, me, or others here could write it. But at best it would be jut another variant on the GPL. We are neither lawyers, nor industry heavyweights, and it is unlikely that our eGPL would be used by others. I suppose that doesn't matter, however, and it might be interesting to try.
I read the thread linked above - it says pretty much the same as I have said, as far as I can see.
The particular paragraph you refer to is:
"However, others (in particular, Richard Stallman) does not necessarily interpret the LGPL in this way. I strongly recommend you contact the copyright holder prior to building a statically linked application for distribution as a commercial product."
This suggests that the library copyright owner may be more flexible than the wording of the LGPL, and that you can contact them for specific permission to statically link the LGPL code with other code without having to provide end users with your object code. That is always applicable - copyright owners are always able to give specific permission.
It also suggests that RMS has a different interpretation - but does not indicate /how/ he interprets it. My guess is that he would say that statically linking to LGPL code requires that your code be LGPL - i.e., that you must release your source code as well as your object code. It seems unlikely that he would allow people greater flexibility in keeping their source code and object files secret.
It's not what the LGPL requires, but it is an easy way to be sure you are compliant. You can certainly keep your code more secret and still link statically to LGPL code, as I've said elsewhere, but I'm trying to give easy-to-follow guidelines here, not minimal rules (for that you can always read the LGPL and ask a lawyer...)
That wasn't my term.
Agreed.
That's the essence of the eCos and FreeRTOS licenses, and would (I think) be a very reasonable choice of license for the code.
It looks like Jon's intentions are a bit looser than that - he does not want to require people to make their changes available to others, or to require that the pass on the source code to other users. That suggests a simple BSD license is what he wants.
I know well that RMS does miss the neuron for crompo... pronco... whatever.
however, his lesson is simple : the US copyright law and international treaties provide the authors of original works, including *us*, the right to choose the terms and conditions of the spread of our works. RMS implemented "copyleft" for his agenda, great, particularly considering the fact that he's basicly a math geek, not a lawyer. But he understood that the law is not here just to make our life more tedious.
The point I want to make is : We don't have to write the GPL. Simply writing honnestly and clearly what we want, how and why is already the beginning of a licence. And it's has much better chances to be read by the end users than M$'s EULA.
Now, sure, there is the risk of licence dillution, fragmentation etc. But we are the authors and have the final right to decide what and how it is distributed. There is no law that forbids writing new licences.
So go on and write us a draft for eGPL, i'll be glad to help a bit :-)
However, yg's approach is kind of interesting in its own right. It certainly lets folks use the source code by writing their own short module files and including what I wrote into them. Has its uses.
Here's a more flexible example than I posted up before:
formatting link
There is only hamming.c, hamming.h, and a test program now. Very simple.
seems so, nice code, but please, if you can, put the files in a subdirectory so there is no need to sort them after they are uncompressed in a crowded directory :-)
also, may I suggest that the "auto" keywords can also be #define'd out ?
About the size of the C data types on various C platforms, I developed these files a few years ago and tested on many machines (servers, desktop, embedded, even a Cray ;-D)
formatting link
formatting link
formatting link
Some more useful routines :
formatting link
formatting link
OK, I know, the comments are in french, I wrote them for a french magazine but they are easy to understand.
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.