[ECOS] A basic question regarding [eCos] performance figures

Alex Schuilenburg alexs@ecoscentric.com
Fri Oct 15 13:44:00 GMT 2004


Andrew Lunn wrote:
> On Thu, Oct 14, 2004 at 11:55:30PM -0700, sandeep wrote:
> 
>>>Now porting eCos to a new platform you need to write
>>>a HAL. Basically all HALs are very similar. To write
>>
>>>a HAL you copy the most similar HAL and modify it to
>>
>>>your needs. Doing this you have used GPL code, so
>>>your new HAL has to be distributed under GPL.
>>
>>If i understand it a little, this means by default you
>>don't have to give out the sources in this case, but
>>if customer asks you have to, else every new hal port
>>by ecos maintainers would need to be available to
>>public, if they also practice same for new hals rather
>>than writing from scratch everytime. reasons for this
>>arise from a quoted reply, further in this post.
>>please correct my misunderstandings.
> 
> 
> You should read the GPL FAQ. http://www.gnu.org/licenses/gpl-faq.html
> 
> You have to make the GPL source avaulable to the customer. You can
> simply ship them on the CD with the binaries, put them up on a web
> site, or include a note saying they are available on request etc.  The
> FAQ tells you all about this. The GPL only requires you to give it to
> the customer. You do not have to make it publicly available.

Just to expand further on this, your customer also has to make it 
available to their customers. Whomever receives the end product has the 
right to receive the GPL'ed source. This is why it is best to contribute 
publically if you or yor customer do not have the time nor inclination 
to provide the sources yourself. You can simply point them to an anoncvs 
snapshot. Otherwise you have to set up the whole infrastructure to be 
able to provide sources on request.

The intent here, when we changed the license to its current form, was to 
"encourage" developers to contribute bug fixes and enhancements of eCos 
back to the community. After all, somebody wrote initially wrote eCos, 
somebody wrote the HAL for the development board you based your custom 
hardware on, somebody ported the BSD TCPIP and PPP stacks, somebody 
added the flash layer and driver support, somebody added the SPI layer, 
and so on. You are building your product from code that cost somebody 
else time and money to develop.

As Andrew explains further down his email though, the vast majority of 
the code should be your application anyway, which is proprietary. That 
is your IP and that is what is protected.

In practice we have never found two competitors developing eCos for 
exactly the same hardware. Everyone has their own preferred supplier of 
CPU, flash components, etc etc. In addition, the electronics consumer 
industry is so competitive, with the lifespan of the products so short 
nowaydays, that by the time your competitor could call on the GPL to 
extract your GPL-derived HAL sources from you, they have already lost 
any advantage they could gain from them.  You either have already 
captured the market or moved onto a superior or cheaper product. Plus 
they still have to develop the application, which is where all your IP 
should lie anyway.

-- Alex


>  
> 
>>can customer distribute/share this obtained source
>>code with rest of the world?? i.e. i bought a piece of
>>hardware for which eCos port was available, binaries
>>were given to me by vendor, i asked for sources and
>>those wer given to me (GPL stuff), though those were
>>not available in public repository for whatsoever
>>commercial reasons. can i share this code with world
>>w/o getting into any hassles with vendor?
> 
> 
> Yes, the GPL allows you as an end customer to ask for the sources and
> you can do what you like with them within the restrictions of the GPL.
> ie you can make them public.
> 
> 
>>>I doubt there is enought information in the eCos
>>>Porting guide to writing a HAL without looking at
>>>other HALs. So in practice you will probably first 
>>>have to spend a long time actually documenting what
>>
>>a 
>>
>>>HAL does, so that you can do a clean room
>>>implementation.
>>
>>Whatever little i understand of eCos, to summarise,
>>non-hal code expects certain functionalities from hal
>>accessible via  predefined
>>macro/function/variable/configuration names. it is
>>quite possible, as discussed in one of the recent
>>threads, a rewrite (writing from scratch) could be
>>very much similar/same to the original, also a writing
>>from scratch could end very much similar to some
>>similar platform, because of the conventions to be
>>followed and similarity in platforms.
> 
> 
> True. Whats where it gets tricky and you need the input from a
> copyright lawyer, which i am not....
> 
> 
>>if you take a similar hal code and modify it to suit
>>your needs, this is modification. but what if someone
>>opens existing similar platform's hal in one window,
>>while all the time completely referring to it - but
>>not  using original source files for modification -
>>keying all manually. can (and if yes, how?) GPL laws
>>pin such cases.
> 
> 
> We are talking about Intulectual Property here. It not the lines of
> source that matter, its the concepts they express. If you copy the
> concepts, you have derived your code from GPL code so it needs a GPL
> license.
>  
> 
>>moresoever if some company is closed source, they have
>>derived from open-source GPL code. but since nobody
>>gets to see the source, nobody knows about it. In what
>>ways GPL tackles this situation.
> 
> 
> You can often tell from the functionality. eg there is only one
> implementation of Readline. Busybox is very easy to identify. These
> are common bits of code that manufactures get into trouble with.  If
> you were to give me an image which might be eCos, i could probably
> identify it by disassembling the startup code etc. JFFS2 would be easy
> to detect by looking at the filesystem layout.
>  
> 
>>on similar note, I wonder how interests of community
>>are protected - when as an individual i give out some
>>some product on an opensource related site (i didn't
>>care to put GPL and other clauses in that, just made
>>available to public, when i was on it). for some
>>reasons this didn't pickup much. some company, in
>>future, happens to find out some good algorithm/logic
>>in that, more or less unused now work, and uses that
>>in some work, patents that logic. will it be an issue
>>for someone else, who happens to use the same logic
>>from that work of mine? 
> 
> 
> If it has been on a public site, it would be classed as prior art. So
> using this you could in theory get the patent overturned. Patents are
> stupid for software. There has been lots of discussion about this
> recently.
> 
> 
>>than fix those. To be able to fix a bug, first you
>>have to know it. Both of us develop an application
>>around our copies of hal. application is closed source
>>(we are giving binaries). but for evident reasons,
>>your application turns out to be more stable and
>>sturdy (reasons could also be that you are a better
>>crookedness.
>>
>>we share some hal that is openly available, you happen
>>to find some crucial bugs in that and some other
>>related issues affecting the execution, for which you
>>do correct fixes and workarounds. I sometimes notice
>>some weird behaviours in code, but I don't understand
>>them and do random things to patch/hide bugs rather
>>than fix those. To be able to fix a bug, first you
>>have to know it. Both of us develop an application
>>around our copies of hal. application is closed source
>>(we are giving binaries). but for evident reasons,
>>your application turns out to be more stable and
>>sturdy (reasons could also be that you are a better
>>programmer  and have even dealt with application code
>>well). but if the case is of an application based
>>on/available in open, it makes things easier for me. I
>>am aware of your hal stability. I need to get hold of
>>a copy of binary given by you, compare the relevant
>>sections (assuming i know what is relevant to look
>>for) of that related with hal code and yeah, i gather
>>a lot about the fixes you have done.
>>
>>you were gaining for stability / performance (crashing
>>and malfunctioning) of your applications, now I too
>>know some of those secrets.
> 
>  
> True, but you are assuming the competitor is using the same HAL.  How
> often does this happen in reality? There are so many different CPUs
> available. The choose of CPU quite often is decided by which supplier
> will give you the best deal, or what CPU/reference design you have the
> best knowledge off, etc.
>  
> If you are deliberately setting out copy somebody else's product then
> maybe you would then use the same CPU and reference design, but you
> are likely to get into other legal trouble with the rest of the system
> anyway.
>  
> There are other arguments against this as well. In practice, my
> experiance with real projects using eCos is that 99% of the bugs are
> in the application. When you start a project you will very quickly
> evaluate the stability of eCos. You will run all the tests and find if
> it works or not. You then have the choice to either fix the bugs
> knowing you have to give them to your customer, or you can swap OS.
>  
> There is one situation i can see which you argument it true. Thats
> with very integrated chipsets. A fictitious example. Say a chipset
> vendor produced a chipset that has an ARM processor, a CCD camera,
> ethernet device, built in 512Kbyte RAM and 512Kbytes FLASH. This is
> obviously designed to be some sort of webcam. eCos provides nearly
> everything you need for this chipset. You application is limited to
> the CCD camera driver, the compression code and the controlling
> application/web server etc. eCos plays a very big part in this setup,
> so bug fixes you find in eCos could help you competitor.
> 
> As with any system you have to consider all the pros and cons and then
> decide. Maybe eCos is the right choice for the application, maybe it
> is not. 
> 
>         Andrew
> 



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list