On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote:
> Sven Luther <[email protected]> writes:
>
> > > It sounds like you are now looking at the question of are the
> > > huge string of hex characters the preferred form for making
> > > modifications to firmware. Personally I would be surprised
> > > but those hunks are small enough it could have been written
> > > in machine code.
> >
> > Yep, i also think it is in broadcom's best interest to modify the licencing
> > text accordyingly, since i suppose someone could technicaly come after them
> > legally to obtain said source code to this firmware. Unprobable though.
>
> Possibly. It sounds like that is what you want to do.
No, i am making them aware of the possibility, and hoping they fix the issue,
but we will see. If they fail to act on this, i don't understand why though,
since it is just addition of a clarification. It is not as if i am asking for
the release of all their chip specs or something such.
> > since there should be at least some kind of executable code in it,
> > independenlty of the fact that we claim that data is also software.
>
> Do you have any evidence that ``software'' was not written directly in
> machine code? Software is written directly in machine code when a programmer
So what, i seriously doubt they where written using an vi in C, as the code
currently stands, so we do need an additional level of source code, being it
only some asm code or something.
> looks at the instruction set and writes down the binary representation
> of the instructions. I know ISC dhcpd has packet filter code that was written
> in that manner, so it is not a lost art. And it is done often enough when
> an assembler will not cooperate, and generate the correct instruction.
But again, this is not the common assumption, so if this is so, they should
write it down black on white in the copyright notice, and everyone would be
happy.
> Without evidence that we don't have the preferred form of the software
> for making modifications I don't see how you can complain.
No, it goes the other way around. Without evidence that all is clean, we have
no right to distribute that code, and if what you describe was the case, a
couple of lines telling us that fact would solve the issue, and not even need
the involvement of their legal department. I would be somewhat suspisious
though if all these guys came up and said they just wrote said firmware in
binary directly though.
Friendly,
Sven Luther
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
- Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]