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

[Yann Guidon <whygee@f-cpu.org>]

hi,

nicO wrote:
> Yann Guidon a écrit :
> > nicO wrote:
> > > Michael Riepe a écrit :
> > > > On Wed, Sep 12, 2001 at 12:14:09AM -0400, nicO wrote:
> > > > [...]
<snipping full quote out>
> > 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 !
1) companies can have "problems" when :
 - vendor goes out of business
 - vendor "hides" pages of documents that detail "errata"
 - vendor sells bogus stuff
i don't remember a few others but i think that i have an "answer" for
each of them :
 - out of business : we can't ;-) and if that happens, the user has the sources.
 - no secret is tolerated in the F-CPU. If an error is found it is immediately
   communicated and worked around/corrected.
 - at least, we don't sell anything. So if it's "bogus", read the 2) below :-P

2) even though there's "nobody to sue", how many companies do you know
who do not take the minimum precaution of writing "no waranty for fitness etc."
??? Read a user licence from M$ or any "professional tool vendor" : they ALL
remove their responsibility. We are no exception in fact.

other case analysis can be discussed.

> There is absolutely no garanty.
excuse-me sir, but if your W95/98/NT/ME/2K freezes, will you sue M$ ?
M$ will ask you to re-read your contract which says that there is
no waranty of any kind. NOBODY today forgets this clause.
Buying stuff does not mean that you have the right to sue.
The reseller and manufacturer have rights and duties that are
defined by the local law, such as replacing a faulty device.
You can go to M$ to replace your badly-pressed Window$ CD
but the contents is something else.


> A lot of compagny will be afraid of this risk.
companies are sheeps. look at the stock exchange rates these days
if you are not convinced.

> 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 !
I don't think that this parallel can be really drawn, we are in a different
position.

> Leon aren't "space qualified" nowdays and will be used "maybe" in few
> years, not before !
it's not my fault ;-)

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

i simply wonder what application will use it. I'm simply puzzled.
However if that happens, i don't know, but that could be really crazy :-)

> > 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.
this means that we are in the case where the company's "central activity"
is not making CPUs but using them.

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

1) If the company uses a F-CPU core 'out of the box' and surrounds
   it with its own "meat", then the SR_URL must simply point to where
   the source code was downloaded. Modulo the definition of what the core is.
2) If the F-CPU core he uses has been modified by this company, 
   the company must upload the changes on his server and change SR_URL
   to point to the new address.

I think that it's a reasonable deal.

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