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