Re: Question about license compatibility
On Thursday 21 July 2005 04:49 pm, Gerasimos Melissaratos wrote: X-Hellenic Ministry of Foreign Affairs-MailScanner: Found to be clean X-MailScanner-From: [EMAIL PROTECTED] I'd like to create a package for ng-spice, which seems to be governed by two licenses, which I include herein. In first reading I cannot see any real discrepancies, but of course IANAL. Pls tell me if any of them is compatible with DFSG. I'm surprised no one has responded to this yet... so I guess I'll get the ball rolling. Its my opinion that both licenses are non-free, for reasonably well established and non-controversial reasons. License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. Anyone else have thoughts? -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: Password disclosure?
|--== Francesco Poli writes: FP On Wed, 20 Jul 2005 10:17:29 +0100 Free Ekanayaka wrote: FP [...] FP | zynaddsubfx is also a must FP [...] FP | The licence is a bit strange, I know, but it is still the FP | softsynth with the best sounds that come out of the box. FP Well, what's strange with the GNU GPL v2? FP http://packages.debian.org/changelogs/pool/main/z/zynaddsubfx/zynaddsubfx_2.2.1-2/zynaddsubfx.copyright From http://zynaddsubfx.sourceforge.net/: Please don't use this program to make music that is against God and Jesus Christ. Realize that the only way to the Salvation is Jesus Christ. Please don't lose this chance and don't make others to lose it! FP Well, that's a Please don't do this: it's a kind *request*, not a FP legally binding *requirement*. FP Upstream authors seem to be Christian fundamentalists or something like FP that. FP At least, that's what appears from the notice you quoted... FP They probably would *not* be pleased, if, say, Marilyn Manson used FP zynaddsubfx in his artistical production; but they (seem to) want their FP software to be free, so they do not discriminate against any field of FP endeavor: they just advice against uses they feel as unethical. FP I fail to see anything non-free or troublesome in all this. Yes, I think you're right. I just reported what I thought was the issue here... I don't know what Paul Naska (author) would do in case his program were used by Marilyn Manson (he could even change the license), but that's to the case now. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Password disclosure?
On Fri, Jul 22, 2005 at 08:02:11AM +0100, Free Ekanayaka wrote: |--== Francesco Poli writes: FP I fail to see anything non-free or troublesome in all this. Yes, I think you're right. I just reported what I thought was the issue here... I don't know what Paul Naska (author) would do in case his program were used by Marilyn Manson (he could even change the license), but that's to the case now. Personally, I think if God cares, he'd be pleased to see Manson exercising his freedom by making music disparaging Him. (And I agree with Francesco.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Website Feedback
Dear Sirs, My name is Rob Collyer, and I'm the owner of webforumz.com. I wanted to let you know that I am interested in exchanging links with you. Webforumz.com has a Google Page rank (PR) of 6 and I am sure your site will benefit from exchanging links with us. We have just added a new resource directory and we would place your link there. Our link details:- URL: http://www.webforumz.com Link Title:- Free SEO, Design and development advice Description: Webforumz.com offers free SEO help, Web design and development advice and gives free website critiques to it's members. Please drop me an email if you would like to swap links letting me know the link title and description of the link you require. Best regards, Rob Collyer webforumz.com http://www.webforumz.com/ - [EMAIL PROTECTED] PS: It would be great if you linked to our site. Just drop me a line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the definition of source
On 7/21/05, Rich Walker [EMAIL PROTECTED] wrote: I think you mean: The story that is circulated now about the tweaking of the S-box is that it was to make DES more resistant to differential cryptanalysis, which was unknown at the time. I tend to give Bruce Schneier a certain amount of credence, although I recognize that he is not a historian. It is well documented that the NSA and at least some of the IBM researchers who contributed to the DES design were cognizant of the technique now known as differential cryptanalysis prior to the finalization of the DES S-boxes, and that the S-boxes are locally (and very nearly globally) optimal with respect to d-c attack. Once you allow systems to exist with poor disclosure of the construction process of their internals, you have opened up a back door wide enough to drive a thousand exploits through. I don't pretend to do a security (or even maintainability) audit of all the code that passes through my hands. I frequently rely on the good faith (and continued existence) of upstream when choosing software products on and with which to build my own work. Yes, I do some due diligence; where it seems worthwhile, I spot-check the code quality, the documentation completeness, and the history of the individuals and organizations; and where it really matters, I make some attempt to evaluate the test coverage and the computational complexity of core algorithms. Very, very few open source projects (and even fewer of the closed-source projects whose internals I've seen) impress me on all of the above scores; but you've got to have some tools to work with if you expect to build big things on a small budget. If you are aware that the providers of the system have an agenda, then it actually makes sense to work *harder* on the full disclosure of all components necessary to reconstruct angle than you would otherwise. Everybody's got an agenda. If you're confident that you understand what that agenda is, then you can hedge intelligently against it. Openness is good, but sometimes it reveals not-so-pretty things, and you need to think about whether a shortcut somebody admits to have taken is repugnant or merely regrettable. (Yes, I *am* in the business of producing stuff that you can only reproduce part of from the design data.) Who isn't? :-) Cheers, - Michael
EUPL draft
Greetings, I searched archive of the debian-legal list and it seems that the proposed European Union Public License (EUPL) has not been discussed here yet. As this is clearly an important subject (and I am sure that it is closely related to the software patents agenda), I would like to ask, if anybody here can say that the EUPL draft would be compatible with the Debian Social Contract. Ales Cepek FFII.cz
Re: Question about license compatibility
On Friday 22 July 2005 03:28 am, Matthew Garrett wrote: Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. Why is that the case? The license says: The licensee agrees not to charge for the University of California code itself. The licensee may, however, charge for additions, extensions, or support. If the license said You cannot charge for this code, nor can you charge for it in agregate with other applications outside of this license I might suggest the second part is simply unenforcable. But even if it were enforcable, how does selling code in agregate with other code not fall within the bar against charging for the code itself? The CD has value because of the code, I am charging for the CD, part of why customers are willing to pay for the CD is the value of the code... strikes me as I am, agregate or not, charging for the code. Additionally, how is this not a discrimination on use prohibited under DFSG #6? One of the uses of software is to package, modify, and resell. If I cannot do that because of the license, isn't that a use descrimination? -Sean -- Sean Kellogg 3rd Year - University of Washington School of Law Graduate Professional Student Senate Treasurer UW Service Activities Committee Interim Chair w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: EUPL draft
Ales Cepek wrote: I searched archive of the debian-legal list and it seems that the proposed European Union Public License (EUPL) has not been discussed here yet. As this is clearly an important subject (and I am sure that it is closely related to the software patents agenda), I would like to ask, if anybody here can say that the EUPL draft would be compatible with the Debian Social Contract. Ales Cepek FFII.cz There's a PDFs are available at http://europa.eu.int/idabc/en/document/2623/5585#eupl. Unfortunately, DRM in the file prevents ps2ascii from working its magic: This file requires a password for access. Error: /invalidfileaccess in pdf_process_Encrypt An encouraging start. ;) -- Sam Morris http://robots.org.uk/ PGP key id 5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
On Fri, 2005-07-22 at 18:35 +0200, Ales Cepek wrote: I would like to ask, if anybody here can say that the EUPL draft would be compatible with the Debian Social Contract. Good question. The EUPL draft is available at http://europa.eu.int/idabc/en/document/2623/5585#eupl Now is time to propose changes. -- Ivo Danihelka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
Ivo Danihelka [EMAIL PROTECTED] writes: On Fri, 2005-07-22 at 18:35 +0200, Ales Cepek wrote: I would like to ask, if anybody here can say that the EUPL draft would be compatible with the Debian Social Contract. Good question. The EUPL draft is available at http://europa.eu.int/idabc/en/document/2623/5585#eupl Now is time to propose changes. Here is the text of the license. I have run it through pdftotext, and then formatted for email reading. Page breaks have been retained. EUPL v.01-EN European Union Public Licence V.01 EUPL © the European Community 2005 This European Union Public Licence (the EUPL) applies to the Work or Software (as defined below) which is provided under the terms of this Licence. Any use of the Work, other than as authorised under this Licence is prohibited (to the extent such use is covered by a right of the copyright holder of the Work). The Original Work is provided under the terms of this Licence when the Licensor (as defined below) has placed the following notice immediately following the copyright notice for the Original Work: Licensed under the EUPL v.01 or has expressed by any other mean his willingness to license under the EUPL. 1. Definitions In this Licence, the following terms have the following meaning: The Licence: this Licence. The Original Work or the Software: the software distributed and/or communicated by the Licensor under this Licence, available as Source Code and also as Executable Code as the case may be. Derivative Works: the works or software that could be created by the Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in article 15. The Work: the Original Work and/or its Derivative Works. The Source Code: the human-readable form of the Work which is required in order to make modifications to it. The Executable Code: any code which has generally been compiled and which is meant to be interpreted by a computer as a program. The Licensor: the physical or legal person that distributes and/or communicates the Work under the Licence. Contributor(s): any physical or legal person who modifies the Work under the Licence, or otherwise contributes to the creation of a Derivative Work. The Licensee or You: any physical or legal person who makes any usage of the Software under the terms of the Licence. page 1 of 6 - © European Community 2005 EUPL v.01-EN - Distribution and/or Communication: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, on-line or off-line, copies of the Work at the disposal of any other physical or legal person. 2. Scope of the rights granted by the Licence The Licensor hereby grants You a world-wide, royalty-free, non-exclusive, sub-licensable licence to do the following, for the duration of copyright vested in the Original Work: use the Work in any circumstance and for all usage, reproduce the Work, modify the Original Work, and make Derivative Works based upon the Work, communicate to the public, including the right to make available or display the Work or copies thereof to the public and perform publicly, as the case may be, the Work, distribute the Work or copies thereof, lend and rent the Work or copies thereof, sub-license rights in the Work or copies thereof. Those rights can be exercised on any media, supports and formats, whether now known or later invented, as far as the applicable law permits so. In the countries where moral rights apply, the Licensor waives his right to exercise his moral right to the extent allowed by law in order to make effective the licence of the economic rights here above listed. 3. Communication of the Source Code The Licensor may provide the Work either in its Source Code form, or as Executable Code. If the Work is provided as Executable Code, the Licensor provides in addition a machine-readable copy of the Source Code of the Work along with each copy of the Work that the Licensor distributes or indicates, in a notice following the copyright notice attached to the Work, a repository where the Source Code is easily and freely accessible for as long as the Licensor continues to distribute and/or communicate the Work. 4. Limitations to copyright Nothing in this Licence is intended to deprive the Licensee of the benefits from any exception or limitation to the exclusive rights of the rights owners in the Original Work or Software, of the exhaustion of those rights or of other applicable limitations thereto. © European Community 2005 page 2 of 6 EUPL v.01-EN 5. Obligations of the Licensee The grant of the rights mentioned above is subject to some restrictions and obligations imposed on the Licensee. Those obligations are the following:
Re: EUPL draft
Derivative Works: the works or software that could be created by the Licensee, based upon the Original Work or modifications thereof. This Licence does not define the extent of modification or dependence on the Original Work required in order to classify a work as a Derivative Work; this extent is determined by copyright law applicable in the country mentioned in article 15. This definition should be left to the copyright law. Distribution and/or Communication: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, on-line or off-line, copies of the Work at the disposal of any other physical or legal person. This appears to include public performance (eg, using the software to drive a website), which will cause problems and be non-free IMHO. 5. Obligations of the Licensee The grant of the rights mentioned above is subject to some restrictions and obligations imposed on the Licensee. Those obligations are the following: ... Provision of Source Code: When distributing and/or communicating copies of the Work, the Licensee will provide a machine-readable copy of the Source Code or indicates a website where this Source will be easily and freely available for as long as the Licensee continues to distribute and/or communicate the Work. This is the if you drive a website using this, then you have to distribute the source, when combined with #1. non-free IMHO. 10. Acceptance of the Licence The provisions of this Licence can be accepted by clicking on an icon I agree placed under the bottom of a window displaying the text of this Licence or by affirming consent in any other similar way, in accordance with rules of applicable law. Clicking on that icon indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions. Similarly, the creation by You of a Derivative Work or the Distribution and/or Communication by You of the Work or copies thereof indicates your clear and irrevocable acceptance of this Licence and all of its terms and conditions. This, together with the preamble's any use of this work, may be non-free. 11. Information to the public In case of any Distribution and/or Communication of the Work by You (for example, by offering to download the Work from a website) the distribution channel or media (for example, the website) must provide the following information to the public: your name, as new Licensor providing the Work, your geographic and electronic address, Whoa... dissident test alert! where the Licensor is registered in a trade or similar public register, the trade register in which the Licensor is entered and his registration number, the different technical steps to follow to conclude the Licence, prior to the Distribution and/or the Communication of the Work, what is to conclude the License? where the Licence contract will be accessible, the languages which can be used for the conclusion of the Licence. The Licence terms provided to the Licensee must be made available in a way that allows him to store and reproduce them. 14. Jurisdiction Any litigation resulting from the interpretation of this license, arising between the European Commission, as a Licensor, and any Licensee, will be subject to the jurisdiction of the European Court of Justice, as laid down in article 238 of the Treaty establishing the European Community. Any litigation arising between parties other than the European Commission, and resulting from the interpretation of this license, will be subject to the exclusive jurisdiction of the competent court: Whoa... discrimination: differentiates the EC amongst all licensors. · where the Licensor resides or conducts its primary business, if Licensor resides or conducts its primary business inside the European Union; · where the Licensee resides or conducts its primary business if Licensor resides or conducts its primary business outside the European Union; · where the Licensor resides or conducts its primary business, if both the Licensor and the Licensee reside or conduct their primary business outside the European Union. Discrimination: this is best left to each copyright law. 15. Applicable Law This License shall be governed by the law of the European Union country where the Licensor resides or has his registered office. This License shall be governed by the Belgian Law if a litigation arises between the European Commission, as a Licensor, and any Licensee. This License shall also be governed by the Belgian Law if the Licensor has no residence or registered office inside a European Union country. Ditto. -- HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
In message [EMAIL PROTECTED], Sean Kellogg [EMAIL PROTECTED] writes On Friday 22 July 2005 03:28 am, Matthew Garrett wrote: Sean Kellogg [EMAIL PROTECTED] wrote: License 1 contains a limitation on use (educational, research and non-profit purposes, without fee) which is a violation of DFSG #6. License 2 is less obvious, but I personally believe that a provision that forbids charging a fee for distribution is non-free, or at least bad policy. Certainly having a package that prohibits charging for distribution would prevent it from being on a Debian CD sold by one of the vendors. Based on the DFSG I'd have to point to #1 and #6... but both are kind of stretches. That aspect of license 2 isn't a problem - the DFSG don't require that people be able to charge for an item of software, merely the aggregate work. Why is that the case? The license says: The licensee agrees not to charge for the University of California code itself. The licensee may, however, charge for additions, extensions, or support. Actually, doesn't the GPL itself contain exactly the same restriction, just worded a bit differently? The GPL forbids charging for the code itself. It DOES permit charging (as much as you can get away with) for the effort of packaging it. I'd class packaging as support, therefore it could be included on a Debian CD because you're not charging for the code. Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Public Domain and Packaging
In message [EMAIL PROTECTED], Brian M. Carlson [EMAIL PROTECTED] writes There is no such thing as software that isn't copyrighted. All original expression that is fixed in a tangible form is immediately copyrighted (at least, that's the U.S. rule). There is still lots of debate as to whether it is possible to disclaim that copyright... but there is no question that it is, at the moment of creation, copyrighted. False. You, as a lawyer-to-be, should know better than to be imprecise. U.S. Government software is not copyrighted, and cannot be so, excepting, of course, the United States Postal Service, which is granted an exception under 19 U.S.C. I gather that's false too :-) The rule, afaict (and I'm not an American), is that copyright *cannot* *be* *enforced*, which is not the same thing at all ... Cheers, Wol -- Anthony W. Youngman - wol at thewolery dot demon dot co dot uk HEX wondered how much he should tell the Wizards. He felt it would not be a good idea to burden them with too much input. Hex always thought of his reports as Lies-to-People. The Science of Discworld : (c) Terry Pratchett 1999 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Public Domain and Packaging
On Fri, Jul 22, 2005 at 10:05:09PM +0100, Anthony W. Youngman wrote: The rule, afaict (and I'm not an American), is that copyright *cannot* *be* *enforced*, which is not the same thing at all ... http://www.copyright.gov/circs/circ1.html#piu --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
* Anthony W. Youngman: Actually, doesn't the GPL itself contain exactly the same restriction, just worded a bit differently? The GPL forbids charging for the code itself. Only for the source code which you must make available when you distribute binaries, you may not charge for anything but your actual costs to create and ship the copy. You can charge what you want for plain source code, binaries, or a combination of source code and binaries on the same distribution medium. -- 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]
A question about converting code to another programming language
Dear Debian legal, I have a few questions about software developement. One of them is whether a program written in e.g. Fortran by me or somebody else (who owns the copyright) is converted to C (not f2c). How is copyright changed and what about patent issues (maybe not relevant). Further questions will follow. Thanks, Svante -- 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: failure notice @ [EMAIL PROTECTED]
On Sat, Jul 23, 2005 at 02:07:09AM -, [EMAIL PROTECTED] wrote: Hi. This is the qmail-send program at peff.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: You sent mail to a mailbox which is used only for receiving mailing list postings. If you did this because you are sending unsolicited bulk email, please don't. I don't want to read it. If you did this because you are CC'ing me on a list email, please don't. I'll just end up with two copies of your response. If you did this because you are responding privately to my list comments, please don't. The list is a public forum, and others may benefit from our discussion: http://www.eyrie.org/~eagle/faqs/questions.html If you really do want to get in touch with me via private email, please send mail to me directly at: [EMAIL PROTECTED] Posting mail to public mailing lists with a deliberately invalid reply address, and making people jump through hoops for the privilege of mailing you, is a severe breach of basic etiquette. Please don't do this. --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 5475 invoked from network); 23 Jul 2005 02:07:09 - Received: from unknown (HELO c-65-96-98-23.hsd1.ma.comcast.net) (65.96.98.23) by 0 with SMTP; 23 Jul 2005 02:07:09 - Received: by c-65-96-98-23.hsd1.ma.comcast.net (Postfix, from userid 1000) id CF13D100AA9BC; Fri, 22 Jul 2005 22:07:08 -0400 (EDT) Date: Fri, 22 Jul 2005 22:07:08 -0400 From: Glenn Maynard [EMAIL PROTECTED] To: Jeff King [EMAIL PROTECTED] Subject: Re: generated source files, GPL and DFSG Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] Mail-Copies-To: nobody X-No-CC: Branden subscribes to this list; do not CC him on replies. User-Agent: Mutt/1.5.9i On Fri, Jul 22, 2005 at 10:05:49PM -0400, Jeff King 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? Get out of my head! -- 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