[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?

Hi Goswin

Thanks for your response, and interesting new view (option C)
on this matter.

On Tue, Oct 31, 2006 at 02:20:44PM +0100, Goswin von Brederlow wrote:
> Ola Lundqvist <opal@debian.org> writes:
> > Let me take two examples:
> > * Person A create a driver by reverse engineering, determine
> >   that by setting a number of memory parts to different values,
> >   the hardware will work as expected. Person A do not know why.
> > * Person B create a driver knowing, that by setting a number of
> >   memory parts to different values, the hardware will work as
> >   expected. Person B knows why.
> * Person C creates a driver knowing with properly names defines and
> comments explaining why he does what and where to easily readable
> structures of the register mappings of the hardware. Person C then
> goes and obfuscates the code into putting seemingly random values into
> seemingly random addresses. Person C still uses his unobfuscated code
> to makes changes but only releases the obfuscated version under GPL.

Yes it is slightly different.

> > Both persons have released their code under the same license
> > and they look (almost at least) the same.
> >
> > Which one will break DFSG?
> >  - Person A?
> >  - Person B?
> >  - None?
> >  - Both?
> Only C. But deciding if B or C applies it quite impossible.

Ok, you are probably right if the person use an automated tool to make
this obfuscation. (Not sure though, see below).

However as it is impossible to know if someone use a obfuscation program
or if the person use a text editor to edit this, I can not see it as
a violation anyway.

At least it is a bit harsh to see it as a policy violation just because
it may be obfuscated.


> > #2 Source Code
> > Source code is available. Not perfectly readable, but this is the
> > source that was released, and licensed away, so yes we have the source.
> Under GPL (as in my example Person C) you need the prefered form of
> modification, which is more than what the DFSG strictly called
> for. But most people might take it as the same (meaning ofuscating is
> so evil it breaks this rule).

The only thing I can find in GPL about this is:
"The source code for a work means the preferred form of the work for making
modifications to it. For an executable work, complete source code means all
the source code for all modules it contains, plus any associated interface
definition files, plus the scripts used to control compilation and
installation of the executable."

But this is only applicable for the ones that distribute and
modify the code as it is listed under chapter 3.

As you say you need the prefered form of _modification_, which means
that if we change things, we are not allowed to obfuscate it. I can not
see anything that enfoce the original author to actually do such

You can not ship something without source at all as the following
phrase exist in the GPL:

"Our General Public Licenses are designed to make sure that you have
the freedom to distribute copies of free software (and charge for this
service if you wish), that you receive source code or can get it if
you want it, that you can change the software or use pieces of it in
new free programs; and that you know you can do these things."

The only requirement on the original author (as I can determine) is that
you get source code for it, not that it is in preferred form for making

Or do I misinterpret the GPL?



// Ola

 --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering ----
/  ola@opalsys.net                   Annebergsslingan 37        \
|  opal@debian.org                   654 65 KARLSTAD            |
|  http://opalsys.net/               Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /

Attachment: signature.asc
Description: Digital signature

Reply to: