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

Re: Bug#383481: Must source code be easy to understand to fall under DFSG?



On Mon, Oct 30, 2006 at 04:52:13PM +0100, Ola Lundqvist wrote:
> The only thing is #2 above. The question is if someone must release
> all it knows when it release open source software (according to DFSG)
> or if you can release only enough to make something work. I can also
> put it as if you want to make good software, when you release something
> as open source?
> 
> What I want to tell with this message is that we should stick to
> what the license tell. The important thing is that we do not
> build something binary that do not contain the code that can
> produce that binary.
> 
> If we consider this as a violation of the DFSG (because of #2 above),
> then where do we draw the line between closed and open source?

Notice that in the GPL case, the definition of free software (to use the
FSF/GNU terminology, which is more fiting here) is pretty clear about the
what is source, namely "the prefered form of modification".

> Must software be easy to understand, or should we consider all software
> that have hardcoded values as closed source?
> 
> 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.

Friendly,

Sven Luther



Reply to: