Re: hello

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

hi !
(g'nighty night too :-P)

graham@belegost.mit.edu wrote:
> Hi,
> 
> I've added some pages for the fcpu license: see
> http://opencollector.org/hardlicense/fcpu.html
i'll take a look, this seems interesting/exciting :-P

> If its ok with people, I'll build on these (to keep
> a record rather than as a place where people leave
> things; I can't think of a simple way to allow general
> modification of pages; I could add a script to take
> proposals for changes, but I think its better done through
> the mailing lists).
KISS :-)
use the HTML power, for example, to make hyperlinks with
the mailing list from the main text ;-)

> The rest of this reply is broken into sections to make it
> easier for me. :-)
are you that tired ? ;-P

> > but when it comes to the denominations, i'm forced to use the "usual" vocabulary.
> OK, how about just using the word 'design'? Given the same definition
> as in para 2 of 'What is in common with the gpl', you could use the
> word design instead of IP almost everywhere in the text without
> changing the end result.

heh, maybe you weren't that tired after all.
this sounds cool. lawyers will hate.


then you wrote :
> > i disagree in the last sentences : what you are forced to divulgue is
> > not necessary working or "nice", tidied. most CVS trees on the Net do
> > not have complete working and nice projects. as with the GPL, the licence
> > i want is mainly a "gentleman agreement". usually, the licence is enforced
> > in severe cases, not just for annoying your neighbour.
> > The GPL does not give you all the rights completely. there are cases where
> > i can't access GCC sources "because i'm not a customer". but for a CPU,
> > i would like to see what's inside it, what features are really implemented
> > and how, before i buy it or in order to compare it with others. for a CPU,
> > "compiling" is not simply going through GCC, it takes big ressources and budget.
> > so i don't see the problem with asking to release the sources.
> OK, one thing the gpl gives you is the right to modify a gpl-ed
> product for 'in-house' only use.
that is the term that gets "misused" and counter-interpreted.
there were some threads about this on comp.arch some time ago...

> If you don't distribute it, you don't
> have to release the modification.

in the f-cpu world, you understand that the "compilation" and the
"distribution" are very hard things and a lot of development might
occur before one chip goes to the market ... so if the release goes along
with the distribution, we might miss a *lot* of the real development effort.

> Maybe that's not perfect for a
> utopian system, but it seems only practical to me.
in practice, i've seen the limits. That's why i try to push forward a stronger GPL.
once you start modifying a file, don't tell me you don't know what you're doing ;
you're implicitely taking part with the general development of the project,
whether it is inhouse or not : it's a part of the project, thus it "should" be
released. ok, what you made might be crap and might break the CVS tree, and
you decide to keep it for yourself. but when Intel did some "inhouse" dvpt around GCC
for IA64, it lasted quite a while and they put NDAs on top of it. as a "normal"
GCC contributor (if you were into this) would you accept that ?
ok, they finally released it but it went the same way that with Analog Devices :
delay, delay, and one day release when nobody needs it.

this "stronger GPL" is not really an utopy, it's about avoiding such cases.
you won't fire your lawyers at a teenage hacker who changed three words
in a file. OTOH you can legitimately "speak louder" if you're company A asking
company B to release their version, even if it's not complete, for evaluation
purpose for example. if you're happy with this design, you'll build upon it,
and in return company B will be able to build upon this or simply reuse/implement.
Intel and others didn't understand that cooperation thing. There might be a way to
force them to understand...

> Say I run a design
> dept in a big company, and I want to evaluate the fcpu as a possible
> core, along with several other different ones. If I want to do that
> I'm almost certainly going to have to make some changes to the core
> (probably interfacing ones). So just to evaluate it I have to set up
> a web site and public CVS tree?

it's not necessarily in your own web site. A tarball sent to the f-cpu
group would do the trick. you're not forced to open a CVS tree (first
i don't use it, and second it will be unuseful if you don't use it).
publishing does not mean that you must run a website, but leave the information
avaialble for reading. OTOH if your f-cpu-based project is very active, you
might as well have a public CVS tree which accepts inputs from (authorised)
people outside of your company. If somebody is not happy for a reason or another,
he can duplicate the tree freely and run it separately.
"publication" is like a file with read right, you're not forced to have the
right to write, since the read allows you to rewrite in your own pool
"as long as you keep the read right".


> But I also don't understand parts of your argument - especially about
> the gpl. You say: 'there are cases where I can't access gcc sources'
> Is gcc a typo for gpl?
no. this is a case with MCS.

> If so, and there are cases where you can't access
> gpl-ed source without being a paying customer, you should tell the
> FSF who will get their lawyers onto it.
IIRC i ringed a bell at the fsf but there's no garanty.

> And I agree with what you say
> about the information about the CPU having to be available - but in the
> case you describe the CPU is being distributed, so the info would have
> to be given out under the gpl too.
the GPL is rather unclear about the release conditions hence the MCS case.
a "stronger GPL" would clear this up and i'd sleep a bit better ;-)


then :
> For software one way this works is that you can assign your copyright
> to the FSF, who have lawyers who will fight cases for you (or in
> reality 'lean' on offenders and tell them how much bad publicity they
> will get, which has the same effect).
ok i know. But here the case is a bit different : it's not ONLY about
copyright.

> There's no such organization
> for hardware designs. Maybe there will be one day.
are you volunteering ? ;-P

> But this seems like an organizational problem, not a license one.
they are closely linked together. if a licence needs an independent organisation
we have to make it. if we can turn the licence in such a way that no
legal stuff is needed, we can spare a lot of efforts :-)

> If I gpl some
> software I write I can't afford a lawyer to enforce the license.
> But there's nothing to stop any users of the software offering
> to put up money to fight the case for me - it's not something that
> needs to be mentioned in the license one way or another.
... at least until now ...

> I guess generally the reason I'm arguing these things is because
> the closer you can stay to the original gpl, the more likely it is
> to get general backing. And also because the gpl is designed around
> (US) copyright law - I don't think you can assign copyright to
> all potential users and then have any say at all over what is done
> with the design (eg say that developers have to release documentation)

one reason to going away from the classical GPL is because it can't be applied
verbatim to certain countries (ie France where the author's rights are
another legal tool that sometimes replaces the copyright stuffs). It is also because
we can't have a monolithic house (aka FSF) in a country (aka USA) and send
the lawyers in a plane to another country to protect the licence and its users
on a case per case basis. there might be a silly way to solve the lawyer problem
(through reversed auctions ;-D) but that's REALLY not a good idea...

and finally :

> > > > spirit. I have seen GPL infringements through "reinterpretation" of the GPL.
> > > Any reference to this?
> > personal communications with a developper at Mercury Computer Systems (mc or mcs.com).
> > i don't have it near to me, sorry, but it is archived somewhere.
> There are two possibilities: either there is a legal weakness in the
> gpl that these people are using - and then everyone should be told what
> this is, so the FSF can change it - or these people are breaking the
> law, and the FSFs lawyers should be told.
there must be other proofs anyway. You can try asking by yourself, for example :
maybe the guy did a simple mistake. I leave others the right to do errors,
but i don't miss such a lesson. for me a SGPL is a good solution. ask RMS if it is
possible.

> > maybe we can ask the FSF to issue a SGPL (like the LGPL, but with "stronger"
> > instead of "light"). i repeat : going from the SW industry to the electronics
> > industry involves a big change of the mentalities. we need something appropriate.
> > same goes for the GFDL.
> Did you read what rms said about hardware designs in the older archives? 
not on the older archive but i read something (1 year old ?).
well, as someone "in the milieu" i can give counterexamples for what i read.
i don't think that he made a crucial point, just rose some practical limitations.
he must remember that a man always gets what he wants if he REALLY wants it ;-)

> I strongly believe they won't do this unless you come up with a very 
> worked out, detailed, argument and a thoroughly worked over license draft. 
that's why i'm discussing with you here tonight ;-)

> > i guess that you mix up things. The F-CPU licence deals with the F-CPU's IP.
> > it doesn't deal with a chip. 
> I think its more fuzzy than that for several reasons:
> 1) I thought you/David Cary/Jamil were saying that the license should
> be more general than just for F-CPU?

the f-cpu licence that i try to make can be generalized to other "free" projects.
then change the f-cpu with the project name, or some other. i think in "f-cpu" terms,
but there is no problem to apply this philosophy to other projects. a collaboration
with Jamil would also be a good thing, in reducing our individual efforts and generalising it.

> 2) You have a requirement that a URL is put on each chip. I agree with
> this. But this is 'dealing with chips' in a way.
ooops, right.
> There's nothing similar in software: no-one says 'each binary should include an
> embedded url pointing to the source'.
so what ?

anyway, what do you think about the labels : "this product contains genetically modified
soja" or "this beef has got five seringues of growth hormones" etc...
when there's something important that the user should be aware of, it is written on the
package. what if the f-cpu-powered chip you bought contained an instruction that is not
contained in the reference manual ? What if there is a slight binary incompatibility ?
i'd call this a "general responsibility" problem : make the client aware of what he buys
and uses. except that a URL is less flashy than red lights with a "radioactive" logo :-)

there's something to dig here.

> "this is not a pipe, and doesn't smell like tobacco".
> > the licence deals with the modification made to the IP, not its use.
> > so i guess that if you make a system including a F-CPU core, you'll ave to publish
> > only the modifications made to the core. if you have an Ethernet controller,
> > used from an external library, it has nothing to do with the F-CPU itself, so
> > no worries. but if you add an F-CPU instruction or modify the Special Registers to
> > access configuration registers in the Ethernet controller, you have to publish the
> > mofications that alter the f-cpu core. this is a controversial subject,
> > and these are my first words, so this is not a definitive point of view.
> Makes a lot of sense to me, though :-)
wow :-)

> Do you think anyone else is going to join in this conversation?
dunno. but they don't know what they miss :-P


> 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