Good point about the libraries. Library sources are needed because applications especially embedded applications need to have full application sources The library sources are available for essentially all compilers and in the embedded world most commercial vendors supply the library source with the releases of the tools.
Regards
Walter Banks Byte Craft Limited
In message , Walter Banks writes
That is not the problem....
The problem is that you have to make the object code of the app available to re-link to the open source library.
Making the object of the app available will be a non-starter for most commercial applications.
This is why you have to start looking at the libraries very carefully when you use a GCC compiler. Which is an overhead time wise and therefore cost wise.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
ion
Sorry - I wasn't clear enough; I'm referring to 2 related problems...
(1) The compiler is GCC, but the libraries are proprietary. We got bit by such an example recently; where we expected all the library sources we didn't get them. Replacing the proprietary library with newlib solved the problem. (2) The library is LGPL - no problem as long as you're happy to publish any fixes, right ?
Um, except when they omit critical pieces... Check carefully.
Thanks, Best Regards, Dave
That's nonsense - using FOSS tools is the only way to *prevent* someone shutting you out. If you don't believe me ask anyone who has bought in to any of the varied closed source tools and/or libraries later bought out by WindRiver and promptly dumpted leaving users completely helpless.
In fact, many people using FOSS tools and libraries do so precisely because they can control the version and capabilities independently of any supplier's wishes.
"Normal commercial restrictions of not pissing off your users" as demonstrated, for instance, by Microsoft ?
You are not starting a religion here are you ? One based upon a licence version no less !
-- Boo
I don't see why ? Why is that more risky than making an executable available ? (provided you strip the debug info first of course).
Well, choice of libraries is probably more important than choice of tools and the excellent support from GCC for such libraries as STL and Boost are one of the main reasons I heartily recommend it as a compiler.
It's a *cost* not an overhead. And the price is well worth paying given how much time you will save through the wise choice of libraries and the code portability that should result.
-- Boo
The real question here is about protecting IP. An application using most commercial compilers can retain all of its IP and use the supplied libraries for our compilers for example with no impact on the ownership of the application.
They can modify the libraries in ways that we don't need to know about and retain IP rights. The application code sources may be sold. The real point is the value of the application code may be several times the cost of the sources for the tools and I as a tool vendor have no claim on the application code or any part of it.
Taken to the extreme automotive engine controllers are programmed with distribution binaries and updates are programmed in the during dealer service. Dealers also install different versions of code to support driving conditions in different locations. This distribution meets FOSS binary distribution.
The IP in these binaries is worth many times the IP of a tool set.
Regards,
Walter.. __ Walter Banks Byte Craft Limited
Giving the object file to competitors is a problem in some cases, but is frequently not a problem in itself. After all, if it is possible to get the program out of the microcontroller, then competitors can get the object code anyway. I would expect that the majority of embedded designs are shipped in a way that allows access to reading the object code by determined competitors (jtag ports, software update systems, external flash, missing "lock" bits, etc., are all ways in).
Of course, it is a different matter being required by software license to distribute (when asked by the user) the object code in a linkable format, that the knowledgeable user can then relink with the LGPL code and run on the system. That varies between impossible, impractical and inconvenient for most embedded systems.
So I agree with you that LGPL is not a useful license for most embedded systems. However, the LGPL is not actually that common for libraries - especially not for libraries that are of typical use for smaller embedded systems.
For larger embedded systems, LGPL becomes more relevant - you might find code for larger libraries like video playback, file system support, bytecode interpreters, etc., under the LGPL. You should then use them in the way they were intended - dynamic linking at load time lets you write your own code under your own license, and use the LGPL libraries. You handle licensing, updates, code source access, etc., of the LGPL libraries in the same way as you handle it for any other software you run on the large system (such as a Linux kernel).
This is the problem... most FOSS/GCC haters have not actually read the licenses. They follow the mantras but not the legalese.
It does not *matter* what license is used for gcc and any other software running on the host computer, only for code that runs on the target! Is that *so* hard to understand? You can't use LGPL code on the *target* (without supplying source or linkable object code) - but gcc does not involve LGPL code for the target. The C support library in gcc (for things like floating point routines) very specifically states that target code generated by gcc may use the gcc runtime library without restrictions:
The glibc C standard library that is commonly found on, for example, Linux systems is LGPL and therefore unsuitable for most small statically linked embedded systems. However, since the library is huge, it is not be used on small embedded systems even when the LGPL license is not an issue.
Library sources are generally available with most commercial tools. But being "available" might mean they cost more. It is not uncommon (and not unreasonable) for cheaper or limited versions of tools to omit the source code for libraries - access to the library source code therefore requires and extra cost that must be taken into consideration. Being available if needed is, of course, more important than the cost of such access.
It may also be the case that you can view the source code, but not have the right to modify it or distribute modifications. Whether that is the case, and whether it is a problem or not, will of course depend on the tool and your requirements. But such issues are not clear-cut in the world of commercial software - you have to check them carefully. It's not like the world of open source software, where projects typically state the license on the front page, and you can quickly see your rights and obligations.
One thing that will always be the case with modifying (or even simply recompiling) libraries is that it will invalidate any sorts of qualifications, certifications and testing that applied to the library. If you have picked an expensive toolset partly because of their testing and certifications procedures, you will limit those benefits if you re-compile the library.
True but it would usually involve dismantling the equipment
Not usually. At least not without dismantling the equipment and often in a one way process.
Exactly.
Most embedded systems don't have dynamic linking and loading.
Linux is from the same license group. What if it is not GPL. LGPL SW etc. Several suppliers of source have in their licenses that you can not link it with any open source SW due to the requirements of the GPL licenses.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
No. That is what I assumed.
Yes. That is what I said.
Interesting points
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
No... They are usually supplied as standard.
Not seen that happen. Which compilers do that?
That is the same for any compiler.
True.... Though that is irrelevant as you cant get a validated Gcc anyway.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
With any toolchain (closed or open source), you can choose the library to use. It is certainly true that no commercial vendor is going to ship a library that restricts the licensing or distribution of the user's application code. I don't think it is fair to assume they will have the same attitude to use of the library source code (for example, can you take the library's "printf" source, modify it, and call it part of your source code?) - although clearly you'll know far more about that than me. But don't assume that every closed source vendor follows your own high standards of professionalism and customer-first attitude.
Most gcc distributions aimed at embedded systems have libraries with a similar freedom from IP restrictions. They are normally either BSD-style licenses, or "GPL with exceptions" precisely so that you can use them as you want in statically linked code with no requirements beyond something like a copyright notice or warranty disclaimer. If your tools don't come with such a library, you can generally switch to something like newlib (basically BSD license).
Some libraries /do/ require that changes to the library code are made available to others, although they pose no restrictions on your own code that links with it, and have no requirements that you provide linkable object code or anything else. This is typically MPL-style (Mozilla Public License) or GPL+exception licensing. Since most modifications to library source code are on the lines of simple bug fixes, this is not going to be an issue for many people - typically you want to pass that fix back to the maintainers of the library. An example of a "library" with this sort of license is FreeRTOS (though you can also buy a commercial license if you don't want to give people your bug fixes).
FOSS is not the right choice in all cases. There are some situations where open source is clearly the best, others where closed source is clearly the best. But for most projects the choice of tools, libraries and licenses is a balancing act between different requirements and desires. What's important is that people can make an informed decision based on rational technical and economic reasons, rather than irrational preconceptions such as "all closed source software is morally wrong" or "using open source forces you to give away your IP".
Only Open source people say that. There are many dozens of licenses. GPL is but one (group) The opposite of GPL is NOT "closed source" but the many dozens of other licenses a lot of which also provide the source.
The first (and only trump card the GPL people tend to parrot is "can I modify it and give it away? " Well the answer is YES in *some* cases. However in all non-GPL cases where the question is "do I have to make my source and object code available the answer is "no"
It is only the GPL Open source people who try and turn it in to black and white, good ad evil. (Somewhat of an American trait with arguments).
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
If you are thinking about competitors who want to copy your software, I don't think the need to dismantle the equipment is going to be a big issue.
Note that I am talking about the majority of /designs/, not in terms of quantity of systems shipped. Large volume systems will typically have much better protection against copying. But for most small volume systems (and most designs are for fairly small volumes), things like convenient software updates, and the ability to do development and debugging on the production model outweigh the tiny risks of someone copying the software.
See, we can agree!
Yes, but most embedded systems don't need such "large" libraries. In systems which /do/ need that kind of code, dynamic loading and linking is often possible (embedded Linux is a clear example, but it's not the only one).
There are many mutually incompatible licenses. Suppliers have attempted (I say "attempted", because I don't know the legal validity of such license requirements) to impose all sorts of restrictions on how their software is used. The GPL has very clear restrictions on how you use GPL'ed source code - other code that is linked directly to it (statically or dynamically) must be under a GPL-compatible license unless it is part of the OS or tool's standard libraries.
If some suppliers specifically state in their licenses that you cannot link their software with GPL'ed code, then that is an additional restriction in their licenses - it is meaningless to say it is because of GPL requirements. Any GPL requirements are an issue for using the GPL'ed code, not this other supplier's code.
No, you said "Which makes GCC unusable for most embedded system". My point is that the license used by gcc itself, and any libraries that are used by the compiler, is irrelevant to the license you use for your target code. Similarly, the license for common large system libraries (like glibc on Linux or other systems) is irrelevant to target systems that don't use those libraries, even if they are commonly associated with gcc. It is only the license of libraries used on the target that need to be considered. If you are happy agreeing with that, we can move on.
If you want me (or others) to expand on points of interest, just ask.
There is no "opposite of GPL" - who is trying to turn it into a black and white issue now?
You are certainly correct in that there is a difference between the "free software" advocates and "open source development" advocates.
The first group emphasise the philosophy that it is important that software is "free", meaning that people have the right to use, modify and distribute the source code and any changes they have made. They see the GPL as a way to ensure that software remains free, and anything "less" than the GPL is a compromise at best.
"Open source development advocates" are more interested in the pragmatic than the philosophical. They believe that an open development model in which people can view and contribute to the software, and re-use the source in other open source projects, is a more effective and efficient way to develop higher quality software. They see different licenses as useful for different purposes - sometimes the GPL is the best choice, sometimes other OSS licenses make more sense. But it is a practical decision, not a moral one.
Like most (I believe) people, I see advantages and disadvantages in both free and non-free software, and in open and closed development. There are types of software where one model works much better than another, and types where different models or compromises works best.
There are fanatics at either end of this scale (to the extent that it is a scale), with rabid "all software should be free" preachers like RMS, and rabid "FOSS is communism and the GPL is cancer" preachers like Steve Balmer. Instead of blindly following either rhetoric, one should try to understand the issues and the choices, and see what makes most sense for what /you/ want to do.
That's a gross oversimplification, and is simply not true - again, /you/ are making it black and white, or GPL and non-GPL. There are lots of non-GPL licenses that require you to "give away" your modifications in some circumstances, and circumstances in which the GPL do /not/ require you to "give away" your modifications.
You are in real danger of doing this yourself at times, and should be more open to alternatives. It is perfectly reasonable to promote non-gcc compilers for being technically superior, cheaper over all, or for other technical or economic reasons (though you'll get arguments there too, of course :-). It is also perfectly reasonable to discuss the pros and cons of licenses for tools, libraries and source code. But do so with an understanding of the licenses involved, and what they cover, and how relevant they actually are. And do so understanding the pros as well as the cons of the licenses. Anything else is just FUD.
As for making things black-and-white, remember what happened to Darth Vader. (This is a quote from some website.)
Yet in the climactic scene of the new "Revenge of the Sith," the evil Darth Vader warns his former master: "If you're not with me, you're my enemy."
Obi-Wan Kenobi replies, "Only a Sith deals in absolutes".
CodeWarrior does not have all the library source code in all their versions. But at the moment I am using their zero-cost "special" edition, and I don't know if the library source code comes with all their paid-for editions. As I say, I don't think it is at all unreasonable for the library source to be omitted.
Other than that one example, I have certainly used toolsets without library source in the past. But if you look through the development toolkits that you sell, and are confident that the entire library source code is provided with all versions of the tools, then I'll be happy to accept your word that this is standard practice. After all, you have easy access to the licensing details of far more tools than I have used.
Absolutely true.
I believe you /can/ get validated gcc toolchains, but it is certainly very uncommon. But validation and certifications are certainly a selling point of some commercial toolkits, and re-compiling the library nullifies that point. I doubt if it is something that concerns most people, but it is just one more thing to consider when deciding what you need in a toolchain.
Hi all,
Raisonance
My .02$, Bruno
sthe
e a
In message , David Brown writes
Yes
I agree and that includes the GPL licenses.
-- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
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.