Re: kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexandre Oliva wrote:
Hi, Hans,

On Mar 29, 2008, Hans de Goede <j.w.r.degoede@xxxxxx> wrote:

USB_SN9C102 - USB SN9C1xx PC Camera Controller support

Thats a fall positive there are a few hex coded tables in there, but
those are either:

1) color curve lookup tables

I'm not smart enough to understand what "color curve lookup table"
means.  Are the comments surrounding the code and published
information available for this decide sufficient for someone
relatively familiar with this topic to figure out what the numbers
mean and to, say, fix the tables such that they work for a lightly
defective camera that encodes colors incorrectly?

2) A standard jpg file format header which gets added in front of the raw jpeg
   data returned by the cam

I think this is probably fine, indeed, if there's a comment explaining
this.

3) register initialization tables consisting of { reg_addr, value } pairs

Now this could be a problem or not.

I've seen a number of drivers that profusely document the meaning of
each register and how it's to be used, such that someone can really
make sense out of it.  This is a great thing to have.

Other drivers simply refer to published specifications that describe
their meanings.

I'd guess that in others, developers didn't mean to deny information,
and they were just too lazy to provide all the information, or they
figured things out by themselves without consulting any documentation
whatsoever.  This could be defended as something other than trying to
stop others from having freedom #1, although adding documentation for
these cases would certainly add freedom.

Unfortunately, in other cases, developers were under restrictions
imposed by NDAs, or by copyrights or availability of the documentation
they might have wanted to copy or refer to.  For these cases, someone
is indeed hurting freedom #1, even if it's not the developer.

It's hard to tell one case from the other just by looking at the
code.  Sometimes you have to ask the developers, or the vendors of the
part the code is for.

You generally get one of these outcomes to a question such as 'Hey,
I'm trying to tweak this code, but I can't figure out these numbers.
Help?' is:

(non-Free IMHO):

- Sorry, I can't help you, I'm under an NDA

- Sorry, I don't understand them myself.  The vendor just said this
is what I should use.

- Sorry, I don't understand them myself.  I just copied them from the
Windows driver.

(non-sure IMHO :-)

- Sorry, I don't understand them myself.  After random trial and error
and some investigation of the behavior of the component while it
interacted with existing software, I got these numbers and they seem
to work for me.

(Free IMHO):

- Sorry, I should have referred to the documentation, it's publicly
available at http://...

- Sorry, I didn't have time to document my findings.  Here are the
notes I took while investigating the device.

- Sorry, I didn't have time or permission to copy the entire
documentation, but I'd be happy to send you a copy of the small
portion that explains these numbers in case you'd like to add
documentation to the code.

I happen to know this driver quite well, which triggered me, but
chances are quite big that you've many more false positives.

If you can help document the sequences of numbers that you can
understand in there, this would be a great improvement.  Then, we'd
have fewer doubts on whether that portion of source code is Free
Software or not.  Without the documentation, in Jeff's position and
given his commitment, I think he's taking a correct conservative
position of leaving it out.

Alexandre,

Isn't the logic of your position (when carried through to its necessary conclusion) that the *only* devices actually worthy of support by your kernel would be instances of free hardware, i.e. hardware wholly unencumbered by NDAs and patents (and thus, probably, the entire apparatus of bourgeois property relations)?

Best wishes,

Michael






--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux