Bug#383481: Must source code be easy to understand to fall under DFSG?
Hi
First I want to tell to you Kyle and Matthew, that this is not a personal
thing against you, and that I have noted the question mark in the end of the
subject ("Contains obfuscated source code, DFSG violation?"). I actually want
to thank you for making me think on what my opinion about open source is.
(I have decided to Cc debian-legal, but I'm not subscribed to that list
so please CC me if you want me to read it).
Now to the reason why I wrote this mail.
I have a question about the bugreport (#383481) because I do not
understand what the problem is. The source code is there, you can
modify it and release it under the same license. Perfectly legal under GPL.
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.
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?
I'll take each item in DFSG and determine it from that points:
-
#1 Free Redistribution
No restriction here.
#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.
#3 Derived Works
No restriction.
#4 Integrity of The Author's Source Code
No restriction, you can change as much as you want.
#5 and 6 No Discrimination ...
No discrimination on specific groups in the licsense.
#7 Distribution of License
No problem here.
#8 License Must Not Be Specific to Debian
No problem here.
#9 License Must Not Contaminate Other Software
No restriction here.
#10 Example Licenses
Just examples, and according to the DFSG, GPL is a fully ok license.
-
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?
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.
Regards,
// Ola
--
- Ola Lundqvist ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
signature.asc
Description: Digital signature
Bug#383481: Must source code be easy to understand to fall under DFSG?
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> 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.
If you have 'char data[] = { 0xef, 0x45, ... };' and from running a
disassembler it is clear that this was produced with gcc for arm (yes,
that is not too wilde an idea) or some other compiler I think then it
is at least suspect.
Personaly I rather have such a char array under GPL than no driver or
a binary only driver. At least you can perfectly legaly dissasemble
the data and, comment the code and make it readable again.
Ultimately I think the decision is with ftp-master and then you have
to fight hard to reverse that. They usualy make good calls there.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
Hi Mathew
(Anyone on debian-legal: please note and maintain the Cc:s)
On Tue, Oct 31, 2006 at 04:26:38PM +, Matthew Garrett wrote:
> On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
>
> (Anyone on debian-legal: please note and maintain the Cc:s)
>
> > 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
> > obfuscation.
>
> No, the preferred form *for* modification.
Hmm, you may be right.
> > 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
> > modification.
>
> That's perfectly acceptable. Upstream can do whatever they want.
> However, if upstream do not provide the preferred form for modification
> (ie, the unobfuscated version), Debian can not distribute it under the
> terms of the GPL.
True. But do this mean that Nvidia have actually violated the license that
they have released their software under? Well maybe not as they may not
need to accept the license to actually use their rights...
As I understand from this, is that it is not enough to know that the software
is licensed under GPL, we must also check every single line of code (manually)
to determine if it is obfuscated or not before we include it into
Debian? Or should we just do this on a best effort basis, that is
file serious bugs when we encounter this.
> That's not an issue in this case, since X is not a GPLed application.
The bug I'm referring to is actually on linux-2.6 and not on X. :) The
original bug was on X though.
> Debian can distribute the obfuscated code entirely legally, without
> violating any licenses. The issue is whether "source" in the DFSG refers
> to the GPL's definition ("the preferred form for modification") or not.
> An alternative interpretation could be "a form amenable to modification
> by people sufficiently familiar with the work".
>
> If people define source as "the preferred form for modifications" in all
> cases, then there's no place for deliberately obfuscated code in Debian.
That is what the Open Source Definition tell. The open source definition
is only applicable on programs though. But we do not enforce the usage
of the open source definition as far as I know. Or do we?
http://www.opensource.org/docs/definition.php
> There's also arguably no place for works that are only available
> as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right now
> there doesn't seem to be a strong opinion in the project about that, but
> I expect it's a discussion that needs to be had.
True. The positional statement that clarified was not the winner in one
of our votes:
http://www.debian.org/vote/2006/vote_004
> (For anyone doubting that the nvidia code is deliberately obfuscated -
> http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv4driver.c.diff?r1=1.1.2.3&r2=1.1.2.4&hideattic=0&only_with_tag=xf-3_3_3
>
> ought to make it pretty clear)
I may be stupid ( :) ) but I can only see that the code is not trivially
easy to read (on either sides). I do not know who did this change
and so on. I can see that the older one is slightly easier to read
on some areas, but that is all I can tell (as I'm not that familiar
with this source). :)
Best regards,
// Ola
> --
> Matthew Garrett | [EMAIL PROTECTED]
>
--
--- Ola Lundqvist systemkonsult --- M Sc in IT Engineering
/ [EMAIL PROTECTED] Annebergsslingan 37\
| [EMAIL PROTECTED] 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 /
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
Ola Lundqvist <[EMAIL PROTECTED]> writes:
> Hi
>
> First I want to tell to you Kyle and Matthew, that this is not a personal
> thing against you, and that I have noted the question mark in the end of the
> subject ("Contains obfuscated source code, DFSG violation?"). I actually want
> to thank you for making me think on what my opinion about open source is.
>
> (I have decided to Cc debian-legal, but I'm not subscribed to that list
> so please CC me if you want me to read it).
>
> Now to the reason why I wrote this mail.
> I have a question about the bugreport (#383481) because I do not
> understand what the problem is. The source code is there, you can
> modify it and release it under the same license. Perfectly legal under GPL.
>
> 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.
> 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.
> I'll take each item in DFSG and determine it from that points:
> -
> #1 Free Redistribution
> No restriction here.
>
> #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).
> #3 Derived Works
> No restriction.
>
> #4 Integrity of The Author's Source Code
> No restriction, you can change as much as you want.
>
> #5 and 6 No Discrimination ...
> No discrimination on specific groups in the licsense.
>
> #7 Distribution of License
> No problem here.
>
> #8 License Must Not Be Specific to Debian
> No problem here.
>
> #9 License Must Not Contaminate Other Software
> No restriction here.
>
> #10 Example Licenses
> Just examples, and according to the DFSG, GPL is a fully ok license.
> -
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> writes: ...CUT... > > 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. ...CUT... > > #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 obfuscation. 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 modification. Or do I misinterpret the GPL? ...CUT... Regards, // Ola -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 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 / --- signature.asc Description: Digital signature
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
(Anyone on debian-legal: please note and maintain the Cc:s)
> 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
> obfuscation.
No, the preferred form *for* modification.
> 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
> modification.
That's perfectly acceptable. Upstream can do whatever they want.
However, if upstream do not provide the preferred form for modification
(ie, the unobfuscated version), Debian can not distribute it under the
terms of the GPL.
That's not an issue in this case, since X is not a GPLed application.
Debian can distribute the obfuscated code entirely legally, without
violating any licenses. The issue is whether "source" in the DFSG refers
to the GPL's definition ("the preferred form for modification") or not.
An alternative interpretation could be "a form amenable to modification
by people sufficiently familiar with the work".
If people define source as "the preferred form for modifications" in all
cases, then there's no place for deliberately obfuscated code in Debian.
There's also arguably no place for works that are only available
as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right now
there doesn't seem to be a strong opinion in the project about that, but
I expect it's a discussion that needs to be had.
(For anyone doubting that the nvidia code is deliberately obfuscated -
http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/vga256/drivers/nv/Attic/nv4driver.c.diff?r1=1.1.2.3&r2=1.1.2.4&hideattic=0&only_with_tag=xf-3_3_3
ought to make it pretty clear)
--
Matthew Garrett | [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
Hi Sven On Tue, Oct 31, 2006 at 07:32:02PM +0100, Sven Luther wrote: ...CUT... > > 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. The question is if it is a violation or not to release as is. 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. Regards, // Ola > Friendly, > > Sven Luther > -- --- Ola Lundqvist systemkonsult --- M Sc in IT Engineering / [EMAIL PROTECTED] Annebergsslingan 37\ | [EMAIL PROTECTED] 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 / --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, 31 Oct 2006 16:26:38 + Matthew Garrett wrote:
> On Tue, Oct 31, 2006 at 05:00:15PM +0100, Ola Lundqvist wrote:
>
> (Anyone on debian-legal: please note and maintain the Cc:s)
Including the From: field (that is you) and the To: field (that is Ola
Lundqvist)? Let's assume the answer is yes...
[...]
> > 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 modification.
>
> That's perfectly acceptable. Upstream can do whatever they want.
> However, if upstream do not provide the preferred form for
> modification (ie, the unobfuscated version), Debian can not
> distribute it under the terms of the GPL.
Exactly.
>
> That's not an issue in this case, since X is not a GPLed application.
> Debian can distribute the obfuscated code entirely legally, without
> violating any licenses. The issue is whether "source" in the DFSG
> refers to the GPL's definition ("the preferred form for
> modification") or not.
IMHO, DFSG#2 refers to source code, as is usually defined, that is to
say, as in the GNU GPL v2.
> An alternative interpretation could be "a form
> amenable to modification by people sufficiently familiar with the
> work".
I think that this would be too vague a definition.
The term "amenable" could be interpreted in a too broad sense and this
would become a slippery slope: someone sufficiently familiar with a
program could succeed in modifying its binary executable using a hex
editor, but (at least in most cases) he/she would *prefer* to make
modifications to the C code (assuming that the program is actually
written in C).
>
> If people define source as "the preferred form for modifications" in
> all cases, then there's no place for deliberately obfuscated code in
> Debian.
Yeah, and that's a feature, not a bug!!
Deliberately obfuscated code is absolutely against the spirit of Free
Software.
> There's also arguably no place for works that are only
> available as JPEGs, any flattened image formats, mp3s, PDFs and so
> on.
Not necessarily. It depends on which is the "preferred form for
modifications": this can only be determined on a case-by-case basis.
For some works the "preferred form for modifications" may be in JPEG
format (think of photographs taken with a digital camera); for some
other the "preferred form" may be some other format (from which the JPEG
is generated).
Please note that the same situation holds for programmatic works: for
some programs the "preferred form for modifications" may be assembly
code (or even machine code); for some other the "preferred form" may be,
say, C code; for some other it could be a grammar definition (think
about tools that generate C code for a parser of a given grammar: bison
comes to mind).
> Right now there doesn't seem to be a strong opinion in the
> project about that, but I expect it's a discussion that needs to be
> had.
IMO, this discussion desperately needs to be had. I think the right
time to have it is after etch is out.
--
But it is also tradition that times *must* and always
do change, my friend. -- from _Coming to America_
. Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgp760nf9rvFI.pgp
Description: PGP signature
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: > ...CUT... > > > 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. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote: [...] > 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. But those major parts of debian/main are cleanly buildable using an already functioning installation of debian/main, aren't they? At least I *hope* those major parts are buildable using only packages from debian/main, otherwise they would Build-Depend on out-of-main components, which is a Policy violation for a package in main, AFAIK. If what I have just said is true and confirmed, then *that* is the difference: one thing is having cyclic bootstrapping dependencies that make an already compiled and installed system necessary, a completely different beast is something that needs an out-of-main compiler in order to be compiled... Or am I completely off track?!? P.S.: I begin to doubt that each recipient still needs to be Cc:ed. Anyone who would like to be dropped from the Cc: list, please tell me! -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpAY1XcwVIyD.pgp Description: PGP signature
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Tue, 31 Oct 2006 20:50:19 +0100 Ola Lundqvist wrote: > Hi Mathew > > (Anyone on debian-legal: please note and maintain the Cc:s) Again assuming that this means you and Matthew want to be Cc:ed as well... [...] > > That's perfectly acceptable. Upstream can do whatever they want. > > However, if upstream do not provide the preferred form for > > modification (ie, the unobfuscated version), Debian can not > > distribute it under the terms of the GPL. > > True. But do this mean that Nvidia have actually violated the license > that they have released their software under? Well maybe not as they > may not need to accept the license to actually use their rights... A copyright holder cannot violate the license he/she releases his/her work under: he/she needs *no* copyright license to deal with his/her own work in any manner. The only license violation that could possibly happen is on works someone else holds copyright on. Hence, nVidia could be in violation, *if* and *as long as* their work is based on someone else's GPL'ed work. I don't know if this is the case here... > > As I understand from this, is that it is not enough to know that the > software is licensed under GPL, we must also check every single line > of code (manually) to determine if it is obfuscated or not before we > include it into Debian? Or should we just do this on a best effort > basis, that is file serious bugs when we encounter this. I think the Debian Project should assume that what upstream distributes as "source code" is actually source code (that is to say, the "preferred form for making modifications to the work"), *unless* there is a reason to think otherwise. Please note that IANADD: my personal opinion does not necessarily reflect the one of the DDs. [...] > > If people define source as "the preferred form for modifications" in > > all cases, then there's no place for deliberately obfuscated code > > in Debian. > > That is what the Open Source Definition tell. The open source > definition is only applicable on programs though. But we do not > enforce the usage of the open source definition as far as I know. Or > do we? > > http://www.opensource.org/docs/definition.php The OSD is completely off-topic here. The Debian Social Contract promises that "Debian will remain 100% free" according to the DFSG. It never speaks about the OSD. > > > There's also arguably no place for works that are only available > > as JPEGs, any flattened image formats, mp3s, PDFs and so on. Right > > now there doesn't seem to be a strong opinion in the project about > > that, but I expect it's a discussion that needs to be had. > > True. The positional statement that clarified was not the winner in > one of our votes: > http://www.debian.org/vote/2006/vote_004 Please note that, according to the proposer of GR-2006-004 (hi Don!), the text of the resolution "very carefully walks the line that the DFSG currently walks"[1]. That is to say, this GR (which however did not pass, as you note) only "restates what is current practice"[1], as far as non-programmatic works and DFSG#2 are concerned. The discussion about source code of non-programmatic works is (unfortunately) still to be had. [1] see the thread that started with http://lists.debian.org/debian-vote/2006/10/msg00185.html -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpHCWsq2CpeV.pgp Description: PGP signature
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Wed, Nov 01, 2006 at 12:55:45AM +0100, Francesco Poli wrote: > On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote: > > [...] > > 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. > > But those major parts of debian/main are cleanly buildable using an > already functioning installation of debian/main, aren't they? No, not always. > At least I *hope* those major parts are buildable using only packages > from debian/main, otherwise they would Build-Depend on out-of-main > components, which is a Policy violation for a package in main, AFAIK. Well, It is not so much that you have to depend on out-of-main components, but that you have to hand-build some of them and stop in the middle and stuff like that. > If what I have just said is true and confirmed, then *that* is the > difference: one thing is having cyclic bootstrapping dependencies that > make an already compiled and installed system necessary, a completely > different beast is something that needs an out-of-main compiler in order > to be compiled... Well, the cross compiler would be built from the same gcc source in main. There is just no binary package provided for those. > Or am I completely off track?!? Not completely, but a bit yes. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Oct 31, Francesco Poli <[EMAIL PROTECTED]> wrote: > IMHO, DFSG#2 refers to source code, as is usually defined, that is to > say, as in the GNU GPL v2. No, it does not. As usual, you are just inventing new requirements which are not specified by the DFSG. > Deliberately obfuscated code is absolutely against the spirit of Free > Software. But if it is X11-licensed then it is still free software, which is what matters here. -- ciao, Marco signature.asc Description: Digital signature
Bug#383481: Must source code be easy to understand to fall under DFSG?
On 10/31/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: * 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. Note that the actions described could have a different intent behind them: backwards compatibility with older hardware. More generally, backwards compatibility might look like obfuscation, to people who are not familiar with the older systems. [It tends to be a case of "there's something going on here which does not make sense."] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383481: Must source code be easy to understand to fall under DFSG?
On Wed, 1 Nov 2006 01:20:43 +0100 Sven Luther wrote: > On Wed, Nov 01, 2006 at 12:55:45AM +0100, Francesco Poli wrote: > > On Tue, 31 Oct 2006 23:59:18 +0100 Sven Luther wrote: > > > > [...] > > > 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. > > > > But those major parts of debian/main are cleanly buildable using an > > already functioning installation of debian/main, aren't they? > > No, not always. > > > At least I *hope* those major parts are buildable using only > > packages from debian/main, otherwise they would Build-Depend on > > out-of-main components, which is a Policy violation for a package in > > main, AFAIK. > > Well, It is not so much that you have to depend on out-of-main > components, but that you have to hand-build some of them and stop in > the middle and stuff like that. Well, that's suboptimal, but not a serious Policy violation, AFAICT. Feeewww! I can start breathing again, now... ;-) > > > If what I have just said is true and confirmed, then *that* is the > > difference: one thing is having cyclic bootstrapping dependencies > > that make an already compiled and installed system necessary, a > > completely different beast is something that needs an out-of-main > > compiler in order to be compiled... > > Well, the cross compiler would be built from the same gcc source in > main. There is just no binary package provided for those. [...] OK, this is not difficult to cure, then... -- But it is also tradition that times *must* and always do change, my friend. -- from _Coming to America_ . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp6EEGGHjiYV.pgp Description: PGP signature
