Re: fsf/chips

[graham@belegost.mit.edu]

> 
> hi,
> 
> graham@belegost.mit.edu wrote:
> > >
> > > things i should add to the f-cpu licence
> > > (while i still have it in the head) :
> > > - file format openness : no proprietary format.
> > > should be recommended by the W3C or standardized
> > > by the IEEE or ISO/ANSI.
> > >
> > > what would be the point of a "free design" if
> > > you can't read the files that the people distribute ?
> > > it would be a weak point of the licencing system
> > > and the GFDL takes this into account too.
> > >
> > If you write the paragraph, I'll stick it into the
> > html version (IMO saying it HAS to be IEEE or ISO/ANSI
> > might be a problem - what would be wrong with a textual
> > readable format that is publicly documented just because its
> > not one of the major standards?)
> 
> i'm not a specialist, and the GFDL licence gets to the point
> better than me. What we could write is :
> 
> - recommended formats : ASCII (ISO), C, C++, VHDL (IEEE), Verilog
> (IEEE???), HTML (W3C), JPEG, PNG, Latex (?) and so on...
> 
> - not recommended : PDF (unless the source is available
> in the same package), PS (another source problem), GIF (patent problems,
> but it's gonna end soon due to the end coming soon), but you'll remark
> that they're used anyway... there's the source or a copy somewhere that
> is freely accessible, but the files themselves (PDF or PS) can't be edited
> or modified.
What about schematics? even worse problems.... :-(

> 
> - opaque or patented formats (yes, some people do patent file formats,
> like M$ for a streaming format) are a BIG NO-NO. even if there's a document
> or two describing it somewhere.
> 
> this mail should be discussed and edited before we include it in the
> licence file, for example we can analyze and/or copy some parts of the GFDL
> which contains good points. The GFDL also deals with the translation to
> other langages. in general, any attempt to encrypt, remove rights
> (reproduce, understand, modify), reduce the visibility/understanding etc
> are forbidden.
Then how about a simple statement: 'any text documents in this design
are covered by the conditions of the current version of the GFDL'?
Has the advantage that they do the work of keeping track of the
current text format problems for you :-) Then we just have to worry about
hardware-specific things like schematics, IC layout files, etc...

> 
> 
> ------------------------------------------------------------------------
> 
> to avoid any problems, the terms of "inhouse use" and the likes should
> be avoided. even if in practice a file format gets translated into another,
> for example in the memory of your computer when you display it, i don't want
> to have problems with this concept/can of worms. maybe later we could work on this
> matter, but the industrial world is full of constraints and the GPL has not yet
> won all over the world, in particular in the laboratories that are tied to
> proprietary SW (Cadence or synopsys etc...).
> 
> ------------------------------------------------------------------------
> 
> i'm trying to jump on Jamil's idea of derivative/based work problems.
> but it's a difficult problem.

Its a problem shared with software: clause 2 of the gpl, para following
the <ul>...</ul> on their web page version. But its in horrible
legalese language so easy to miss...
> 
> ------------------------------------------------------------------------
> 
> you can speak on the HTML about the point we made recently about
> the cohabitation of several 'designs' : there's no problem integrating
> the F-CPU design on a chip that implements another design distributed
> with another licence if :
> - the presence of the f-cpu is clearly stated
> (as other f-cpu only chips, you know, the url etc), and 
> - the licence is respected and
> - the core is not obscurely modified to integrate the new features.
You want me to put that in as a separate clause? Could you just
save the latest page 'as html source', edit it and mail it back? Otherwise
I'm going to be guessing at what you want with risk of mind-reading
wrongly ;-)

> for example, i spoke about Emacs running under Windows without
> interfering with the GPL. there's nothing wrong with using a F-CPU embedded
> with a proprietary memory controller, as long as the f-cpu core is not modified
> (or the modifications obey the licence).
> 
> OTOH it is not possible to integrate a non-GPL'd (or f-cpu licence or the likes)
> design into the f-cpu. the reason is that if you include ie a patented stuff
> inside the design, when you redistribute it, you force people to infringe
> the patent or to accept a licence that is not this of the whole project.
> for example, it's not good to alter EMACS and force the system to use a
> proprietary/patented algorithm, interface or so on... you can't modify EMACS
> with informations protected by NDA about a particular device or software,
> because the GPL forces (???) you to release the source, and breach your NDA.
> 
> 
> well it's getting complex and late. I hope we can elaborate deeply
> on these subjects in a fruitful thread.
> 
> > Graham
> WHYGEE
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> the F-CPU: http://www.mime.univ-paris8.fr/~whygee/f-cpu.html
> SHARCPAGE: http://www.mime.univ-paris8.fr/~whygee/sharcpage.html
> 
Graham