Re: distributing precompiled binaries
Dave Howe wrote: MJ Ray wrote: So where did the above PDF and PS are programming languages argument come from? References, please! PDF and PS *are* programming languages, and quite powerful ones. However, they are entirely interpreted - the output of a pdf compiler would be a static image, not a pdf document, as pdf is the source (if that makes sense) PDF and PS documents are often mechanically generated - they are transformed from some other document format - but that doesn't mean that they are compiled code. The transform is more like a preprocessor pass - the output is still valid source, just not the same source as was originally written. I think the discussion went off-topic. The terms source language, compiler etc. are not so important in pure technical term. I think 90% of people agree that C code passed to an obfuscation filter is not more source code, but it is still written in C. [But passing to indent is still source] So we have the same mechanism with PS and PDF. Are the sources easily modifiable? Are the sources in the form that upstream would normally use to modify it? So sometime PDF and PS are really sources (in legal term), but most of time they are an intermediate (and obfuscated) format. ciao cate -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Fri, 03 Apr 2009 10:29:42 +1100 Ben Finney wrote: Francesco Poli writes: When there is no source (== preferred form for making modifications) available, I do not think we should call the work DFSG-free. I would clarify the ambiguity of “available”: The upstream developer, by definition, has available a preferred form of the work for making modifications to it. That is the source, and works for which that source is not made available *to recipients* of the work (with all the rest of the DFSG freedoms and requirements) should not be considered DFSG-free. Yes, definitely. Thanks for making it clearer than I could do in my quickly-written message. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpNd7u2iaBRv.pgp Description: PGP signature
Re: distributing precompiled binaries
On Sun, Mar 29, 2009 at 10:33:38AM +0200, Bernhard R. Link wrote: * Steve Langasek vor...@debian.org [090328 23:46]: And this has all been discussed before. Obviously not often enough for you. Oh, I'd much rather be doing something other than discussing this, but as long as people are going to misrepresent the DFSG to this mailing list and repeat arguments that have already been refuted as if they're canon, it's fairly necessary. Also, a PDF is a program for a certain type of interpreter. A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest This is no different to a compiled binary. The argument used to justify the claim that the DFSG requires source for PDF and PS files is that PDF and PS are programming languages. Yet *no one* claims that when you write a text document that you will later postprocess into a PDF, you're writing a program! If what you've written is not a program, then the source document is not the source for a program in any meaningful sense. The difference between a compiler and a mumble2pdf converter is that a compiler's output will algorithmically resemble the original source to the program, no matter how much it optimizes, but two versions of mumble2pdf could output *completely different* programs which are related *only* in the (presumedly) human-readable output they display. - only that they output the same documentation. I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. It's reasonable for you to hold the position that this is not free. But that's not what the DFSG says; and before someone tries to change the DFSG to say this, I would recommend someone try to come up with a brighter line to separate documentation than, e.g., fonts, graphics, sounds, and videos than just more people edit documents. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Steve Langasek vor...@debian.org wrote: [...] The argument used to justify the claim that the DFSG requires source for PDF and PS files is that PDF and PS are programming languages. [...] I asked that we not have this argument here and now, because this case involves applets under the GPL, so the PDF-source problem doesn't matter, but if the alternative is that some will invent incorrect and weak strawmen arguments to fight, I might as well try to straighten this record. I thought the argument used is that PDF and PS are produced by compiling some document source code to some object code. Whether or not they are programs seems irrelevant. Indeed, this previous email says as much: It's just another computer-readable translation, which a human can also treat as such, such a very inconvenient one. And while different compilations of a program are in practise very similar, the only thing one can expect is that they produce binary that do the same thing -- Bernhard R. Link, 29 March, this thread. So where did the above PDF and PS are programming languages argument come from? References, please! Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Wed, 1 Apr 2009 23:02:06 -0700 Steve Langasek wrote: [...] It's reasonable for you to hold the position that this is not free. But that's not what the DFSG says; and before someone tries to change the DFSG to say this, I would recommend someone try to come up with a brighter line to separate documentation than, e.g., fonts, graphics, sounds, and videos than just more people edit documents. As far as I am concerned, I do *not* want to separate documentation and programs from fonts, graphics, sounds, and so forth. I am convinced that *all* these works need to have source available in order to comply with the DFSG and be called Free. And I respectfully disagree with your claim that the DFSG don't apply (or apply in a weaker sense) to documentation, or graphics, or sounds, or whatever. As Bruce Perens clarified, the original intent was for the DFSG to apply to everything distributed in Debian (main): | When designing the DFSG, I was considering the contents of a Debian CD, | much like the Official Debian ISO image, containing all of the Debian | software and documentation. [...] | I intended for the entire contents of that CD to be under the rights | stated in the DSFG - be they software, documentation, or data. Please see http://lists.debian.org/debian-legal/2003/08/msg00264.html for the context. As usual, IANADD, TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpQcWbB7zHVk.pgp Description: PGP signature
Re: distributing precompiled binaries
On Sun, 2009-03-29 at 15:37 +0100, MJ Ray wrote: I disagree, seeing PDFs as being like intermediate code rather than source code, but both gammu and remuco claim to be under the GPL, so require good source for their applets, so let's not have this debate here now. Both gammu and remuco come with the sources required to build their binaries, but both require compilers/components that don't exist in Debian. Either way, remuco's upstream author has informed me that the WTK dependency can be dropped and replaced with MicroEmu, which appears to be LGPL. When I have time, I'll work on packaging that, as it doesn't seem to be in Debian yet. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Thu, 2 Apr 2009 18:52:45 +0200 Francesco Poli f...@firenze.linux.it wrote: On Wed, 1 Apr 2009 23:02:06 -0700 Steve Langasek wrote: [...] It's reasonable for you to hold the position that this is not free. But that's not what the DFSG says; and before someone tries to change the DFSG to say this, I would recommend someone try to come up with a brighter line to separate documentation than, e.g., fonts, graphics, sounds, and videos than just more people edit documents. As far as I am concerned, I do *not* want to separate documentation and programs from fonts, graphics, sounds, and so forth. I am convinced that *all* these works need to have source available in order to comply with the DFSG and be called Free. And I respectfully disagree with your claim that the DFSG don't apply (or apply in a weaker sense) to documentation, or graphics, or sounds, or whatever. As Bruce Perens clarified, the original intent was for the DFSG to apply to everything distributed in Debian (main): | When designing the DFSG, I was considering the contents of a Debian CD, | much like the Official Debian ISO image, containing all of the Debian | software and documentation. [...] | I intended for the entire contents of that CD to be under the rights | stated in the DSFG - be they software, documentation, or data. Please see http://lists.debian.org/debian-legal/2003/08/msg00264.html for the context. As usual, IANADD, TINASOTODP. With all due respect, I think you are mixing issues here. I don't think anyone has advanced an argument that anything, including data, should not be covered by the DFSG. The question is, for those types of data that are not reducible to text files, what considerations should govern the format(s) in which such data is provided. If an upstream author chooses to offer non-text data under a free license, the format in which the data is offered should, in the first instance, be within the discretion of the author. Artwork, music, and video can be supplied in a variety of formats or containers. Accessing and modifying that data in a useful way may require specialized tools and knowledge. Unless the required tools are non-free, none of this makes the data non-free. Similarly, if a hypothetical upstream author creates documentation that combines text, images, and formatting (or formatting alone) and then offers that documentation under a free license, that is in fact a desirable result. Maybe that documentation takes the form of a mindmap file, or odf or pdf, or something else. In any of those cases, the format does not make the data non-free. With the right tools and knowledge, the data in any of these formats can be accessed and modified. This is in contrast to a binary blob of compiled code, which can be only approximated by disassembly or reverse engineering. (And this is the crucial distinction.) Now there may be any number of reasons why some formats might be preferred and encouraged, and other formats deprecated and discouraged. Ease of accessibility and modification (which may not be the same thing) are, without doubt, factors to consider. That debate can be had, and decisions reached, without resort to labeling an author's choice of data format as free or non-free. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
In message 49d496cc.yviehl9rqvhommxs%...@phonecoop.coop, MJ Ray m...@phonecoop.coop writes So where did the above PDF and PS are programming languages argument come from? References, please! No references, sorry, but I certainly got the impression from the books I had years ago (PostScript reference manuals) that PostScript was meant as a programming language. iirc it's an rpn notation that is actually very similar to Forth, which definitely is a programming language. It's merely a strange, domain-specific language the purpose of which is to describe and lay out a page of paper, but presumably no different from (if I've got the right language) VHDL which is used to lay out a printed circuit board. And both of them are in some cases written in directly by their practitioners, and in other cases are generated by program generators. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com writes: Either way, remuco's upstream author has informed me that the WTK dependency can be dropped and replaced with MicroEmu, which appears to be LGPL. When I have time, I'll work on packaging that, as it doesn't seem to be in Debian yet. Thanks for the update and good news. -- \ “I was arrested today for scalping low numbers at the deli. | `\ Sold a number 3 for 28 bucks.” —Steven Wright | _o__) | Ben Finney pgp2VtokSXefP.pgp Description: PGP signature
Re: distributing precompiled binaries
On Thu, 2 Apr 2009 17:40:06 -0400 Greg Harris wrote: On Thu, 2 Apr 2009 18:52:45 +0200 Francesco Poli wrote: [...] As far as I am concerned, I do *not* want to separate documentation and programs from fonts, graphics, sounds, and so forth. I am convinced that *all* these works need to have source available in order to comply with the DFSG and be called Free. [...] With all due respect, I think you are mixing issues here. I don't think anyone has advanced an argument that anything, including data, should not be covered by the DFSG. My understanding is that an argument is being advanced by Steve Langasek that Source is only mandatory for programs under the DFSG as written [1] This is applying the DFSG in a weaker sense for non-programmatic works than for programs. I think we already discussed this issue on this list: see some past threads [2][3][4]. [1] http://lists.debian.org/debian-legal/2009/03/msg00136.html [2] http://lists.debian.org/debian-legal/2005/07/msg00514.html [3] http://lists.debian.org/debian-legal/2005/07/msg00441.html [4] http://lists.debian.org/debian-legal/2005/03/msg00149.html [...] If an upstream author chooses to offer non-text data under a free license, the format in which the data is offered should, in the first instance, be within the discretion of the author. The format choice is within the author's discretion, but whether we consider the work as complying with the DFSG (or not) is within *our* discretion. When there is no source (== preferred form for making modifications) available, I do not think we should call the work DFSG-free. This holds for programs, for manuals, for images, for audio files, and so forth... Once again, IANADD TINASOTODP. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpdVkrQbIfqw.pgp Description: PGP signature
Re: distributing precompiled binaries
MJ Ray wrote: So where did the above PDF and PS are programming languages argument come from? References, please! PDF and PS *are* programming languages, and quite powerful ones. However, they are entirely interpreted - the output of a pdf compiler would be a static image, not a pdf document, as pdf is the source (if that makes sense) PDF and PS documents are often mechanically generated - they are transformed from some other document format - but that doesn't mean that they are compiled code. The transform is more like a preprocessor pass - the output is still valid source, just not the same source as was originally written. I would direct you to http://www.physics.uq.edu.au/people/foster/postscript.html for your amusement - the first example is a fairly impressive raytracing program written in postscript. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Francesco Poli f...@firenze.linux.it writes: When there is no source (== preferred form for making modifications) available, I do not think we should call the work DFSG-free. I would clarify the ambiguity of “available”: The upstream developer, by definition, has available a preferred form of the work for making modifications to it. That is the source, and works for which that source is not made available *to recipients* of the work (with all the rest of the DFSG freedoms and requirements) should not be considered DFSG-free. -- \“Every sentence I utter must be understood not as an | `\ affirmation, but as a question.” —Niels Bohr | _o__) | Ben Finney pgpbiaAkBFldn.pgp Description: PGP signature
Re: distributing precompiled binaries
On Thu, Apr 02, 2009 at 07:38:39PM +0100, Dave Howe wrote: MJ Ray wrote: So where did the above PDF and PS are programming languages argument come from? References, please! PDF and PS *are* programming languages, and quite powerful ones. However, they are entirely interpreted - the output of a pdf compiler would be a static image, not a pdf document, as pdf is the source (if that makes sense) PDF and PS documents are often mechanically generated - they are transformed from some other document format - but that doesn't mean that they are compiled code. The transform is more like a preprocessor pass - the output is still valid source, just not the same source as was originally written. I would direct you to http://www.physics.uq.edu.au/people/foster/postscript.html for your amusement - the first example is a fairly impressive raytracing program written in postscript. Or http://www.pugo.org/main/project_pshttpd/ Mike -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
* Steve Langasek vor...@debian.org [090328 23:46]: And this has all been discussed before. Obviously not often enough for you. Also, a PDF is a program for a certain type of interpreter. A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest This is no different to a compiled binary. It's just another computer-readable translation, which a human can also treat as such, such a very inconvenient one. And while different compilations of a program are in practise very similar, the only thing one can expect is that they produce binary that do the same thing (and even that is often not true). - only that they output the same documentation. I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Bernhard R. Link brl...@debian.org writes: * Steve Langasek vor...@debian.org [090328 23:46]: A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest This is no different to a compiled binary. It's just another computer-readable translation, which a human can also treat as such, such a very inconvenient one. And while different compilations of a program are in practise very similar, the only thing one can expect is that they produce binary that do the same thing (and even that is often not true). Moreover, those that want to have different freedoms for users of different types of software — documentation, programs, images, etc. — still have all their arguing ahead of them. The *default* position should be that all users get the same freedoms; restrictions for some types of software, that don't apply to others, need to be justified explicitly. That's quite apart from the practical matters of even reliably *distinguishing* different types of bit streams from each other in order to figure out which rules apply: e.g. if the software is a PDF, it is both documentation *and* program. -- \ “The fact that a believer is happier than a skeptic is no more | `\ to the point than the fact that a drunken man is happier than a | _o__) sober one.” —George Bernard Shaw | Ben Finney -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
In message 20090329083338.ga28...@pcpool00.mathematik.uni-freiburg.de, Bernhard R. Link brl...@debian.org writes - only that they output the same documentation. I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. Would you call a Word document a good enough source? After all, it requires a proprietary program to process it properly! :-) imho, the difference between plain text and a plain pdf is minimal. If, however, the pdf has loads of embedded links etc ... Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Sun, 29 Mar 2009 11:02:07 +0100 Anthony W. Youngman wrote: [...] imho, the difference between plain text and a plain pdf is minimal. If, however, the pdf has loads of embedded links etc ... Please reconsider your claim after thinking about typesetting, formatting, mathematical formulas, pictures, footnotes, headers/footers, internal and external links, and so forth... For instance, for a PDF file generated from LaTeX, I would certainly say that the PDF format is not source form at all. -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpkcCtwhhe6C.pgp Description: PGP signature
Re: distributing precompiled binaries
On Sun, 2009-03-29 at 11:02 +0100, Anthony W. Youngman wrote: In message 20090329083338.ga28...@pcpool00.mathematik.uni-freiburg.de, Bernhard R. Link brl...@debian.org writes - only that they output the same documentation. I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. Would you call a Word document a good enough source? After all, it requires a proprietary program to process it properly! :-) No, OO.o is free. imho, the difference between plain text and a plain pdf is minimal. If, however, the pdf has loads of embedded links etc ... -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
Francesco Poli f...@firenze.linux.it wrote: On Fri, 27 Mar 2009 13:57:49 + MJ Ray wrote: [...] I found gnapplet with sources in the contrib bit of the gammu tree. https://buildd.debian.org/fetch.cgi?pkg=gammu;ver=1.23.1-2;arch=i386;stamp=1236036416 doesn't seem to mention it being rebuilt. Can it not be rebuilt from those sources alone? [...] It seems to me that bug #521448 is an attempt to report this [...] I am not sure whether the bug should be reopened or maybe another bug report should be filed against gammu. What do others think? Reopen and retitle? As I understand policy 2.2.2, the gammu applet is almost exactly the example of free packages which require [...] packages which are not in our archive at all for compilation or execution at the moment. Minor but essential. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Steve Langasek vor...@debian.org wrote: [...] A recent (Dec 2008) addition with no grounding in the DFSG. If I see PDFs being rejected with this rationale when it's not a question of license compliance (PDFs distributed under the GPL certainly have to have source with them, but that's not a DFSG matter), I certainly intend to dispute it. I disagree, seeing PDFs as being like intermediate code rather than source code, but both gammu and remuco claim to be under the GPL, so require good source for their applets, so let's not have this debate here now. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Sun, 29 Mar 2009 15:33:59 +0100 MJ Ray wrote: Francesco Poli wrote: [...] It seems to me that bug #521448 is an attempt to report this [...] I am not sure whether the bug should be reopened or maybe another bug report should be filed against gammu. What do others think? Reopen and retitle? As I understand policy 2.2.2, the gammu applet is almost exactly the example of free packages which require [...] packages which are not in our archive at all for compilation or execution at the moment. Minor but essential. Could you please do that? I think you investigated the issue far more than I have personally done, hence I think you could better explain the problem, and point to the relevant files, and so forth... -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp8hYQ2f4mVH.pgp Description: PGP signature
Re: distributing precompiled binaries
* Anthony W. Youngman deb...@thewolery.demon.co.uk [090329 12:03]: I concur the problem is less severe with documentation than with programs, as translating to text and reformating is often not that big a loss for documentation. But I think in most cases only a .pdf is still to hard to change to call it free. imho, the difference between plain text and a plain pdf is minimal. If, however, the pdf has loads of embedded links etc ... Note that I said most cases. There are .pdfs thinkable that are their own preferred form of modification. But usually there is some something lost. Even if it is only splitting words when wrapping, there is often something involved that makes changing even only small things a tedious task. If we ship it we should be able to make modifications, like adding a half-sentence with same warning or changing some problematic words. If that is reasonable possible with the pdf, then it can be OK in my eyes. But as I said, I think in most cases that is simply not the case. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
gammu: gnapplet.sis requires packages which are not in our archive (was: distributing precompiled binaries)
reopen 521448 ! retitle gammu: gnapplet.sis requires packages which are not in our archive stop Justification: Policy 2.2 This email is to reopen bug 521448. As I understand the close message, while gammu's source does contain source code for gnapplet.sis, it requires packages which are not in our archive at all for compilation. That's given in debian-policy section 2.2.2 as an example of something which should be in the contrib section of the archive network, so this seems still a problem. A split package would be better than pointing users upstream, IMO. The section of debian-policy is http://www.fr.debian.org/doc/debian-policy/ch-archive.html#s-contrib The email discussion of gammu's gnapplet.sis and a similar case starts at http://lists.debian.org/debian-legal/2009/03/msg00127.html It finished with:- Francesco Poli f...@firenze.linux.it wrote: On Sun, 29 Mar 2009 15:33:59 +0100 MJ Ray wrote: Francesco Poli wrote: It seems to me that bug #521448 is an attempt to report this [...] Reopen and retitle? [...] Could you please do that? [...] Done. Thanks for your time and hope this isn't too awkward to fix. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Steve Langasek vor...@debian.org wrote: On Sat, Mar 28, 2009 at 09:51:46AM +1100, Ben Finney wrote: The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. The DFSG does not say this. Source is only mandatory for programs under the DFSG as written. That's taking the example from the explanation to be the complete requirement. Also, a PDF is a program for a certain type of interpreter. The Source missing entry in the REJECT-FAQ is Your packages contains files that need source but do not have it. These include PDF and PS files in the documentation. http://ftp-master.debian.org/REJECT-FAQ.html In the remuco package, the jar's definitely a program anyway. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Fri, 27 Mar 2009 13:57:49 + MJ Ray wrote: [...] I found gnapplet with sources in the contrib bit of the gammu tree. https://buildd.debian.org/fetch.cgi?pkg=gammu;ver=1.23.1-2;arch=i386;stamp=1236036416 doesn't seem to mention it being rebuilt. Can it not be rebuilt from those sources alone? If it's a bug which has been overlooked, that's something else to fix, not a reason for remuco to introduce a similar bug. It seems to me that bug #521448 is an attempt to report this issue for gammu. Unfortunately, it seems that the reporter only complained about the lack of source, which is apparently not the actual issue, and the bug was promptly closed... I am not sure whether the bug should be reopened or maybe another bug report should be filed against gammu. What do others think? -- New location for my website! Update your bookmarks! http://www.inventati.org/frx . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp9oZIaE4g2B.pgp Description: PGP signature
Re: distributing precompiled binaries
On Sat, Mar 28, 2009 at 08:55:27AM +, MJ Ray wrote: Steve Langasek vor...@debian.org wrote: On Sat, Mar 28, 2009 at 09:51:46AM +1100, Ben Finney wrote: The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. The DFSG does not say this. Source is only mandatory for programs under the DFSG as written. That's taking the example from the explanation to be the complete requirement. It's reading the text of the actual guideline instead of making inferences based on the title. Also, a PDF is a program for a certain type of interpreter. A PDF as a program is its own source. You're talking about the preferred format for modification of *documentation*, not a program. There's no reason to expect that two different versions of mumble2pdf are going to output two *programs* that resemble one another in the slightest - only that they output the same documentation. And this has all been discussed before. The Source missing entry in the REJECT-FAQ is Your packages contains files that need source but do not have it. These include PDF and PS files in the documentation. http://ftp-master.debian.org/REJECT-FAQ.html A recent (Dec 2008) addition with no grounding in the DFSG. If I see PDFs being rejected with this rationale when it's not a question of license compliance (PDFs distributed under the GPL certainly have to have source with them, but that's not a DFSG matter), I certainly intend to dispute it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com wrote: [...] For the Python part, the sources are completely distributed, and no binaries are in the tarball. However, for the Java part, only the .jar is distributed in the tarball. I have contacted the upstream developer about this issue, and he will be releasing another tarball with the sources for the Java portion. I think this is a problem at the moment: DFSG 2 requires source code. The problem begins here: The Java portion has a build-dependency on Sun Microsystem's WTK[1], and it is not free[2]. However, this is just a build dependency, and not a runtime dependency. In fact, the .jar isn't even supposed to run on the target machine, it's supposed to be uploaded to the mobile device. So this would be a practical problem, Fails To Build From Source, but only for the mobile device component? I think the Java portion would need to be in contrib at least due to the non-free build-dependency, and probably non-free because presumably some bit of WTK ends up in the jar file, but that may depend on the precise terms and I got a General Error page when trying to view [2] https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewLicense-Start Hence, my question: Is it okay (within DFSG) for upstream to distribute the said .jar file, together with the sources for this .jar file, and for this said .jar file to be copied straight into a .deb and distributed as-is? I feel that it isn't, because it fails DFSG 2 at the moment and maybe others once the WTK-dependent sources are available. There are several bits in http://ftp-master.debian.org/REJECT-FAQ.html which look like they'd apply, like Source missing and Non-Main. I suspect it's probably not certain until we have some general resolution to the wider firmware question, though. http://www.debian.org/vote/2008/vote_003#texte is a bit kernel-case-specific to be reliable here. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Fri, 2009-03-27 at 11:24 +, MJ Ray wrote: Chow Loong Jin hyper...@gmail.com wrote: [...] For the Python part, the sources are completely distributed, and no binaries are in the tarball. However, for the Java part, only the .jar is distributed in the tarball. I have contacted the upstream developer about this issue, and he will be releasing another tarball with the sources for the Java portion. I think this is a problem at the moment: DFSG 2 requires source code. That's fine, upstream will provide the source code in the next release, in addition to the bundled binary .jar The problem begins here: The Java portion has a build-dependency on Sun Microsystem's WTK[1], and it is not free[2]. However, this is just a build dependency, and not a runtime dependency. In fact, the .jar isn't even supposed to run on the target machine, it's supposed to be uploaded to the mobile device. So this would be a practical problem, Fails To Build From Source, but only for the mobile device component? I think the Java portion would need to be in contrib at least due to the non-free build-dependency, and probably non-free because presumably some bit of WTK ends up in the jar file, but that may depend on the precise terms and I got a General Error page when trying to view [2] https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewLicense-Start It wouldn't really FTBFS, if the mobile component isn't built, but instead shipped verbatim as a data file. Hence, my question: Is it okay (within DFSG) for upstream to distribute the said .jar file, together with the sources for this .jar file, and for this said .jar file to be copied straight into a .deb and distributed as-is? I feel that it isn't, because it fails DFSG 2 at the moment and maybe others once the WTK-dependent sources are available. There are several bits in http://ftp-master.debian.org/REJECT-FAQ.html which look like they'd apply, like Source missing and Non-Main. Source missing would apply if the source is really missing, but this is a case of source + binary, but the binary is not rebuilt, and instead distributed as is. Non-main would apply if the .jar needs to be rebuilt from the provided sources instead of just distributed as is. I suspect it's probably not certain until we have some general resolution to the wider firmware question, though. http://www.debian.org/vote/2008/vote_003#texte is a bit kernel-case-specific to be reliable here. But that's about sourceless firmware. This is a binary _with_ sources. To summarize: Upstream will ship sources for the .jar as well as the .jar itself, but the .jar cannot be built from the sources without WTK, which is non-free, and cannot be distributed by Debian. So, I'd like to distribute the .jar as-is, without removing it from the upstream tarball, or rebuilding this .jar before distributing it. Is this permitted? Also, as mentioned in debian-mentors, there is one such binary (not .jar, but .sis) which is distributed within the gammu package which is in main. Considering gammu's currently sitting in main, surely shipping the .jar similarly in remuco (the package I'm working on) wouldn't be a problem? -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com wrote: On Fri, 2009-03-27 at 11:24 +, MJ Ray wrote: Chow Loong Jin hyper...@gmail.com wrote: [...] For the Python part, the sources are completely distributed, and no binaries are in the tarball. However, for the Java part, only the .jar is distributed in the tarball. I have contacted the upstream developer about this issue, and he will be releasing another tarball with the sources for the Java portion. I think this is a problem at the moment: DFSG 2 requires source code. That's fine, upstream will provide the source code in the next release, in addition to the bundled binary .jar The problem begins here: The Java portion has a build-dependency on Sun Microsystem's WTK[1], and it is not free[2]. However, this is just a build dependency, and not a runtime dependency. In fact, the .jar isn't even supposed to run on the target machine, it's supposed to be uploaded to the mobile device. So this would be a practical problem, Fails To Build From Source, but only for the mobile device component? I think the Java portion would need to be in contrib at least due to the non-free build-dependency, and probably non-free because presumably some bit of WTK ends up in the jar file, [...] It wouldn't really FTBFS, if the mobile component isn't built, but instead shipped verbatim as a data file. I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? [...] To summarize: Upstream will ship sources for the .jar as well as the .jar itself, but the .jar cannot be built from the sources without WTK, which is non-free, and cannot be distributed by Debian. So, I'd like to distribute the .jar as-is, without removing it from the upstream tarball, or rebuilding this .jar before distributing it. Is this permitted? I don't think so, but I could be wrong. I'd remove the jar from the remuco upstream tarball and aim to put it in its own contrib package. Also, as mentioned in debian-mentors, there is one such binary (not .jar, but .sis) which is distributed within the gammu package which is in main. Considering gammu's currently sitting in main, surely shipping the .jar similarly in remuco (the package I'm working on) wouldn't be a problem? Does gammu give a justification? I don't see it considered in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180632 http://packages.debian.org/changelogs/pool/main/g/gammu/current/copyright but there's a link to a gammu-legal post which isn't found. I found gnapplet with sources in the contrib bit of the gammu tree. https://buildd.debian.org/fetch.cgi?pkg=gammu;ver=1.23.1-2;arch=i386;stamp=1236036416 doesn't seem to mention it being rebuilt. Can it not be rebuilt from those sources alone? If it's a bug which has been overlooked, that's something else to fix, not a reason for remuco to introduce a similar bug. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: distributing precompiled binaries
On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: [...] I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? Unless I'm mistaken, a PDF without sources is an issue, but if the PDF comes with sources, this is not an issue. If you're saying the .jar is the same as the .pdf, then what's wrong with distributing a .jar that has sources? [...] To summarize: Upstream will ship sources for the .jar as well as the .jar itself, but the .jar cannot be built from the sources without WTK, which is non-free, and cannot be distributed by Debian. So, I'd like to distribute the .jar as-is, without removing it from the upstream tarball, or rebuilding this .jar before distributing it. Is this permitted? I don't think so, but I could be wrong. I'd remove the jar from the remuco upstream tarball and aim to put it in its own contrib package. Also, as mentioned in debian-mentors, there is one such binary (not .jar, but .sis) which is distributed within the gammu package which is in main. Considering gammu's currently sitting in main, surely shipping the .jar similarly in remuco (the package I'm working on) wouldn't be a problem? Does gammu give a justification? I don't see it considered in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=180632 http://packages.debian.org/changelogs/pool/main/g/gammu/current/copyright but there's a link to a gammu-legal post which isn't found. I found gnapplet with sources in the contrib bit of the gammu tree. What contrib bit? Isn't the whole of gammu in main? https://buildd.debian.org/fetch.cgi?pkg=gammu;ver=1.23.1-2;arch=i386;stamp=1236036416 doesn't seem to mention it being rebuilt. Can it not be rebuilt from those sources alone? It probably can, with an appropriate compiler. However, I'm not sure there's such a compiler in Debian. If it's a bug which has been overlooked, that's something else to fix, not a reason for remuco to introduce a similar bug. Or perhaps it was a non-issue to begin with. I'll contact Michal Čihař (gammu maintainer) and ask him about it. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
Re: distributing precompiled binaries
On Fri Mar 27 14:57, Chow Loong Jin wrote: On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: [...] I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? Unless I'm mistaken, a PDF without sources is an issue, but if the PDF comes with sources, this is not an issue. If you're saying the .jar is the same as the .pdf, then what's wrong with distributing a .jar that has sources? A PDF with sources which we can't turn into the PDF is also an issue. (i.e. shipping a frame-maker file and a PDF is not, AIUI, OK) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: distributing precompiled binaries
Chow Loong Jin hyper...@gmail.com writes: On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: [...] I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? Unless I'm mistaken, a PDF without sources is an issue, but if the PDF comes with sources, this is not an issue. The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. -- \ “There is something wonderful in seeing a wrong-headed majority | `\ assailed by truth.” —John Kenneth Galbraith, 1989-07-28 | _o__) | Ben Finney pgpCcuT4ymtL6.pgp Description: PGP signature
Re: distributing precompiled binaries
On Sat, Mar 28, 2009 at 09:51:46AM +1100, Ben Finney wrote: Chow Loong Jin hyper...@gmail.com writes: On Fri, 2009-03-27 at 13:57 +, MJ Ray wrote: [...] I'm not sure that it matters what you call the mobile component, if that data file is really some sort of program that has sources which aren't usable. How is that jar different from a PDF in this way? Unless I'm mistaken, a PDF without sources is an issue, but if the PDF comes with sources, this is not an issue. The PDF needs to come with sources to build the corresponding PDF *using only free software in Debian*, or it's not acceptable for Debian. The same needs to be true of any binary in Debian, AIUI. The DFSG does not say this. Source is only mandatory for programs under the DFSG as written. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
distributing precompiled binaries
Hi all, I've recently encountered an issue while packaging remuco (Bug #416379). Remuco is a duplex remote control application (mobile phones = media players). The mobile phone portion is written in Java, whereas the portion that runs on the media player computer is written in Python. For the Python part, the sources are completely distributed, and no binaries are in the tarball. However, for the Java part, only the .jar is distributed in the tarball. I have contacted the upstream developer about this issue, and he will be releasing another tarball with the sources for the Java portion. The problem begins here: The Java portion has a build-dependency on Sun Microsystem's WTK[1], and it is not free[2]. However, this is just a build dependency, and not a runtime dependency. In fact, the .jar isn't even supposed to run on the target machine, it's supposed to be uploaded to the mobile device. Hence, my question: Is it okay (within DFSG) for upstream to distribute the said .jar file, together with the sources for this .jar file, and for this said .jar file to be copied straight into a .deb and distributed as-is? Thanks in advance. [1] http://java.sun.com/products/sjwtoolkit/ [2] https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewLicense-Start P.S. I sent this on debian-mentors already, then was told by bremner that I should send this here, so I'm sorry if you have received this twice. -- Chow Loong Jin signature.asc Description: This is a digitally signed message part
