Benoit Audouard <[EMAIL PROTECTED]> tapota :

> ------------------ Début de Rapport SpamAssassin ---------------------
> Ce message est probablement du SPAM (message non sollicité envoyé en
> masse, publicité, escroquerie...).
>
> Cette notice a été ajoutée par le système d'analyse "SpamAssassin" sur
> votre serveur de courrier "hephaistos.attique.in", pour vous
> aider à identifier ce type de messages.

[...]

> Détails de l'analyse du message:   (3.1 points, 2.5 requis)
>  0.9 FROM_ENDS_IN_NUMS      L'en-tête From: se termine par un nombre
>  1.2 NO_EXPERIENCE          BODY: Contient une offre qui ne "requiert aucune 
> expérience"
>  1.1 MAILTO_TO_SPAM_ADDR    URI: Contient lien vers adr. mail ressemblant à 
> une adr. de spammeur
>
> -------------------- Fin de Rapport SpamAssassin ---------------------
>

Arg !
Désolé pour le delai s"explicant par ce qui précède.


> From: Benoit Audouard <[EMAIL PROTECTED]>
> Subject: Re: [Fwd: dialogue avec Sagem/ADI, impact respect GPL sur pilote
>       eagle-usb]
> To: Mathieu Roy <[EMAIL PROTECTED]>
> Date: Mon, 11 Oct 2004 22:02:39 +0200
> X-Mailer: Evolution 2.0.1-1mdk 
> X-Spam-Checker-Host: mx.attique.org
>

[...]


>> Par ailleurs, il me parait étrange de parler de license BSD ou X11
>> pour du code propriétaire. Ce n'est pas nécessairement erroné mais
>> c'est pervers, dans la mesure où l'on considère ces licences comme des
>> licences de logiciel libre, et non de freeware, parce qu'elles
>> s'appliquent avant tout à des code source.
> I've not yet made up my mind on this, I would prefer BSD a priori if GPL
> (with source since latest changes...) cannot be obtained. From my
> understanding, BSD licence authorizes to distribute the binary without
> the source code, hence we would be distributing a "binary to text"
> version of the firmware (the source being managed by ADI, see below).
>> Sinon, il est possible en effet, de manière satisfaisante pour la GPL,
>> que le firmware ne soit pas compilable avec des outils libres mais
> yep in case the source code is furnished (this is "new" for firmware)
> even though I'm willing to accept this rule (I'm not sure for ADI)
>> qu'il soit libre. Ceci dit, un logiciel libre dépendant de logiciels
>> propriétaires n'est pas tout à fait libre, si l'on creuse -- pour gna,
>> par exemple, c'est un problème.
> I do not know if such tools exists. Maybe http://sdcc.sourceforge.net/
> as this is a 8051 DSP chipset ? We have currently no experience with
> this and do not see the point of investing in it currently as it is run
> in the modem, no on the main unit (CPU of the PC). I've already seen
> such a discussion but could not find the url (I'm interested if you know
> any relevant URL, giving facts and impacts + suggestions to convince
> ADI).
> The current maintainers are ADI people, that's their choice to make.

That's not really the point.

> More particularly, would it imply that you are going to close our
> project on gna.org ?
> I've re-read https://gna.org which is quite clear in fact, and you give
> in Article 3 "For non-program contributions, we will decide on a case
> per case basis whether these restrictions apply or not." : I would like
> to examine this possibility before you come up with a final decision.

If we admit this firmware to be something different than a program, we
could indeed accept it. 
But I'd like to hear Vincent Caron and Loic Dachary about that. I got
no clear idea about the subject, apart that the reason why ADI does
not provide the firmware with the sourcecode is still be mystery to
me; having this information would probably help to find workarounds. 

I have the feeling that Loic knows much more than me about drivers
legal issues, as he work in an area where it does matter (3d
graphics).


> Here is what I proposed you in my previous mail (French again...) as I
> would like to make an example of eagle-usb for manufacturer that would
> choose to go nowadays to GPL licensing for their drivers. This may seem
> a duplicate for existing documents, when it's not : in our case, we
> still  have to convince ADI/Sagem and provide them with appropriate
> directives. They can then make their own choices with relevant
> information, updated when needed : I see it as a "practical exercise",
> that should be done following "libre"-ways (maybe - in some situations -
> not public on the short term, but as much as possible public in the long
> term). The wiki is a way to organize what can be found on the web and
> several ML.

That's an interesting approach.


About the content:

On <http://dev.eagle-usb.org/wakka.php?wiki=RequirementsEagleUsbGPL>, 
#LT007 and #LT006 are set with importance low. But if these problem
were solved, most of the others issues of greater importance would not 
even be a problem any longer. I strongly suggest to raise the
importance of these issues.

The problem is not really to obtain this sourcecode, the problem is to
address these questions first: 
        - Why ADI does not want to provide this sourcecode? There
        could be plenty of reasons, some of them could be trivial to
        resolve.
        - What does it means not to have this sourcecode? Can we bear
        with such firware? What is the usual practice when it comes to
        firmware inclusion in the kernel? This should inform us on the
        risk of such firmware, if any.

Once this is done, it will be probably easier to fix the problem in
one way or another. It is really hard to make a proposal without the
knowledge of an half of the problem.
        
Please, keep [email protected] informed of important steps made related
to this issue.


(PS: Please add me in CC: if you reply to this mail. I cannot suscribe
to such an high traffic list currently.)

-- 
Mathieu Roy

  +
  | Thalie  : <http://yeupou.coleumes.org/> 
  | Clio    : <http://clio.coleumes.org/>       
  | Uranie  : <http://alberich.coleumes.org/>
  | Euterpe : <http://kromaniaks.coleumes.org/>
  +-----------------------------------------------------------+

Reply via email to