[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC



hi !

nicO wrote:
> Michael Riepe a crit :
> > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote:
> > [...]
> > > A SoC is so specialised ! So there isn't any interrest to change the
> > > chip. It's a complete system so you could always create a compatible
> > > chip with a complete different SoC. Imagine a mp3 producer, there is so
> > > many manner to make it. You could do it with dedicated HW or with a DSP
> > > or a powerfull RISC cpu, or with many little cpu.
> > >
> > > I hope a convince you.
> >
> > I absolutely don't mind if somebody builds an F-CPU based SoC.
> > As long as users can get the complete source code under GPL ;)
> >
> 
> I think that you forget that produice a complet chip cost a lot of
> money, a lot ! Do you think that a compagny will take 6 month to
> produice a chip that a direct concurrent could only use 2 month, because
> of the open source ?

you fall in the same trap constantly. F-CPU's goal is not to let people
do "benefits" on it. It is here to "help" the industry as a whole and
harmonize some common stuff. Where people would use SUN/SPARC workstations,
they could find F-CPU/Linux boxes for 1/4 the price and a lot of third
parties.

concerning the difficulty, here is the first opening quote from the
"supermen" book (about supercomputers, si tu veux l'emprunter yaka demander)
  "
    If a man can write a better book, preach a better sermon, or
    make a better mousetrap than his neighbor, though he build
    his house in the woods, the world will make a beaten path
    to his door.
                                     Ralph Waldo Emerson, 1871
  "

comprenne qui voudra. On top of that, this quote has a special
meaning because Seymour Cray built lots of CRAY fabs in the isolated
woods. Thanks to him, a lot of people in the neighbourhood
have seen helicopters and journalists for the first time
in their life :-)

> GPL was written for software in mind. They want to
> spread this kind of software, and make some attractive clauses (for
> example, we can not stole your code).

i don't like the "attractive" thing.
Of course, the following text probably doesn't apply to your last comment
but i write anyway.

Of course, i would like F-CPU to be used in big and small designs,
in the commercial or industrial world. However there is a limit to
attraction. i don't know if you understand what i will say, but
i encourage you to visit DATE (with me or alone) and preach for
the F-CPU. We are designers, not whores. Most people with whom
you will speak have no sense of what freedom means. the only
freedom they know is their "holy right to make profit" (sometimes
they think it can short-circuit other fundamental or constitutional
freedoms).
The only thing that they want is money, or profit. other words
are market shares, penetration (ouch !), growth... Nobody will speak
about advancement of the technology (except in the introduction
of very generalistic press releases), about encouraging competition
or our freedom to design and do our engineer's work.
Some university teachers are still idealistic enough to believe
in that, but that tends to disapear quickly as they get funded
by the industry.

So here, i will draw (or more precisely, redraw and insist upon it)
a "line" : You have the right to use the F-CPU sources for any purposes
as long as it is "out of the tarball" (unmodified). In fact, most
IPs are like that. I remember of an example (unsure but it's a rough
figure) for the ARM (?) core IP : ie you get the "compiled IP" for $10K
and if you want to modify it, you have to pay $35K (?). If my memory
serves me well, i heard these numbers at DATE in Munich).
"please contact your local reseller for up-to-date pricing".

Now, you get a kick-ass F-CPU with source code "for free". you get
the right to integrate it in your preferred washing machine as long as
you don't modify the provided sources or integrate stuff into the core.
The ARM (? was it ARM btw ?) guy told me that it is done this way
most of the time : few customers really want to modify the core's sources.
 - first reason is that the compiled core is already compiled : the compiler
   licence would cost more
 - it is already optimized
 - it is compatible with anything.
So that's fine for me. I don't know if Michael will agree to my POV but i am
open to any senseful and argumented discussion.

The next step is : you want to modify the core. You don't need to pay more
because it is already "free" and it can't be "more free". If i take
the ARM guy's saying for true, this is not going to happen a lot.
The condition for modifying the code is to redistribute it (in F-CPUland).
Of course there is still the problem of where the "limit" of the core is,
but it's another discussion.

What we "give" is the possibility to
"evaluate" the core, within the limits fixed (and slowly loosened)
by the m4 files' parameters. So if the company wants to implement,
say, a communication controller (SCSI RAID or IP router for example)
and wants to avoid the cost of an existing IP, a small team of
engineers can d/l the F-CPU tarball, the LEON's, anything else,
and make testbenches, comparisons, benchmarks...
If it chooses F-CPU, fine. If it needs some changes,
then it must release the new files. It is simple.

Forcing to release the files is seen, by you and Juergen at least IIRC,
as a problem. It is also forcing companies to open their eyes : releasing
their specs and sources increases indirectly the customer's self-help
and augments the feedback (if the company is open enough). It is a garantee
of stability of the product family. And remember the ALPHA fiasco :
Companies who heavily invested in ALPHA CPUs (sometimes when somebody lied
when purposedly saying that ALPHA would be continued during decades) have
now lost money and time porting their applications. Now, imagine ALPHA
was open-sourced : the companies would be able to continue the work,
probably through a joint-venture that spreads the costs.

I wish the microelectronics world was not such a dirty swamp ...


Concerning nicO's remarks about integrating F-CPUs everywhere :
fine, but woudln't it be an overkill ??? there is no "short"
version of F-CPU (32 bit support is not under way and it is discouraged).
I know no 'portable' application that needs fast 32-b arithmetics.
When it is really required, a 16-b or 32-b C does multi-precision
operations. 32-bit SIMD would be used for real-time imaging
and sound processing applications (ie digital handicams)
but the devices that do that are often made in Japan with
highly proprietary chips/ASICs. F-CPU would not help much.

However, it is useful for small quantities
(around 1K-100K) runs concerning high-speed control, such as
the SCSI or IP router example. Small companies would adopt F-CPU
easily because the price tag and the independence from the toolset
are "attracting" (to reuse your word). I think that it is where
we can seek implementors.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/