[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] License issues GPL/LGPL and Juergen Goeritz' SoC
Yann Guidon a écrit :
> 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
> 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
> 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.
You all right but you miss one very big point. If a compagny have a
problem with an ARM7, ARM will have a lot of trouble and pay. For fcpu
nothing !There is absolutely no garanty. A lot of compagny will be
afraid of this risk. Look, it happen the same thing with linux : only
Red Hat are supported by compagny as Cadence or other software compagny.
Maybe, Turbo linux, Suse and Mandrake but never Debian. Never. There is
no compagny to make the support, but every one have the right to do it !
Leon aren't "space qualified" nowdays and will be used "maybe" in few
years, not before !
> 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.
ARM7 is a 32b device, so ? In few years, will have 0.07 um tech, 64 bits
cpu could become common.
> 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.
Yep, if they can earn money, and there work will not be stolen as
explain by Michael. But i think of another think of the GPL. Sources
must be delivered with binaries but what happen with chips. Does a chip
maker should release a chip with the HDL code ? It's not a binaries, so
does the compagny _must_ distribiute this code ? or it must be done only
in case of IP (no more SDF file only, IP), which is more directly link
with the sources code ?
> To unsubscribe, send an e-mail to email@example.com with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
To unsubscribe, send an e-mail to firstname.lastname@example.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/