Re: generated source files, GPL and DFSG
On Thu, Jul 28, 2005 at 11:47:58PM +0200, Francesco Poli wrote: On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote: Florian Weimer wrote: [...] The GR did not change the wording of the DFSG at all. However, it's clear that a significant shift took place in SC interpretation, from a foggy definition of program to a more dogmatic everything we ship is software approach. Our interpretation of the DFSG must reflect this change. The only way to do this is to interpret progarm in the broadest possible sense. Please, no. We've already had long, tedious discussions about what software means. Don't go trying to change the meaning of program too. If you think that the places where we currently talk about program are unclear and should say software, then propose a GR to get them changed. We ship lots of things that are NOT programs... Yes, I think it's time to propose a GR to do a s/program/work/ in the DFSG. Since IANADD, I cannot propose GRs, but I hope that some DDs will help. It's not quite that simple; you can't just change that bit alone. I'm working on something here. More on this later. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Fri, 29 Jul 2005 15:58:36 +0100 Andrew Suffield wrote: Yes, I think it's time to propose a GR to do a s/program/work/ in the DFSG. Since IANADD, I cannot propose GRs, but I hope that some DDs will help. It's not quite that simple; you can't just change that bit alone. I'm working on something here. More on this later. I'm looking forward to seeing something concrete to discuss about! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpnI6duGhc2m.pgp Description: PGP signature
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
* Raul Miller ([EMAIL PROTECTED]) [050727 18:45]: On 7/27/05, Steve Langasek [EMAIL PROTECTED] wrote: Uh, I don't? I said that the other guidelines are *applicable* to non-program works, and *should be applied* to non-program works -- not that, as presently written, we are obliged to apply them to non-program works. I'd prefer to approach this issue from a different direction. The point behind the DFSG is that we need to be able to solve problems in the stuff we distribute. Sorry, but I disagree. The point behind the DFSG is that our priorities are our users and the free software community, according to our social contract. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Andreas Barth: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. After looking at the relevant GR again, I'm convinced that my first statement is indeed correct, and that the doubts I expressed in another message are unfounded. The GR did not change the wording of the DFSG at all. However, it's clear that a significant shift took place in SC interpretation, from a foggy definition of program to a more dogmatic everything we ship is software approach. Our interpretation of the DFSG must reflect this change. The only way to do this is to interpret progarm in the broadest possible sense. For practical reasons, we have to exclude license texts from that and certain copyright banners in About boxes etc., but this does not change the general direction of interpretation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Steve McIntyre: Please, no. We've already had long, tedious discussions about what software means. Don't go trying to change the meaning of program too. If you think that the places where we currently talk about program are unclear and should say software, then propose a GR to get them changed. We ship lots of things that are NOT programs... Exactly, and we still require that these things are properly licensed under some DFSG-free license. The interpretation I outlined is certainly not new. It reflects the current practice, and I think we're in a pretty good position as far as compliance is concerned. Even the notorious GNU FDL issue is not a real problem here (beyond the invariant section business) -- the GNU FDL requires open formats. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, Jul 28, 2005 at 04:08:09PM +0200, Florian Weimer wrote: * Steve McIntyre: Please, no. We've already had long, tedious discussions about what software means. Don't go trying to change the meaning of program too. If you think that the places where we currently talk about program are unclear and should say software, then propose a GR to get them changed. We ship lots of things that are NOT programs... Exactly, and we still require that these things are properly licensed under some DFSG-free license. The interpretation I outlined is certainly not new. It reflects the current practice, and I think we're in a pretty good position as far as compliance is concerned. Even the notorious GNU FDL issue is not a real problem here (beyond the invariant section business) -- the GNU FDL requires open formats. I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. That most certainly _is_ new, and is completely bogus. As I said, propose a GR to change the wording s/program/software/ of DFSG#2 if you want that meaning. Redefining/reinterpreting commonly-used words is a very good way to alienate people... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You can't barbecue lettuce! -- Ellie Crane signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
Florian Weimer wrote: * Andreas Barth: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. After looking at the relevant GR again, I'm convinced that my first statement is indeed correct, and that the doubts I expressed in another message are unfounded. The GR did not change the wording of the DFSG at all. However, it's clear that a significant shift took place in SC interpretation, from a foggy definition of program to a more dogmatic everything we ship is software approach. Our interpretation of the DFSG must reflect this change. The only way to do this is to interpret progarm in the broadest possible sense. Please, no. We've already had long, tedious discussions about what software means. Don't go trying to change the meaning of program too. If you think that the places where we currently talk about program are unclear and should say software, then propose a GR to get them changed. We ship lots of things that are NOT programs... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Welcome my son, welcome to the machine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Steve McIntyre: The interpretation I outlined is certainly not new. It reflects the current practice, and I think we're in a pretty good position as far as compliance is concerned. Even the notorious GNU FDL issue is not a real problem here (beyond the invariant section business) -- the GNU FDL requires open formats. I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. Why do you think this would change anything? Isn't this the assumption under which debian-legal operates in general? With a few practical exceptions, of course (license texts, public key certificates, etc.), but the general rule seems to be followed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Florian Weimer ([EMAIL PROTECTED]) [050728 16:19]: * Steve McIntyre: The interpretation I outlined is certainly not new. It reflects the current practice, and I think we're in a pretty good position as far as compliance is concerned. Even the notorious GNU FDL issue is not a real problem here (beyond the invariant section business) -- the GNU FDL requires open formats. I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. Why do you think this would change anything? Isn't this the assumption under which debian-legal operates in general? Actually, it is not the assumption under which the DFSG operates in general. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, Jul 28, 2005 at 04:19:02PM +0200, Florian Weimer wrote: * Steve McIntyre: The interpretation I outlined is certainly not new. It reflects the current practice, and I think we're in a pretty good position as far as compliance is concerned. Even the notorious GNU FDL issue is not a real problem here (beyond the invariant section business) -- the GNU FDL requires open formats. I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. Why do you think this would change anything? Isn't this the assumption under which debian-legal operates in general? With a few practical exceptions, of course (license texts, public key certificates, etc.), but the general rule seems to be followed. What? I'm astounded by your argument here. Go look in a dictionary, _please_. Program does not mean what you think it means. Re-defining a common word like this is not a good route for earning credibility. If you think DFSG#2 should cover all programs/software/images/works/whatever, then change it so that it _does_ say that. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Google-bait: Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
* Andreas Barth: I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. Why do you think this would change anything? Isn't this the assumption under which debian-legal operates in general? Actually, it is not the assumption under which the DFSG operates in general. Quite deliberately, I wrote debian-legal, not DFSG. 8-) I don't know much about DFSG interpretation by the people who actually decide what's DFSG-compliant and what's not. Maybe their view is suffficently distinct, but the archive doesn't show it, IMHO. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Steve McIntyre: Why do you think this would change anything? Isn't this the assumption under which debian-legal operates in general? With a few practical exceptions, of course (license texts, public key certificates, etc.), but the general rule seems to be followed. What? I'm astounded by your argument here. Go look in a dictionary, _please_. Program does not mean what you think it means. Re-defining a common word like this is not a good route for earning credibility. I'm not redefining anything. I'm entirely descriptive. Have a look at the list archives if you don't believe me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On 7/28/05, Andreas Barth [EMAIL PROTECTED] wrote: * Raul Miller ([EMAIL PROTECTED]) [050727 18:45]: On 7/27/05, Steve Langasek [EMAIL PROTECTED] wrote: I'd prefer to approach this issue from a different direction. The point behind the DFSG is that we need to be able to solve problems in the stuff we distribute. Sorry, but I disagree. The point behind the DFSG is that our priorities are our users and the free software community, according to our social contract. Ok, I'll say that more verbosely: The point behind the DFSG is that we need to be able to solve problems in the stuff we distribute for our users, and for the benefit of the free software community. Thanks, -- Raul
Re: generated source files, GPL and DFSG
On Thu, 28 Jul 2005 15:00:29 +0100 Steve McIntyre wrote: Florian Weimer wrote: [...] The GR did not change the wording of the DFSG at all. However, it's clear that a significant shift took place in SC interpretation, from a foggy definition of program to a more dogmatic everything we ship is software approach. Our interpretation of the DFSG must reflect this change. The only way to do this is to interpret progarm in the broadest possible sense. Please, no. We've already had long, tedious discussions about what software means. Don't go trying to change the meaning of program too. If you think that the places where we currently talk about program are unclear and should say software, then propose a GR to get them changed. We ship lots of things that are NOT programs... Yes, I think it's time to propose a GR to do a s/program/work/ in the DFSG. Since IANADD, I cannot propose GRs, but I hope that some DDs will help. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpV2L7hMdicG.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
I'm arguing with your interpretation of program to mean anything you
want - in this case potentially any random string of bytes. That most
certainly _is_ new, and is completely bogus. As I said, propose a GR
to change the wording s/program/software/ of DFSG#2 if you want that
meaning. Redefining/reinterpreting commonly-used words is a very good
way to alienate people...
If you are only looking at the DFSG, you are missing the point. The
point is that the Social Contract requires that all software in Debian
(that is, main) must comply with the Debian Free Software Guidelines.
That was the interpretation debian-legal used before last year's GR, and
the GR, while editorial, simply made that clearer.
Therefore, if the DFSG said that All ham sandwiches must include source
code..., then the Social Contract would still require that all
provisions of the DFSG apply to all of main.
In addition, DFSG 6 and several other DFSG sections apply to programs.
If you are claiming that suddenly non-program software does not have to
comply with DFSG 6, then we have a problem.
Also, from policy 2.2.1:
Every package in _main_ and _non-US/main_ must comply with the DFSG
(Debian Free Software Guidelines).
Note that it does not say: Only programs in _main_... or Every
program in _main_ Therefore, it is still a serious bug.
In addition, the etch RC policy requires that:
All content in main and contrib must meet the DFSG, both in .debs and
in the source (including the .orig.tar.gz)
I see no support for your opinion in actual, codified Debian policy[0].
[0] By policy, I don't mean just policy.txt.gz; I mean all technical and
non-technical policy documents.
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: generated source files, GPL and DFSG
On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote: On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote: I'm arguing with your interpretation of program to mean anything you want - in this case potentially any random string of bytes. That most certainly _is_ new, and is completely bogus. As I said, propose a GR to change the wording s/program/software/ of DFSG#2 if you want that meaning. Redefining/reinterpreting commonly-used words is a very good way to alienate people... If you are only looking at the DFSG, you are missing the point. The point is that the Social Contract requires that all software in Debian (that is, main) must comply with the Debian Free Software Guidelines. That was the interpretation debian-legal used before last year's GR, and the GR, while editorial, simply made that clearer. Therefore, if the DFSG said that All ham sandwiches must include source code..., then the Social Contract would still require that all provisions of the DFSG apply to all of main. Yes, the DFSG must be applied to everything in main. How do you get from there to the words 'ham sandwich' must be read as 'software', exactly? -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Thu, 2005-07-28 at 20:08 -0700, Steve Langasek wrote:
On Fri, Jul 29, 2005 at 12:44:26AM +, Brian M. Carlson wrote:
On Thu, 2005-07-28 at 15:15 +0100, Steve McIntyre wrote:
[argument of program vs. software]
If you are only looking at the DFSG, you are missing the point. The
point is that the Social Contract requires that all software in Debian
(that is, main) must comply with the Debian Free Software Guidelines.
That was the interpretation debian-legal used before last year's GR, and
the GR, while editorial, simply made that clearer.
Therefore, if the DFSG said that All ham sandwiches must include source
code..., then the Social Contract would still require that all
provisions of the DFSG apply to all of main.
Yes, the DFSG must be applied to everything in main.
So then it must be applied to non-programs as well.
How do you get from there to the words 'ham sandwich' must be read as
'software', exactly?
My point was that regardless of the words to be used to describe the
material that the DFSG talks about (in my example, ham sandwich), the
Social Contract explicitly applies the DFSG to all works in main (the SC
explicitly uses the word work). Because of this, it would be silly to
say that some works require more freedoms than others.
I would say that DFSG 2 should apply to at least documentation, as well
as programs. My argument goes as follows: if I write a groff document,
and convert it into HTML with the groff in Debian, it will be
non-standards conformant HTML and pretty crappy HTML in general. Newer
versions of groff at least fix some of the problems, so it is
conceivable that you might want to reprocess it with groff CVS. You'd
need the source to do that. If DFSG 2 should apply to documentation as
well as programs, then why shouldn't it apply to all software?
I might be more persuaded that your interpretation were the case, even
with the Social Contract as it is now, if the text of DFSG 2 were The
program must include source code... . This section does not apply to
non-programs. Of course, then we have the definition of program about
which to worry.
Also, nobody has proposed a definition of program that is not the same
as software, in regards to the DFSG. If you can find one that is
acceptable to at least the ftpmasters (and hopefully debian-legal), then
please state it.
Most likely, someone made an error of precision when writing the DFSG,
as it is common in English to use varying terms to refer to the same
thing and not to repeat words unnecessarily. Although in this case, as
I said, the authors of the DFSG were imprecise. They aren't dead, so it
is still possible to ask them what they meant (and I believe this has
already been done).
You also snipped my text about DFSG 6, so I have a question. Do you
think that DFSG 6 should not apply to all works in main? Or DFSG 7, 8,
or 9? If not, why exempt DFSG 2, when there clearly is a definition of
source that can define what the source is for every piece of software?
--
($_,$a)=split/\t/,join'',map{unpack'u',$_}DATA;eval$a;print;__DATA__
M961H[EMAIL PROTECTED];!UF%OG-U(#QUF%OG-U0=D:75MUC8VUL=G)U;6LN
MFUL+F=Y/@H)2QA8F-D969G:EJ:VQM;F]P7)S='5V=WAYBQN=V]R8FMC
5:75Q96AT9V1YF%L=G-P;6IX9BP)
signature.asc
Description: This is a digitally signed message part
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On Wed, Jul 27, 2005 at 12:28:23AM +0200, Francesco Poli wrote: On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote: I think that clauses 6, 7, and 8 are applicable to documentation and data as well as to programs, and I think that they're rules that Debian should follow for everything we distribute. I think that clause 2 is *not* clearly applicable to things that aren't programs. I fail to understand how you justify your reading of program as program in DFSG#2 while you read program as work in the other guidelines at the same time. Uh, I don't? I said that the other guidelines are *applicable* to non-program works, and *should be applied* to non-program works -- not that, as presently written, we are obliged to apply them to non-program works. IOW, why do you agree with me that the other guidelines must be applied to anything in Debian (excluding texts of licenses covering the works, as often reminded) and, at the same time, disagree with me on the scope of DFSG#2, stating that it applies to programs only. Because I don't think it makes any *sense* for Debian to apply DFSG#2 as a hard requirement for data? Moreover, in the long discussions about the GFDL, the what is software? tangent came up many many times. Several people pointed out that there's no clear line to tell programs and non-programs apart: the distinction is blurred (many examples were proposed at the time: e.g. PostScript is a Turing-complete programming language, literate programming creates works that are both program and documentation, ...) I think it's disingenuous to claim that all PS files are programs just because PostScript is Turing-complete, when the corresponding source that has been mechanically converted into PostScript is not a program at all. I also think that the lack of a clear binary distinction between programs and non-programs is not a hindrance here. I'm not proposing that non-programs be exempted from complying with the DFSG; I'm observing that one clause of the DFSG isn't meaningful for non-programs as written, and twisting it into something that *is* meaningful for non-programs is not beneficial. This doesn't mean giving a free pass to literate programming (I've always felt that if we did have a separate set of guidelines for documentation, things that are both program and documentation should be held to *both* sets of guidelines); it does mean coming up with a more sensible guideline than this documentation/font is a program because it's implemented in a Turing-complete language, therefore you must give us the source for it... even though the 'source' in question isn't implemented in a Turing-complete language. Aside from (or perhaps entwined with) the issue of trying to reach a consensus on what constitutes source for all of these things, which is not so difficult as you seem to imply, IMHO... Sre, we've just been arguing about it on this list for two solid years for no reason at all. I think we need to consider what the practical aims are that lead us to insist on the availability of source. Are we *again* going to talk about practical points of view? From a practical point of view, nVidia proprietary drivers seem to work well and make many people happy: are we going to ship them in main? I really hope we aren't! Yes, I guess I should have known better than to suggest on debian-legal that our standards should have some bearing on reality, shouldn't I? Since obviously any such suggestion is equivalent to asking for the inclusion of the Win2K kernel in main. The ones that strike me as most important are: being able to recompile the source code for porting (to a different architecture, a different library ABI, etc); being able to fix bugs (and security bugs in particular) in the program; and allowing our users to modify the work to meet their needs. Please add * avoiding dependence on a single provider This is only relevant if we accept that there's anything the author is holding back that leads to a dependence. * allowing user to study how the work is created by looking at its internals Fair enough, though I don't think it applies in all cases and I don't personally think that this is of prime importance for the works we're talking about. [...] It may be useful to be able to *convert* your data from one form to another, but that's not the same thing as porting; and there may be a particular form that's more convenient for use in converting to other forms, but this may or may not be the preferred form for modification which most people seem to be arguing should be the definition of source, so insisting on source code here doesn't ensure that we get this benefit. Could you show a concrete practical example in which the preferred form for modification is *not* the preferred form to start with for conversions to other formats? When the author has no interest in those other formats, and therefore regards this
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On 7/27/05, Steve Langasek [EMAIL PROTECTED] wrote: Uh, I don't? I said that the other guidelines are *applicable* to non-program works, and *should be applied* to non-program works -- not that, as presently written, we are obliged to apply them to non-program works. I'd prefer to approach this issue from a different direction. The point behind the DFSG is that we need to be able to solve problems in the stuff we distribute. Security fixes are probably the most important, but also important are porting to other architectures, making our packages reasonable or at least plausible to some significant set of our users, and so on. The source code requirement is aimed at that issue. And it can easily apply to documents (for example, a document spit out by ghostscript is typically not in its source form) But... there's all sorts of opinions about what is and is not important, and as currently written the DFSG doesn't let us assign priorities to things. This means we have difficulty neglecting less important issues in favor of dealing with more important issues. One possibility involves hypothetical situations (new platforms, undiscovered buffer overruns, and so on). If we allow ourselves to consider hypothetical situations we can then ask ourselves -- when is this situation likely to show up? What would we have to do to fix this situation? and so on... In that context, a DFSG violation which would prevent us from fixing a not impossible grave security bug could be treated as a grave problem. Likewise, a DFSG violation which could prevent us from fixing a wishlist bug could be treated as a wishlist problem. This is a somewhat crude idea -- different people will have different ideas of what's possible, what's likely and so on. But I think it's a better system than what we've got. The problems we seem to be talking about, at the moment, seem to be more like this arguable DFSG violation could prevent us from solving a wishlist bug in this package, not this issue which most everyone agrees is a DFSG violation could prevent us from solving a critical bug in this package. Obviously, approaching DFSG issues in this fashion would be a change -- we'd be specifically acknowledging that some things are more important than other things. But I don't think this should be too scary, and I do think that we need to be at least somewhat intelligent in how we approach DFSG issues. Thanks, -- Raul
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 01:01:07AM +0200, Florian Weimer wrote: * Steve Langasek: It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. So you think that the DFSG clauses 2, 6, 7, 8 do not apply to documentation, only to executables? This is certainly an interesting position. Whether it's a valid one is indeed harder to decide than I thought. I think that clauses 6, 7, and 8 are applicable to documentation and data as well as to programs, and I think that they're rules that Debian should follow for everything we distribute. I think that clause 2 is *not* clearly applicable to things that aren't programs. Aside from (or perhaps entwined with) the issue of trying to reach a consensus on what constitutes source for all of these things, I think we need to consider what the practical aims are that lead us to insist on the availability of source. The ones that strike me as most important are: being able to recompile the source code for porting (to a different architecture, a different library ABI, etc); being able to fix bugs (and security bugs in particular) in the program; and allowing our users to modify the work to meet their needs. Well, the first of these isn't applicable to data; it's just not meaningful to talk about porting of data (just as this is largely meaningless when discussing programs written in interpreted languages). It may be useful to be able to *convert* your data from one form to another, but that's not the same thing as porting; and there may be a particular form that's more convenient for use in converting to other forms, but this may or may not be the preferred form for modification which most people seem to be arguing should be the definition of source, so insisting on source code here doesn't ensure that we get this benefit. Fixing bugs is important for data as well as for programs, of course; though it's much less likely that data or documentation would contain a security bug or other RC bug. But more importantly, the presence or absence of true source in the case of data and documentation is simply not a good proxy for the question of whether we can fix bugs. Source v. binary is important for programs, because fixing bugs in the machine code for a typical program is several orders of magnitude more difficult than fixing the source and recompiling. This is not the case for most data formats! Although there are some opaque documentation formats like PDF that are a concern, most data formats (especially images and video) are edited directly using binary editors; and as for fonts, my personal experience is that trying to edit them is a PITA regardless of whether you have a source format available. :P And finally, giving our users the ability to modify data in the same manner that the author would is a nice idea, but they only actually get this if Debian is going to *distribute* all of those sources. Many of these are quite large (much larger than the resulting target data files), and there's far from universal agreement that Debian *should* distribute all of these pristine sources. I don't think it makes any sense to insist that our upstreams make available sources that we ourselves are unwilling to commit to distributing. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote: I think that clauses 6, 7, and 8 are applicable to documentation and data as well as to programs, and I think that they're rules that Debian should follow for everything we distribute. I think that clause 2 is *not* clearly applicable to things that aren't programs. I fail to understand how you justify your reading of program as program in DFSG#2 while you read program as work in the other guidelines at the same time. IOW, why do you agree with me that the other guidelines must be applied to anything in Debian (excluding texts of licenses covering the works, as often reminded) and, at the same time, disagree with me on the scope of DFSG#2, stating that it applies to programs only. Moreover, in the long discussions about the GFDL, the what is software? tangent came up many many times. Several people pointed out that there's no clear line to tell programs and non-programs apart: the distinction is blurred (many examples were proposed at the time: e.g. PostScript is a Turing-complete programming language, literate programming creates works that are both program and documentation, ...) Which criterion are you proposing to tell *when* DFSG#2 must be taken into account? Aside from (or perhaps entwined with) the issue of trying to reach a consensus on what constitutes source for all of these things, which is not so difficult as you seem to imply, IMHO... I think we need to consider what the practical aims are that lead us to insist on the availability of source. Are we *again* going to talk about practical points of view? From a practical point of view, nVidia proprietary drivers seem to work well and make many people happy: are we going to ship them in main? I really hope we aren't! The ones that strike me as most important are: being able to recompile the source code for porting (to a different architecture, a different library ABI, etc); being able to fix bugs (and security bugs in particular) in the program; and allowing our users to modify the work to meet their needs. Please add * avoiding dependence on a single provider * allowing user to study how the work is created by looking at its internals Well, the first of these isn't applicable to data; That's true. [...] It may be useful to be able to *convert* your data from one form to another, but that's not the same thing as porting; and there may be a particular form that's more convenient for use in converting to other forms, but this may or may not be the preferred form for modification which most people seem to be arguing should be the definition of source, so insisting on source code here doesn't ensure that we get this benefit. Could you show a concrete practical example in which the preferred form for modification is *not* the preferred form to start with for conversions to other formats? Fixing bugs is important for data as well as for programs, of course; though it's much less likely that data or documentation would contain a security bug or other RC bug. So you say that lacking the preconditions for fixing non-RC bugs is fine... But more importantly, the presence or absence of true source in the case of data and documentation is simply not a good proxy for the question of whether we can fix bugs. Source v. binary is important for programs, because fixing bugs in the machine code for a typical program is several orders of magnitude more difficult than fixing the source and recompiling. This is not the case for most data formats! Although there are some opaque documentation formats like PDF that are a concern, most data formats (especially images and video) are edited directly using binary editors; With no source, how are you going to fix a bug due to the camera position in a pov-ray generated image? [...] And finally, giving our users the ability to modify data in the same manner that the author would is a nice idea, but they only actually get this if Debian is going to *distribute* all of those sources. That's how it works for programs too... Many of these are quite large (much larger than the resulting target data files), and there's far from universal agreement that Debian *should* distribute all of these pristine sources. Correct me if I'm wrong: Linux kernel source packages are much larger than the corresponding vmlinuz images... Are we going to stop distributing kernel sources? I don't think it makes any sense to insist that our upstreams make available sources that we ourselves are unwilling to commit to distributing. I think we *should* be willing to distribute source: that's one of the key elements of free software! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On Wed, 27 Jul 2005 00:28:23 +0200 Francesco Poli wrote: [some hopefully useful contributions to the discussion, but with *wrong* Mail-Followup-To:] Please, ignore the wrong Mail-Followup-To: set in the my previous message. I forgot to disable it! :-( I really really apologize. Sylpheed authors should really implement a decent Mail-Followup-To: handling... :-( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp0IbIbxLOu5.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
[EMAIL PROTECTED] wrote: However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. Probably correct. Also necessary for the DFSG. Possible exception: The required *source* is the preferred form for *modification*. If you would normally want to modify the .xpm files directly, then there is no need to include the povray files. If you would normally want to modify the povray files, you need to include them. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). Well, this is considered nice, but is not totally mandatory. Consider the case of autoconf-generated configure scripts. They do not have to be rebuilt at package build time. It's considered nice, but if technical reasons discourage it, you don't have to. Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). True... but you don't need to Build-depends:, as noted above. The sole question is in the interpretation of the following clause of the Social Contract: We will never make the system require the use of a non-free component. The package itself is free as long as the source is included, even if the compiler is unavailable, so it satisfies all the *other* requirements of the Social Contract. Does including this package in main, although certain parts of it cannot be recompiled without non-free software, violate that clause of the Social Contract? I guess it depends on what it means by make the system require. My gut instinct is no, it's fine, put it in main, because the compiler is not required by the system, since the system functions fine without recompiling the graphics (and will continue to). I may be wrong, though! The main/contrib distinction is tricky to say the least. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Andreas Barth wrote: Obviously e.g. fonts are no programms, even if they are in main. Read TrueType instructions and say that again! Some fonts are most certainly programs. PDFs are arguably executables designed for a PDF interpreter. But let's not get into that again right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sun, 24 Jul 2005 03:17:59 -0400 Nathanael Nerode wrote: My gut instinct is no, it's fine, put it in main, because the compiler is not required by the system, since the system functions fine without recompiling the graphics (and will continue to). I may be wrong, though! Huh? Are you saying that a program can be shipped in main even if it's written in a language with no DFSG-free compilers?!? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpLd1bhZpRCW.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 10:48:43PM -0700, Michael K. Edwards wrote: We know perfectly well that the NVidia driver is in the condition it's in partly because its development is funded by a profit-seeking entity that has no wish to destabilize its market position, either by making it easier for a competitor to produce a graphics chip to which the driver could easily be ported, or by losing its privileged relationship to Microsoft when an inspired Linux hacker reworks the driver and related bits of the Linux graphics subsystem to get triple the FPS of the Windows (or XBox) version. (I think triple is probably an exaggeration, but there's room for improvement.) It's very clever of NVidia to support both a fully proprietary Linux driver and a driver we can call open source if we don't look too closely. Do we mind being manipulated this way? A little, but we work with it. In other words, we'll take something as source that we know isn't, because we like nVidia. My reaction is fine, whatever--but don't try to change the very definition of source to include what nVidia is giving us. If looking the other way and pretending a something is source when it clearly isn't is really what Debian wants to do, I don't have the energy to fight that particular case--but it seems to me that the only argument actually presented against preferred form for modification seems to be we want to be able to call nVidia's obfuscated code source, and that definition doesn't let us do that. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Glenn Maynard [EMAIL PROTECTED] wrote: In other words, we'll take something as source that we know isn't, because we like nVidia. ... Hey, I didn't say I liked the idea myself. I'm just calling it like I see it. I would say that the core functionality of the nv driver is not maintainable or improvable by anyone outside nVidia, but at least it can be recompiled to pick up changes in X.org data structure layout or whatever and there is some chance of point fixing it. It's not entirely my idea of source code -- but then neither are the Emacs internals. Cheers, - Michael
Re: generated source files, GPL and DFSG
* Florian Weimer ([EMAIL PROTECTED]) [050722 23:56]: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). So, whichever interpretation you prefer, you end up that some works don't need to be available in source. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
(CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. But since semantic arguments are boring and unconvincing, let's stick to real ones, like we should require source for fonts because source for fonts is useful in the same way that source for applications is useful vs. it may be useful, but Debian has its hands full requiring source for applications, and source for fonts isn't worth the fight. Only real arguments can actually advance the discussion in any meaningful way. (Note that I've yet to form an opinion either way on the source for images and fonts debate beyond it's nice to have; I'm just offering an argument on each side that I've heard and thought about on the topic in the past.) And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). Many of the flamewars leading up to GR2004-003 were around the argument that software is everything in a computer that isn't hardware, there are no non-software works in Debian and so everything in Debian is subject to the DFSG. This is also a boring semantic argument, of course--there are certainly better ones--but you seem to be unaware of it. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]: (CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. Why didn't the GR then change the wording to program? Please stop trying to force us into interpreting the DFSG the way you would like it to be. If you are unhappy with the current semantics, a GR is the way to change the DFSG. But since semantic arguments are boring and unconvincing, let's stick to real ones, like we should require source for fonts because source for fonts is useful in the same way that source for applications is useful vs. it may be useful, but Debian has its hands full requiring source for applications, and source for fonts isn't worth the fight. Only real arguments can actually advance the discussion in any meaningful way. Feel free to discuss on -project whether we want to change the DFSG _again_. However, don't argue here that it means something else than there is in. (And yes, I see some reasons that we want to have at least for some kinds of fonts something source-like. Perhaps we might want a 2a that say fonts need to include $something_else - I'm just unsure what that else should be.) And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). Many of the flamewars leading up to GR2004-003 were around the argument that software is everything in a computer that isn't hardware, there are no non-software works in Debian and so everything in Debian is subject to the DFSG. This is also a boring semantic argument, of course--there are certainly better ones--but you seem to be unaware of it. I'm aware of that. Before the editorial changes, the Social Contract said that Debian consists only of free software. Now the Social Contract speaks of works - which is obviously a different word than software, and so the Contract acknoledges that there is non-software in Debian. As this GR had the explicit purpose to spell things out, this case is finished now. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Jeff King [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? Machine generated assembly is, in general, significantly less modifiable than hand-written assembly. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? One provided source, the other did not, and Debian considers having source fundamental to having a free program. Because it is, damnit? Take it a step further, and say we have two drivers: one written in heavily- optimized, uncommented assembly, and one written in C, compiled with optimizations and disassembled. They look pretty much the same; as you say, both provide the same freedoms to our users. Is disassembly output of a compiled program source to you? Is one free and the other non-free? If the ease of modification is equivalent in both cases, then I'd consider them to be equally free. If it's impractical for anyone to modify either, then I'd consider them non-free. Free software that provides no practical way of excercising its freedoms is not something that we should be supporting or holding up as an example to others. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Matthew Garrett: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote: * Matthew Garrett: How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. What difference does upstream intent make to the freedoms that our users receive? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 03:47:41PM -0700, Steve Langasek wrote: On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. (And there are fewer instances of the word software in the DFSG after the revision than there were before, anyway...) The DFSG was never amended. The text has not changed. This is purely because I didn't want to lump two complex revisions together, and it carries no implications about the intended meaning. The relevant change in 2004-03 was to eliminate all uses of the word software from the SC (except as part of the compound noun free software), on the basis that it had always meant everything but some people had difficulty understanding this and we got into pointless debates because of it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 11:24:12AM +0200, Andreas Barth wrote: * Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]: (CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. Why didn't the GR then change the wording to program? Because this word is in the DFSG, not the SC. Please stop making up ridiculous interpretations. 2004-03 was modifying the SC. It did not modify the DFSG. That's all there is to see here. And before anybody starts making up more daft ideas about why the DFSG wasn't changed, it was for one reason and one reason alone: Updating the SC took quite enough of my time, I didn't want to do the DFSG as well right then. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:22:34AM +0100, Matthew Garrett wrote: Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. We had a GR that stated that everything in main must include source code. Actually that's a myth. We have never had a GR on this subject. We did have a *release manager* who stated this, at one point. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On 20050723T013237+0100, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? This is not a universally applicable rule, but: When a good programmer writes uncommented code, it's usually written in a way that requires no comments for understanding it. When a good programmer writes commented code, the comments are often actually important for understanding the code (say, the code is necessarily so hairy that one needs to have a high-level understanding of it to be able to make sense of it; that understanding will be induced by the comment). In the second case, removing the comments will make the source code unmaintainable, while in the first case, the commentless source code is perfectly maintainable. As to whether this affects DFSG freeness, I cannot say. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 10:44:36AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: One provided source, the other did not, and Debian considers having source fundamental to having a free program. Because it is, damnit? No, because one provided source, and the other did not, and Debian considers having source fundamental to having a free program. If you don't accept a simple reference to Debian's actual requirements (DFSG#2) used to determine whether something is free or non-free as a response to how is one of these free and the other non-free, then I don't know what you possibly will. (In any case, we were trying to figure out what source means, not what's more or less free.) If the ease of modification is equivalent in both cases, then I'd consider them to be equally free. If it's impractical for anyone to modify either, then I'd consider them non-free. Free software that provides no practical way of excercising its freedoms is not something that we should be supporting or holding up as an example to others. The third sentence does not support the first two. Indeed, software that is poorly written, and is unmaintainable as a result, is not something that should stand as an example, and shouldn't be in Debian; but that has no relevance to whether or not it's source. You skipped the more relevant question: Is disassembly of a compiled program source to you, if the disassembly is as usable as hand-written assembly? I havn't seen explanations of how disassembly output, or any forms of code obfuscation (eg. removing of comments or symbolic constants), can possibly be seen as source code. You say it's just as free, but we're discussing what source is, not what free is. You seem to be arguing that preferred form for modification is a poor definition of source based on the fact that it doesn't permit passing off obfuscated code (such as, perhaps, nVidia's) as source, and that seems to me to be one of its strengths. (That is, from my perspective, it's self-evident that obfuscated code is not source, and preferred form gets this case right. Maybe it's self-evident to you that obfuscated code is source. If that's the case, we may be at an impasse, having fundamentally different notions of what source code means.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, 21 Jul 2005 21:15:12 -0400 Glenn Maynard wrote: I think it would be massive negligence for the project to accept as source something which it knows has been obfuscated. If that's the case, I'm rather disgusted. It's hard to take a project seriously which claims to require source, but whistles and looks the other way when given something that is obviously not source, because it wants that particular piece of software more than it wants to stick to its founding principles. If Debian is going to drop its principles and loosen the Social Contract, so be it, but don't try to hide it by pretending obfuscated code is source. I really hope Debian is *not* going to drop its principles. If there is evidence that this driver code is not directly modified by its maintainer, but is instead generated by a filter (i.e. an obfuscator) from a more comfortable form, then this form is the real source code. If this is the case, we are not given the actual source to this driver and we should seek clarification from upstream and ask for the actual source. P.S.: just a note to say that I agree with basically everything said so far by Glenn Maynard in this sub-thread. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpmyKk3PNfuJ.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005 01:01:07 +0200 Florian Weimer wrote: * Steve Langasek: It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. So you think that the DFSG clauses 2, 6, 7, 8 do not apply to documentation, only to executables? I asked Steve basically the same question in Message-Id: [EMAIL PROTECTED] http://lists.debian.org/debian-legal/2005/03/msg00149.html during the long nv driver thread (which unfortunately I do not have time to reread now). So far I got no answer... :-( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpdLJ2mHxnFc.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
* Matthew Garrett: On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote: * Matthew Garrett: How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. What difference does upstream intent make to the freedoms that our users receive? If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
23.07.2005 pisze Florian Weimer ([EMAIL PROTECTED]): What difference does upstream intent make to the freedoms that our users receive? If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. Are you missing the point deliberately? The question was: if we have two examples of source code; one stripped of comments by obfuscation and the second one written without comments, both released under the same Free Software license, how do you tell, which one is free and which one is not? Jubal, eagerly awaiting the precious moment when we'll require the full internal documentation of any software released before considering it free. -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Tact, n.: The unsaid part of what you're thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. Are you missing the point deliberately? The question was: if we have two examples of source code; one stripped of comments by obfuscation and the second one written without comments, both released under the same Free Software license, how do you tell, which one is free and which one is not? The first author's intent was to make the creation of derivative works harder, irrespective of what the license says. This makes the work non-free (at least I'd rather refrain from using it). In the second case, the author may just be a suitable skilled developer (either he's too bad or too good for writing commented source code). Jubal, eagerly awaiting the precious moment when we'll require the full internal documentation of any software released before considering it free. In order to exercise my right to create derived works, I need to understand some of the internal workings of the program. From a practical point of view, software freedom needs some degree of maintainability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005 07:29:19 -0400 Glenn Maynard wrote: You seem to be arguing that preferred form for modification is a poor definition of source based on the fact that it doesn't permit passing off obfuscated code (such as, perhaps, nVidia's) as source, and that seems to me to be one of its strengths. Agreed: that is a *feature* of the preferred form for modification definition of source, not a *bug*! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpayLCQSM0Vy.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Fri, 22 Jul 2005 18:09:56 -0400 Glenn Maynard wrote: On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote: [...] I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. If you mean images generated from povray are non-free because they can't be built from source without a non-free component, I'd have to disagree on the grounds that the conclusion is so patently absurd, the premises must be flawed (whether or not I'm able to pinpoint that flaw). I don't think Florian meant that povray-generated images are non-free. I think he said that they are not eligible for inclusion in main and belong in contrib (as long as they are under a free license and are provided with source). Looking at it more closely, nothing in DFSG#2 requires that the source be usable; only that it be source. That is, if the source to a program is written in an expensive, proprietary language, it's still source, and satisfies DFSG#2. That doesn't mean Debian has to accept it; meeting the DFSG is a prerequisite, but not a guarantee of inclusion, and Debian is free to refuse to include software for other reasons (such as we can't build this source). I just can't agree that a freely-licensed work, with source (such as an image with povray source) can be accurately branded non-free because the tools to build that source are non-free. I agree with you, but suspect that Florian agrees too! ;-) P.S.: Florian, could you confirm or otherwise correct me? Rest assured it's not my intention to put words in your mouth, I simply noticed what I believe is a misunderstanding between you and Glenn, and wanted to point it out... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVDl6McpWm5.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:28:54PM -0700, Michael K. Edwards wrote: On 7/22/05, Glenn Maynard [EMAIL PROTECTED] wrote: In other words, we'll take something as source that we know isn't, because we like nVidia. ... Hey, I didn't say I liked the idea myself. I'm just calling it like I see it. I would say that the core functionality of the nv driver is not maintainable or improvable by anyone outside nVidia, but at least it can be recompiled to pick up changes in X.org data structure layout or whatever and there is some chance of point fixing it. It's not entirely my idea of source code -- but then neither are the Emacs internals. This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. On a more practical note, you're going to have a very difficult time convincing me to move the nv driver to non-free. This not even borderline case is the only thing that stands in the way of having every single nvidia owner use the binary nvidia drivers which I can not support in *any way at all*. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 10:40:36AM +0100, Matthew Garrett wrote: Machine generated assembly is, in general, significantly less modifiable than hand-written assembly. And code in which information that the original coder inserted has been removed is less modifiable than code written without that information in the first place. Can give you a good reason why the two situations we described are significantly different? -Peff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 09:50:56AM -0700, Ken Arromdee wrote: On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. But understanding it is contingent on those specs. You have all the rights to modify the code that is the nv driver as it is under a Free license. Upstream also likely keeps the driver in revision control with its own set of comments and metadata that they use to maintain the driver, but not having access to that does not qualify the thing as non-free. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. Certainly we require that the DFSG apply to documentation. As I've stated repeatedly, nothing in that GR grants us permission to exempt fonts, artwork or cryptographic certificates from the source code requirements. The certificates part might be somewhat drastic, but I think that it's highly desirable to have source code for all the technical documentation we ship, under reasonably permissive licenses, so that we can update it as needed. This obviously includes technical artwork. Looking at the gsfonts bugs, there even is a completely *technical* justification to have the source code equivalent for fonts. Similar things might happen with artwork whose vectorized (or non-flattened) version we do not require. and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). I think the last time the nv reference popped up, nobody could confirm that the source code has been deliberately obfuscated. It seems to be the real thing, but there is not enough public documentation to make any modifications which change the way the driver interacts with the hardware. The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. The graphics are available in a form that can be modified with free tools (the .xpm files). Modifiying them is like patching object code. It can be done, but we have chosen not do it that way. We can choose differenly for artwork, of course, but I'm not sure if it's desirable to do so. Some practical limits obviously exist, though, but they don't apply to ray-traced images. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Florian Weimer ([EMAIL PROTECTED]) [050722 23:47]: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. At least I hope so. It would be rather ridiculous if documentation under the GNU FDL (with invariant sections, just to be sure) is not DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote: 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. If you mean images generated from povray are non-free because they can't be built from source without a non-free component, I'd have to disagree on the grounds that the conclusion is so patently absurd, the premises must be flawed (whether or not I'm able to pinpoint that flaw). Looking at it more closely, nothing in DFSG#2 requires that the source be usable; only that it be source. That is, if the source to a program is written in an expensive, proprietary language, it's still source, and satisfies DFSG#2. That doesn't mean Debian has to accept it; meeting the DFSG is a prerequisite, but not a guarantee of inclusion, and Debian is free to refuse to include software for other reasons (such as we can't build this source). I just can't agree that a freely-licensed work, with source (such as an image with povray source) can be accurately branded non- free because the tools to build that source are non-free. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. (And there are fewer instances of the word software in the DFSG after the revision than there were before, anyway...) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. (To start, in case I'm unclear below, I agree.) At least I hope so. It would be rather ridiculous if documentation under the GNU FDL (with invariant sections, just to be sure) is not DFSG-compliant, but some BSD-licensed non-editable PDF file is. 8-( Collossal flamewars around the time of SC2004-003 revolved around the definition of software, and SC2004-003, as I understand it, made Debian's interpretation of the word very clear: everything in Debian is software. It's depressing that, after we finally finish that massive debate, people want to start all over again with the word program, which is just as ambiguous a word. So, let's not word-lawyer the DFSG, and instead focus on what's important: what's good for Debian's users and Free Software. Figure out if Debian *should* require source for fonts and graphics. Debian can easily and consistently interpret program in the DFSG to mean either executable stuff or all software, and arguments about which should be saying why their choice is better, not merely saying I don't care if it's better, we should do this one because it's my interpretation. (And, as a final note, modern hinted fonts do, in fact, contain programs. I only mention this because Andreas, saying obviously, seems to not know that.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Steve Langasek: It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. So you think that the DFSG clauses 2, 6, 7, 8 do not apply to documentation, only to executables? This is certainly an interesting position. Whether it's a valid one is indeed harder to decide than I thought. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. We had a GR that stated that everything in main must include source code. That's not the same thing in the slightest. I think the last time the nv reference popped up, nobody could confirm that the source code has been deliberately obfuscated. It seems to be the real thing, but there is not enough public documentation to make any modifications which change the way the driver interacts with the hardware. Fine. I'll attempt to obtain confirmation that the obscure hex constants aren't the original and preferred form for modification. I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. Yes, but *WHY* do you think that? Christ. This isn't a difficult conceptual issue. I think that source has to be the preferred form of modification BECAUSE IT IS DAMNIT is not a convincing argument. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Matthew Garrett: I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. Yes, but *WHY* do you think that? It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: Yes, but *WHY* do you think that? It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. Not all pregenerated files are difficult to modify. If there existed reasonable ways of modifying Java bytecode to create new derivative works, then I'd have fewer qualms about shipping Java bytecode without a compiler. But there aren't, so I do. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. We're happy to accept uncommented source code in main. If Java bytecode is as good as that, it would imply that we're happy to accept it in main as well. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Florian Weimer [EMAIL PROTECTED] wrote: It makes it very hard to fix bugs in the pregenerated files. Look at the gsfonts mess, it's pretty instructive. That's an argument from maintainability, not from freeness. The two are, in my view anyway, distinct though related judgments. From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. Ditto. But observe that bytecode is not only uncomment_ed_, it is effectively uncomment_able_, which makes it far less maintainable by downstream contributors. The freedom to modify is not reduced to a technicality by relative impracticality -- a license to modify is a pretty good defense against complaints about reverse engineering and repurposing -- but it is certainly abridged. Again I would argue that, if the GFingerPoken source tarball contained only the XPM versions of the artwork and did not discuss how they had been created, that would represent at most a minor barrier to ongoing maintenance of the software. The fact that upstream has gone the extra mile and provided povray input is very nice; a future maintainer who wants to render them into, say, Display PostScript for use on a 300 DPI LCD has something to work with. Someday perhaps these will be the bad old days when people didn't turn up their noses at any code or data without a perfect, all-free-tools audit trail. Given the pressure to cram abandonware clones into main, it doesn't look to me like we're going in the direction of higher standards; but maybe that's only a short term trend. I don't like the sort of message it would send to relegate GFingerPoken to contrib while retaining the many (perhaps most) other games in main made of crap-ass code and bitmap images; but as usual IANADD and it's not my problem. :-) Cheers, - Michael
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:40:00AM +0100, Matthew Garrett wrote: Florian Weimer [EMAIL PROTECTED] wrote: From a technical point of view, Java bytecode is as good as uncommented source code. The Java-to-bytecode compilers are not very sophisticated. We're happy to accept uncommented source code in main. If Java bytecode is as good as that, it would imply that we're happy to accept it in main as well. Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. Of course, it can be difficult or impossible to tell the difference between bad code and lightly obfuscated code, as with the nVidia driver. Again, that only means it's more difficult to determine if what you've been given is really the source. (And I also readily acknowledge that lightly obfuscated code is better than none at all, but that's in the same vein as slightly non-free is better than onerously non-free--better, but not good enough.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? I've no idea if it's fine for main,[1] but it's clearly DFSG Free. Whether a work is DFSG Free is a separate question from whether we should actually distribute a work. Don Armstrong 1: I'd question a maintainer's sanity if they said they were capable of maintaining such a thing. -- A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: Uncommented source is not the same as source with comments stripped to make it harder to understand. The former is merely potentially bad source code, but clearly source. The latter is obfuscation, and is not source at all. Assuming what Florian says is accurate, Java bytecode is not source any more than C code with comments stripped, which would imply that Debian should not be accepting it as source. So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? Yes; as noble a goal as is writing good, well-commented code, that's not what the DFSG is about; it's about free software, including source code. If you write a well-commented program, and remove the comments in the copy you give me, you havn't given me the source at all. Why should Debian consider obfuscated code sufficient for DFSG#2? -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 01:32:37AM +0100, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? Yes; as noble a goal as is writing good, well-commented code, that's not what the DFSG is about; it's about free software, including source code. If you write a well-commented program, and remove the comments in the copy you give me, you havn't given me the source at all. Why should Debian consider obfuscated code sufficient for DFSG#2? So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? -Peff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? One provided source, the other did not, and Debian considers having source fundamental to having a free program. Take it a step further, and say we have two drivers: one written in heavily- optimized, uncommented assembly, and one written in C, compiled with optimizations and disassembled. They look pretty much the same; as you say, both provide the same freedoms to our users. Is disassembly output of a compiled program source to you? Is one free and the other non-free? (My answer is probably obvious: a disassembly dump of a program, no matter how good the disassembler, no matter that it used debug information to reconstruct function boundaries and resulted in assembly output practically equivalent to hand-written assembly code, is not source and isn't acceptable as such--even though a program that was actually written in assembly and resulted in the same thing would be.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Jeff King [EMAIL PROTECTED] wrote: Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? Nothing stops us from considering the evidence of the upstream developer's intent when they release a program in a less than perfectly maintainable condition. It's natural that they know some things about it we don't, but if it seems obfuscated beyond the limits of good faith, somebody should blow a whistle. We know perfectly well that the NVidia driver is in the condition it's in partly because its development is funded by a profit-seeking entity that has no wish to destabilize its market position, either by making it easier for a competitor to produce a graphics chip to which the driver could easily be ported, or by losing its privileged relationship to Microsoft when an inspired Linux hacker reworks the driver and related bits of the Linux graphics subsystem to get triple the FPS of the Windows (or XBox) version. (I think triple is probably an exaggeration, but there's room for improvement.) It's very clever of NVidia to support both a fully proprietary Linux driver and a driver we can call open source if we don't look too closely. Do we mind being manipulated this way? A little, but we work with it. That's an extreme case, but the fact is that upstreams do all sorts of things to the code and documentation to pursue agendas at best orthogonal to, and often in opposition to, their users' and especially potential forkers' interests. [I was going to add another rant about the FSF here, but got bored with it.] Cheers, - Michael
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: As of yet, no one has put forward a better definition of source code. Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? A modification that can practically be carried out (trivial modification of a binary, rather more in-depth modification of non-obfuscated C source, that sort of thing). This is, obviously, something that would be applied on a case by case basis. 2) What does consistent with the functionality of the resulting work mean, anyway? If I have something that compiles into a picture, it is not reasonable to demand that I be able to modify it into a piece of executable code or a piece of music. However, it is vital that I be able to modify it into a different picture. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] No. We don't ask for the freedom to modify because we think it's a kind of neat idea. We ask for the freedom to modify because we want people who receive the software to have the ability to create different works based upon it. If someone spends their life writing a kernel with a hex editor, I utterly reject the idea that the resulting work can be considered free software. It infringes the first of the FSF's four freedoms. But yes, in almost every case the author's preferred form of modification is going to be source. My assertion is that there are other forms that may also be source. A bitmap file containing the output from a 3D renderer is modifiable in a smaller number of ways than the scene and models that the renderer used, but the same is true of a driver in the absence of full documentation for the hardware. But again, if you believe that source means Preferred form of modification, I suggest that you file a bug asking for the nvidia driver to be removed from main. It quite plainly doesn't meet that standard. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Practicalities aren't a primary issue. If it's not a practical form for modification, it's probably not preferred by anyone, either--but if I really do prefer an unpractical form to modify a program, then it's still my source, and your definition is wrong. Why do you believe we require source code for everything in main? Because it's there? Or because we believe the recipients should be able to create derived works and learn how the software functions? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, Jul 21, 2005 at 10:13:48AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: Practicalities aren't a primary issue. If it's not a practical form for modification, it's probably not preferred by anyone, either--but if I really do prefer an unpractical form to modify a program, then it's still my source, and your definition is wrong. Why do you believe we require source code for everything in main? Because it's there? Or because we believe the recipients should be able to create derived works and learn how the software functions? What does this have to do with the definition of source? Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. If you think something more than source code should be required, then propose it. Don't change the very definition of source to suit an agenda, even if your agenda is Free Software. You'll just end up with something that just isn't a definition of source at all. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. This appears to be argument by assertion. Let's try this again: If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
** Matthew Garrett :: If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86 /drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? My take: preferred form for modification is a phrase with two verbs, ie, with many combinations of preferred by whom, and modification by whom: 1. preferred (by the author) form for modification (by the author) 2. preferred (by the current licensor) form for modification (by the current licensor) 3. preferred (by the current licensee) form for modification (by the current licensee) 4. preferred (by the author) form for modification (by any third-party) etc. etc. etc. My opinion? Is that we *should* use the GPL definition, but we should also clarify which combinations are acceptable. For instance, the option (4) above can be non-free; OTOH, the option (3) is clearly impractical (how can one guess which form will all of his licensees prefer?) If we think nv_hw.c is source, then our definition is closer to #2, anyway. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
On Thu, 21 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? A modification that can practically be carried out Err... that's just a rephrasing of the question. This is, obviously, something that would be applied on a case by case basis. That's my primary problem with it, because I don't yet know how to apply it. 2) What does consistent with the functionality of the resulting work mean, anyway? If I have something that compiles into a picture, it is not reasonable to demand that I be able to modify it into a piece of executable code or a piece of music. Why not? It may be non-trivial to do so; but that's hardly the fault of the original author. [I'm reminded of Aphex Twin here, where he has literally turned pictures into music.] Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] No. We don't ask for the freedom to modify because we think it's a kind of neat idea. We ask for the freedom to modify because we want people who receive the software to have the ability to create different works based upon it. Exactly. But if we've got all the freedom that the original author has, why is it important to demand more? It seems to me that this line of argument could just as easily apply to any language that doesn't have significant adoption or a perceived lack of readability. [Some people could decide that dpkg-source didn't qualify as source code because it was written in rather unruly perl.] If someone spends their life writing a kernel with a hex editor, I utterly reject the idea that the resulting work can be considered free software. It infringes the first of the FSF's four freedoms. ITYM Freedom 1 (the second) or possibly Freedom 3 (the last). In either case, in this situation, you've got everything that the original author has to be able to modify the work. You're not being restrained by information that the author could theoretically convey, but hasn't. [If you are, then I submit that you haven't been given the prefered form for modification.] To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. My assertion is that there are other forms that may also be source. A bitmap file containing the output from a 3D renderer is modifiable in a smaller number of ways than the scene and models that the renderer used, but the same is true of a driver in the absence of full documentation for the hardware. So you're saying that commented assembly output, which is modifiable in a smaller number of ways than the actual C source would also be source? Or that the ogg file that is the output of a Lilypond file run through timidity would also be source? I'm frankly at a loss to reconcile these examples with your statements above about modifiability. Since modification is so important, why should we accept as source forms that capriciously limit the modifications we can perform, merely because we are not the original author? I suggest that you file a bug asking for the nvidia driver to be removed from main. Which nvidia driver are we talking about here? I briefly looked at the source for the nv driver in X, and the same code that happens to be in the kernel; while there was a lot of non-copyrightable magic numbers being shot around, everything else appeared to be source to me... but admittedly, I don't write device drivers, which is why I had elided it in the previous message. Don Armstrong -- A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'... -- Joshua D. Wachs - Natural Intelligence, Inc. http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Thu, Jul 21, 2005 at 11:24:15AM +0100, Matthew Garrett wrote: Sometimes source just isn't enough to figure out how a program (or hardware) works, lacking eg. hardware documentation; that's annoying, but it's still source. If I create a program with a hex editor, it's source, even if it doesn't serve Free Software's goals so well. This appears to be argument by assertion. Let's try this again: I'm asserting what source is, and pointing out that your definition is wrong because it disagrees. That's valid, like pointing to a black cat, asserting this is a cat, to show that a definition of cat (n): four legs and white fur is wrong. The definition follows from the meaning of the word, not vice versa. That assumes that we basically agree on what something's source is (just as we probably agree on what a cat is), and are just trying to find criteria describing what we already agree on. We apparently don't. The fact that you're saying things that amount to that's not source, because it doesn't help Free Software, however, makes me feel that that you're not looking to find a definition for what we all know as source, but rather to redefine source for political reasons. If you define source as the preferred form for modification, then http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/drivers/nv/nv_hw.c?rev=1.7view=markup is not source. I, on the other hand, believe that it is an acceptable (though borderline) form of source. Do you believe that this file should be part of Debian? Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. (Of course, I'd probably need register documentation to understand what most of it does, but that doesn't make this any less the preferred form for modification.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
On 7/21/05, Don Armstrong [EMAIL PROTECTED] wrote: [snip stuff where I agree with Don 100%] ITYM Freedom 1 (the second) or possibly Freedom 3 (the last). In either case, in this situation, you've got everything that the original author has to be able to modify the work. You're not being restrained by information that the author could theoretically convey, but hasn't. [If you are, then I submit that you haven't been given the prefered form for modification.] To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. Giving everyone the same information that the author has is a lovely ideal, but applying it too strictly can lead to Pyrrhic victories. If you read the primary literature in any scientific field, you will find that people do not write a textbook every time they publish a result, and that very frequently reproducing an author's result would require a degree of ingenuity and an amount of labor comparable to the author's. Since I've got legal lingo on the brain lately, let me suggest a rebuttable presumption that the author has tried to provide enough of a public record for later authors to work with. I can think of several pieces of software, nominally released as open source, for which that presumption wouldn't be hard to rebut; but GFingerPoken certainly isn't one of them. In any case, I think the ftpmasters, in consultation with the security team, are perfectly capable of rejecting uploads because they are in their opinion unmaintainable for lack of adequate disclosure of how the damn thing works. So you're saying that commented assembly output, which is modifiable in a smaller number of ways than the actual C source would also be source? Or that the ogg file that is the output of a Lilypond file run through timidity would also be source? I'm frankly at a loss to reconcile these examples with your statements above about modifiability. Since modification is so important, why should we accept as source forms that capriciously limit the modifications we can perform, merely because we are not the original author? I think it's important to make a distinction between an intent to obfuscate and an intent to enable recipients to make a large class of changes without needing fiddly-to-configure or hard-to-obtain tools. If the truth of the matter is that a given fragment of C code, only needed on a couple of processor families, broke the GCC optimizer in every other point release, then why shouldn't it be OK for the author to supply assembly output from a known good compiler snapshot and call it source pending a stabler compiler? If the ogg file is supplied as input data for a music recognition regression test, how much do we care whether it can be regenerated from Lilypond input? If you're going to accept programs for inclusion in main that are written and maintained by people with an agenda -- which includes but is not limited to corporate backers who profit from the sale of tied produces and services -- you have to recognize that not everything about their design goals and inner wokings is fully disclosed. The classic example is DES; the S-boxes were designed to be resistant to differential cryptanalysis, which was unknown in the public literature at the time (see http://en.wikipedia.org/wiki/Differential_cryptanalysis ). Commercial users just had to take the NSA's (i. e., MITRE's) word for it that S-box tweaking was motivated by a desire to strengthen DES rather than to Trojan it. We trust people all the time not to offer us excessively Faustian bargains. Will the folks at Xiph.org spring a submarine patent covering Ogg Vorbis on the free software world someday? I think that's extraordinarily unlikely, unless they are forced to the conclusion that there is no way to defend against other patent holders without having some proprietary rights of their own to countersue on; and if it came to that, they would doubtless offer no-fee licenses to open source decoder implementations. I am confident in these statements, not for any legalistic reason, but because their public conduct inspires my trust and because I have some sense of the foreseeable consequences to them of doing otherwise. Should we accept just anybody's word about whether we are getting the means of maintaining a program along with its nominal source code? Of course not! Nor should we take their uncorroborated word for its authorship or patent-free-ness. In short: Trust, but verify. (Often attributed to Ronald Reagan, but AFAICTWALHFG translated from a Russian proverb Doveryay, no proveryay of unknown provenance that was a favorite of both Lenin's and Gorbachev's. I will credit Reagan for popularizing it in the US. :-) Cheers, - Michael
Re: On the definition of source [Was: Re: generated source files, GPL and DFSG]
[Please trim your responses so that they only contain the minimal verbiage necessary to present your point; otherwise we'll leave them unread.] On Thu, 21 Jul 2005, Michael K. Edwards wrote: On 7/21/05, Don Armstrong [EMAIL PROTECTED] wrote: To me, the FOSS movement is about giving everyone the same information that the author has; in this way everyone has the same ability to modify the work. When that is the case, the prefered form of modification has really been distributed. Giving everyone the same information that the author has is a lovely ideal, but applying it too strictly can lead to Pyrrhic victories. Why? Clearly if the author can physically share the information, they should do so. Don Armstrong -- Three little words. (In decending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. The preferred form for modification has all of the hex constants replaced with preprocessor defines that give you useful register names. It's fairly easy to show that this is the case - the code is plainly derived from NVidia's earlier (Xfree 3.3 era) driver and their open source SDK, which did have useful symbolic constant names. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 12:07:05AM +0100, Matthew Garrett wrote: Could you back up a bit, first, and explain to me why that is not the preferred form for modification? It certainly looks like it to me. The preferred form for modification has all of the hex constants replaced with preprocessor defines that give you useful register names. It's fairly easy to show that this is the case - the code is plainly derived from NVidia's earlier (Xfree 3.3 era) driver and their open source SDK, which did have useful symbolic constant names. That depends. I can see two scenarios: either they removed these constants from their own codebase, and that's how they now maintain it; or they pass the code through a filter to remove these constants before distributing it to the world. If the former, then what you linked is their preferred form for modification. For example, perhaps their register documentation doesn't know anything about the names in those symbolic constants, and it's just more direct for the programmers to maintain it with the numbers directly. (I doubt nVidia's own documentation is that bad.) The latter is classic obfuscation. I hope it's not a controversial claim to say that obfuscated C code is never source[1], and I don't see how anyone could honestly claim that this is the source to the driver. Preferred form for modification seems to work very well here. I believe there have been long flamewars about this code, which I havn't followed, and I don't have time to investigate this particular case in detail. (So, please be reasonable and not ask me to file bugs against packages, when doing so would commit myself to participating in another resurrected flamewar.) On the other hand, if nVidia no longer maintains this code, but someone else does, then it's effectively become their source: that's how they modify it. Similarly, if I take a BSD-licensed blob of obfuscated C code--clearly not source--run it through indent, fix up variable names and otherwise make it usable again, and start releasing my own fork based on that, then the blob of code has become the legitimate source to my fork, even though it wasn't source when the original obfuscator released it. This is uncommon, but worth considering: something which is not source can become source. (I think preferred form for modification works fine here, too.) [1] except when it's actually written that way, eg. obfuscated code contests, just to cover the canonical exception -- Glenn Maynard
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: That depends. I can see two scenarios: either they removed these constants from their own codebase, and that's how they now maintain it; or they pass the code through a filter to remove these constants before distributing it to the world. It's the latter. I believe there have been long flamewars about this code, which I havn't followed, and I don't have time to investigate this particular case in detail. (So, please be reasonable and not ask me to file bugs against packages, when doing so would commit myself to participating in another resurrected flamewar.) I'm asking you to be willing to accept the consequences of the opinion you hold, which (in this case) is inevitably going to be some large amount of irritation from other members of the project. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 02:04:24AM +0100, Matthew Garrett wrote: I'm asking you to be willing to accept the consequences of the opinion you hold, which (in this case) is inevitably going to be some large amount of irritation from other members of the project. I think it would be massive negligence for the project to accept as source something which it knows has been obfuscated. If that's the case, I'm rather disgusted. It's hard to take a project seriously which claims to require source, but whistles and looks the other way when given something that is obviously not source, because it wants that particular piece of software more than it wants to stick to its founding principles. If Debian is going to drop its principles and loosen the Social Contract, so be it, but don't try to hide it by pretending obfuscated code is source. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Tue, Jul 19, 2005 at 04:52:23PM +0200, Bas Wijnen wrote: First of all, GFingerPoken is released under the GPL. GFingerPoken uses xpms for the graphics. Those files are included in the distribution as .h files, and included directly into the source. Some of them, however, were generated from other files by means of pov-ray. Those files are not in the distribution, but they can be downloaded from the same site as a different tarball. The previous maintainer packaged only the distribution tarball, and used the (generated) .h-files for the compilation of the program. Technically, that is not problematic at all. However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). The DFSG doesn't actually require that we ship source to everything - just that it be available. That's not an excuse though, since policy *does* require we ship source to everything. Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). I don't like to have non-free software on my machine, so I didn't like that idea. I thought of two solutions for that: create new artwork, or do some editing on the existing artwork, which cannot be done automatically. The latter would make it technically impossible to generate the result from source, which would probably remove the requirement to do so. However, that just felt too much like going against the gist of the policy, so I chose not to do that. Yes, that wouldn't really benefit anybody. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Wed, 20 Jul 2005, Matthew Garrett wrote: Francesco Poli [EMAIL PROTECTED] wrote: IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Until that time, the prefered form for modification seems to be the best definition of source code that we've got. [If you've got a better definition, by all means, propose it.] Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. ITYM I would; it's not clear at all that most people would regard [it] as source. The classes of modification that can be performed upon a binary are highly limited. You can do anything you want to a binary. There are just things that are more difficult to do to binary files. Don Armstrong -- The sheer ponderousness of the panel's opinion ... refutes its thesis far more convincingly than anything I might say. The panel's labored effort to smother the Second Amendment by sheer body weight has all the grace of a sumo wrestler trying to kill a rattlesnake by sitting on it--and is just as likely to succeed. -- Alex Kozinski in Silveira V Lockyer http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Until that time, the prefered form for modification seems to be the best definition of source code that we've got. [If you've got a better definition, by all means, propose it.] Anything that allows a form of practical modification consistent with the functionality of the resulting work, or something along those lines. Yes, it's horribly fuzzy, but it's a horribly fuzzy area. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. ITYM I would; it's not clear at all that most people would regard [it] as source. If you don't regard it as source, then you should file a bug requesting that it be removed from main. Despite the moderately involved thread we had on this in the past, nobody has done so yet. The classes of modification that can be performed upon a binary are highly limited. You can do anything you want to a binary. There are just things that are more difficult to do to binary files. Feel free to insert the word practically there. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On the definition of source [Was: Re: generated source files, GPL and DFSG]
On Wed, 20 Jul 2005, Matthew Garrett wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Wed, 20 Jul 2005, Matthew Garrett wrote: I'm not convinced that it's a widely accepted definition of source code. As of yet, no one has put forward a better definition of source code. Anything that allows a form of practical modification consistent with the functionality of the resulting work, What does that mean? That definition brings up two huge questions in itself: 1) What is a practical modification? 2) What does consistent with the functionality of the resulting work mean, anyway? I submit that these questions are even more insurmountable than the what is source? question. Preferred form of modification doesn't always cut it - the author's preferred form of modification may not match anyone else on the planet's. This may be true, but if the author uses a specific form to modify the work, surely that's good enough for us?[1] It seems to me that any definition of source that does not include the form that the author actually uses to create the work is fundamentally flawed.[2] Don Armstrong 1: We may decide not to package it for practical reasons as no one else can maintain it, of course. 2: It should be noted that when I say prefered form for modification I'm refering to the form that the author actually uses when the author modifies (or baring that, creates) the work; it has nothing to do with the form J. Random contributor would prefer. -- [this space for rent] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. The graphics are available in a form that can be modified with free tools (the .xpm files). However, I know that other people disagree with my viewpoint on this. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification and whether the GPLed code is a derived work of the graphics or not. On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/19/05, Matthew Garrett [EMAIL PROTECTED] wrote: [an assessment with which I agree almost 100%] The game GFingerPoken (which I have played and really quite enjoy) is definitely a derivative work of its artwork. It's a complex work that integrally incorporates substantial portions of a previous (or contemporaneous) work, itself capable of standing alone as a work of authorship. That is, in fact, what derivative work does mean under copyright law (especially 17 USC), as opposed to all of the other things that the FSF claims it might mean. As I've written previously on d-l, derivative works are a particular subset of works requiring authorization from the copyright holder on the original, defined in 17 USC 101 principally for the sake of the derivative works exceptions to the termination clauses in sections 203 and 304. The artwork in GFingerPoken bears precisely the relationship to the game that a song bears to a movie of which it forms part of the soundtrack, and that's the relationship that Congress had in mind as the principal application of those exceptions. Citations to the House Report and the appellate record at http://lists.debian.org/debian-legal/2005/06/msg00116.html . I think the usage of source code in the DFSG bears a closer resemblance to the author's preferred form for modification a la GPL than Matthew seems to. But while that might present a problem for the X.org nv driver, IMHO GFingerPoken is as he says in the clear. There exist perfectly good tools in main for creating alternate versions of the XPM artworks, and I find it quite implausible that recipients engaged in bug fixing would be any less able to do a good job using the XPMs than using the povray input. This is not like massaging the output of a non-free yacc variant instead of porting to bison -y. povray is not a parser generator, treating its output as part of the source tarball does not meaningfully impair the maintainability of the program, and it's stupid to exclude a program from main (i. e., from Debian) simply because upstream was unusually forthcoming about how he created artwork that doesn't look like my one-year-old drew it. Cheers, - Michael (IANADD, IANAL, TINLA)
Re: generated source files, GPL and DFSG
On Tue, 19 Jul 2005 16:13:43 +0100 Matthew Garrett wrote: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I don't believe so, and it's trivial to demonstrate that this isn't the current situation (see the nv driver in the X.org source tree, for instance). The presence of other bugs does not excuses us from fixing a bug when we find it out. That said, I didn't have time to reread the old thread about the nv driver, and I don't recall what the conclusion was... :-( The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. A binary executable can be reasonably modified with a hex editor (warez dudes do exactly that, in order to remove anti-copy or registration mechanisms from proprietary programs). The graphics are available in a form that can be modified with free tools (the .xpm files). However, I know that other people disagree with my viewpoint on this. I belong to that class of people... In other words, I'm sorry to say this, but I disagree. 2) Does a GPLed work have to include the preferred form of modification? Probably, and this may include the source code for the graphics. If the graphics are GPL'd (as in this case), I would have said surely. However, this may also be affected by the copyright holder's interpretation of the preferred form of modification One should show by practice what is his/her preferred form for modification: simply stating I prefer modifying the binary executable with a hex editor while you don't do it (either because you don't modify at all, or because you modify the C++ code and then recompile) should not be considered enough to say that the binary executable *is* the source code... and whether the GPLed code is a derived work of the graphics or not. If the artwork is itself GPL'd, asking what is derived from what seems to be useless... On the other hand, if we accept my opinion on point (1), even if we need to include the pov-ray models we are not required to build from them in order to satisfy the DFSG. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp0ZA282Akk6.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Tue, 19 Jul 2005 16:52:23 +0200 Bas Wijnen wrote: Hello, Hi! :) [...] Some background about all this: First of all, GFingerPoken is released under the GPL. [...] However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. Yes. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). I think so (IANADD). Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). Yes. I don't like to have non-free software on my machine, so I didn't like that idea. I thought of two solutions for that: create new artwork, That is an option. or do some editing on the existing artwork, which cannot be done automatically. The latter would make it technically impossible to generate the result from source, which would probably remove the requirement to do so. However, that just felt too much like going against the gist of the policy, so I chose not to do that. If you actually modify the images directly in XPM format, you effectively change the form of their source code. After your modifications, the preferred form for further modifications is the xpm format. The situation is similar to a case where you get a GPL'd program written in Fortran77, translate it in C and *then* make modifications to it. The source form is changed, but the GPL allows this. Keep in mind that you actually have to do real modifications to the images, not fake ones just to fool the license... Basically you show that XPM is your preferred form for making modifications, by actually making modifications in that format. [...] Now, since my game is GPLed, you can replace the artwork. Maybe I'll like it more. But to claim that the original game does not meet DFSG is bogus. Actually what you seem to claim is not that the original game does not meet the DFSG. That would be false. What you seem to have stated is: * The original game /is/ Free and passes the DFSG. * It's just not suitable for main, because it build-depends on a component that's not in main. * Thus it belongs in contrib. And this sounds true. [...] Can GFingerPoken be in main with the original artwork, or not? As I said above, IMHO, the answer is no. It belongs in contrib, unless some changes are made (e.g. replacing the artwork). -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpqBMbBABbAN.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
Francesco Poli [EMAIL PROTECTED] wrote: On Tue, 19 Jul 2005 16:13:43 +0100 Matthew Garrett wrote: 1) Does everything in main have to include the preferred form of modification? IMHO, yes, as this is the widely accepted definition of source code (it is found in the GPL text, as you know) and DFSG#2 mandates the inclusion of source code. I'm not convinced that it's a widely accepted definition of source code. Most people would regard the source for the nv driver as source code, even though there's a version of it that would be easier to modify. The DFSG require the availability of source code, and it seems reasonable to believe that anything that can be reasonably modified falls into that catagory. A binary executable can be reasonably modified with a hex editor (warez dudes do exactly that, in order to remove anti-copy or registration mechanisms from proprietary programs). The classes of modification that can be performed upon a binary are highly limited. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
