NOT A [GPL License violation]

Bruno Ducrot ducrot at poupinou.org
Mon Oct 9 02:04:05 PDT 2006


On Sun, Oct 08, 2006 at 05:01:30PM -0600, M. Warner Losh wrote:
> In message: <45298188.1080201 at damogran.de>
>             Lutz Boehne <lboehne at damogran.de> writes:
> : In any case, I suggest you get back to that person and ask for more 
> : information.
> 
> That was my suggestion as well.  I grepped the entire tree, both ports
> and src, and couldn't find any code that came close to resembling this
> code.
> 
> Googling shows two packages that contain this code, but those aren't
> part of FreeBSD and they are distributed under the LGPL and the GPL.
> 
> Finally, there was no need to forward this to hackers@ or chat at .  Not
> only did I see it in audit, several people forwarded this to core@ for
> investigation.
> 

I'm working on Dell's laptop support, even though I'm not
the one who code a tool for a fan control (and I don't
know if such tool under FreeBSD exist).

Some preminaly code can be found here:

http://people.FreeBSD.org/~bruno/i8kutils_bsd.tar.bz  [1]
http://people.FreeBSD.org/~bruno/acpi_dell.tar.gz     [2]
http://people.FreeBSD.org/~bruno/dellctl.tar.gz       [3]

For now, the 3 tar ball above have not been publically send to any
public list I'm aware of, because those are only priminally work.

For [1], people can check I haven't removed any copyright, nor I even
bothered adding my name.  In any case, I don't plan to add that one to
the base system.
In fact, I think to remove it from http://people.FreeBSD.org/~bruno/
in the near future.

For [2], people can check it's a really preliminary work, and is based
on some calls to ACPI methods under the DSDT.  Since it's a really
different approach taken from the driver found under Linux, it's free
from any GPL'ed code.

Finally [3] is only a userspace tool to control [2].

Since [2] and [3] are free from any GPL'ed codes, I consider commiting
them if one day they work.

Actually I even considered to port [2] under Linux, because this is
the right way to go when ACPI mode is enabled for obvious reason.
The io ports related to the SMM handler are shared, and ACPI take
care to handle an ACPI mutex before entering SMM, that at least might
eliminate strange cases when sometimes i8k doesn't work.

Cheers,

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


More information about the freebsd-hackers mailing list