Re: Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, Oct 31, 2006 at 09:06:50PM +0100, Ola Lundqvist wrote:
> Hi Sven
> On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote:
> > > Will all reverse engineered drivers with hardcoded values be considered
> > > as closed source? Must you always release everything that you know
> > > when you release somehting as open source?
> > > Must we release the instructions on how to paint an image, how to
> > > move the arm while painting if we release an image as open source?
> > >
> > > I think this is worth considering. Personally I think this bug can
> > > be closed.
> > But your thinking are giving us an excellent way out. We could simply take all
> > those binary blobs that are in the kernel, and try to take a guess about the
> > instruction set which they are designed for, and disasemble them, and provide
> > the dissasembled version under the GPL, as well as a instructions to
> > re-assemble them into the actual binary blob.
> > If we were to achieve that, i would be more than happy to consider these blobs
> > and their corresponding reverse-engineered asm codes as actual source.
> > One may argue that in this case, the actual documentation of the registers
> > may be more of a source for such binary blobs, but it would in any case be no
> > worse than any other reverse-engineering effort out there.
> I fully agree that this kind of work would be a good thing. Such
> improvements would most problably be a benifit for the open source
> community and maybe would give us better functionality in the end.
Patches are welcome :)
> The question is if it is a violation or not to release as is.
I doubt that there is any more sense in (re-)discussing this.
> The other good (or bad?) thing is that we would need cross-compilers
> for most major instruction-sets as reassembling probably mean compiling
> for a different architecture.
Nope, because you can ship the source code and the object file if you wanted.
Already now, major parts of debian/main are not cleanly buildable out of the
box, due to cyclic bootstraping dependencies.