Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 10:48:43PM -0700, Michael K. Edwards wrote: We know perfectly well that the NVidia driver is in the condition it's in partly because its development is funded by a profit-seeking entity that has no wish to destabilize its market position, either by making it easier for a competitor to produce a graphics chip to which the driver could easily be ported, or by losing its privileged relationship to Microsoft when an inspired Linux hacker reworks the driver and related bits of the Linux graphics subsystem to get triple the FPS of the Windows (or XBox) version. (I think triple is probably an exaggeration, but there's room for improvement.) It's very clever of NVidia to support both a fully proprietary Linux driver and a driver we can call open source if we don't look too closely. Do we mind being manipulated this way? A little, but we work with it. In other words, we'll take something as source that we know isn't, because we like nVidia. My reaction is fine, whatever--but don't try to change the very definition of source to include what nVidia is giving us. If looking the other way and pretending a something is source when it clearly isn't is really what Debian wants to do, I don't have the energy to fight that particular case--but it seems to me that the only argument actually presented against preferred form for modification seems to be we want to be able to call nVidia's obfuscated code source, and that definition doesn't let us do that. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On 7/22/05, Glenn Maynard [EMAIL PROTECTED] wrote: In other words, we'll take something as source that we know isn't, because we like nVidia. ... Hey, I didn't say I liked the idea myself. I'm just calling it like I see it. I would say that the core functionality of the nv driver is not maintainable or improvable by anyone outside nVidia, but at least it can be recompiled to pick up changes in X.org data structure layout or whatever and there is some chance of point fixing it. It's not entirely my idea of source code -- but then neither are the Emacs internals. Cheers, - Michael
Re: generated source files, GPL and DFSG
* Florian Weimer ([EMAIL PROTECTED]) [050722 23:56]: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). So, whichever interpretation you prefer, you end up that some works don't need to be available in source. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
(CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. But since semantic arguments are boring and unconvincing, let's stick to real ones, like we should require source for fonts because source for fonts is useful in the same way that source for applications is useful vs. it may be useful, but Debian has its hands full requiring source for applications, and source for fonts isn't worth the fight. Only real arguments can actually advance the discussion in any meaningful way. (Note that I've yet to form an opinion either way on the source for images and fonts debate beyond it's nice to have; I'm just offering an argument on each side that I've heard and thought about on the topic in the past.) And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). Many of the flamewars leading up to GR2004-003 were around the argument that software is everything in a computer that isn't hardware, there are no non-software works in Debian and so everything in Debian is subject to the DFSG. This is also a boring semantic argument, of course--there are certainly better ones--but you seem to be unaware of it. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
* Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]: (CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. Why didn't the GR then change the wording to program? Please stop trying to force us into interpreting the DFSG the way you would like it to be. If you are unhappy with the current semantics, a GR is the way to change the DFSG. But since semantic arguments are boring and unconvincing, let's stick to real ones, like we should require source for fonts because source for fonts is useful in the same way that source for applications is useful vs. it may be useful, but Debian has its hands full requiring source for applications, and source for fonts isn't worth the fight. Only real arguments can actually advance the discussion in any meaningful way. Feel free to discuss on -project whether we want to change the DFSG _again_. However, don't argue here that it means something else than there is in. (And yes, I see some reasons that we want to have at least for some kinds of fonts something source-like. Perhaps we might want a 2a that say fonts need to include $something_else - I'm just unsure what that else should be.) And even if it has to be interpreted that way, the social contract speaks of works, which is more than only software (i.e. there are non-software works in Debian). Many of the flamewars leading up to GR2004-003 were around the argument that software is everything in a computer that isn't hardware, there are no non-software works in Debian and so everything in Debian is subject to the DFSG. This is also a boring semantic argument, of course--there are certainly better ones--but you seem to be unaware of it. I'm aware of that. Before the editorial changes, the Social Contract said that Debian consists only of free software. Now the Social Contract speaks of works - which is obviously a different word than software, and so the Contract acknoledges that there is non-software in Debian. As this GR had the explicit purpose to spell things out, this case is finished now. Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about converting code to another programming language
[EMAIL PROTECTED] wrote: 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). If the transformation from Fortran to C involves creative activity, then the person who did the transformation may hold a copyright in the C-version. Compare a translation from French to English of a book. If it's just a literal translation, then the translator has no copyright. This does not affect the original copyright in the Fortran version. And the translator needs permission to create this derivative work. If the original program infringes on a patent, then the transformed program will also infringe. Patents cover functionality, not specific programs. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Jeff King [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? Let's say I write a program in C code and compile it to assembly language, which I distribute. Somebody else writes an equivalent program directly in assembly language and distributes it. The distributed products contain the same amount of information about how they work. How is one of these free and the other non-free? Machine generated assembly is, in general, significantly less modifiable than hand-written assembly. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Glenn Maynard [EMAIL PROTECTED] wrote: On Sat, Jul 23, 2005 at 02:35:01AM +0100, Matthew Garrett wrote: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? One provided source, the other did not, and Debian considers having source fundamental to having a free program. Because it is, damnit? Take it a step further, and say we have two drivers: one written in heavily- optimized, uncommented assembly, and one written in C, compiled with optimizations and disassembled. They look pretty much the same; as you say, both provide the same freedoms to our users. Is disassembly output of a compiled program source to you? Is one free and the other non-free? If the ease of modification is equivalent in both cases, then I'd consider them to be equally free. If it's impractical for anyone to modify either, then I'd consider them non-free. Free software that provides no practical way of excercising its freedoms is not something that we should be supporting or holding up as an example to others. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
On Fri, 2005-07-22 at 23:32 +0200, Florian Weimer wrote: So this license is certainly on the right track. But we really don't need yet another copyleft license which is not GPL-compatible, do we? According the Study and Comments, they have some reasons: quote Several licences, known as “Open Source” are more or less addressing the above considerations although none was completely satisfying. Most use specific American notions, refer to foreign applicable law and jurisdiction, do not consider European culture or requirements and ignore (or even forbid) official translations in EU national languages. Some dispositions are intensively “viral”, whereas massive spreading through linkage to other software is not the aim of the European Commission, or contains less secure liability disclaimer clause. Furthermore, it is the interest of the Commission, as public authority, to keep control of its Licence and to be independent from external author’s authorizations to update or translate dispositions in all EU languages if needed. /quote The Study into Open Source Licensing of software developed by The European Commission: http://europa.eu.int/idabc/en/document/2623/5585#eupl Do you know a contact address to which these concerns can be submitted? IDABC provides online discussion forum http://europa.eu.int/idabc/en/document/4420 But more useful will be to post the well thought collected comments to the officials. Your point about strange click-through license for source-code distribution is very important. Thanks, -- Ivo Danihelka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: EUPL draft
On 7/23/05, Ivo Danihelka [EMAIL PROTECTED] wrote: Do you know a contact address to which these concerns can be submitted? IDABC provides online discussion forum http://europa.eu.int/idabc/en/document/4420 But more useful will be to post the well thought collected comments to the officials. I suggest to directly contact [EMAIL PROTECTED] which is given at IDABC Contact Page (http://europa.eu.int/idabc/en/contact) Here in Czech Republic our Ministry of Informatics (http://www.micr.cz/default_en.htm) asked OSS.cz to collect comments and suggestions from Czech open source community on EUPL draft. There is only one month for comments so there is not much time left. Ales Cepek FFII.cz
Re: EUPL draft
In message [EMAIL PROTECTED], Florian Weimer [EMAIL PROTECTED] writes Copyleft clause: If the Licensee distributes and/or communicates copies of the Original Works or Derivative Works based upon the Original Work, this Distribution and/or Communication will be done under the terms of this EUPL Licence. The Licensee (becoming Licensor) cannot offer or impose any additional terms or conditions on the Work or Derivative Work that alter or restrict the terms of the Licence. Oh, so it's likely you can't relicense under the GPL. Let's see... Actually, I would think it is pretty certain you can't relicense under the GPL. The GPL explicitly forbids sublicensing, while the EUPL mandates it. 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: generated source files, GPL and DFSG
* Matthew Garrett: So say we have two drivers for a piece of hardware. One is written without comments. One was originally commented, but the comments have been removed. Both provide the same amount of information about how they work. Both are released under the same license. Both provide exactly the same freedoms to our users. How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote: * Matthew Garrett: How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. What difference does upstream intent make to the freedoms that our users receive? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 03:47:41PM -0700, Steve Langasek wrote: On Fri, Jul 22, 2005 at 11:56:01PM +0200, Florian Weimer wrote: * Andreas Barth: Actually, the DFSG says: | 2. Source Code | | The program must include source code, and must allow distribution in | source code as well as compiled form. Obviously e.g. fonts are no programms, even if they are in main. It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. (And there are fewer instances of the word software in the DFSG after the revision than there were before, anyway...) The DFSG was never amended. The text has not changed. This is purely because I didn't want to lump two complex revisions together, and it carries no implications about the intended meaning. The relevant change in 2004-03 was to eliminate all uses of the word software from the SC (except as part of the compound noun free software), on the basis that it had always meant everything but some people had difficulty understanding this and we got into pointless debates because of it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 11:24:12AM +0200, Andreas Barth wrote: * Glenn Maynard ([EMAIL PROTECTED]) [050723 11:15]: (CC's trimmed.) On Sat, Jul 23, 2005 at 09:21:04AM +0200, Andreas Barth wrote: It's clear from the context (and previous discussion) that this has to be interpreted as software. I disagree with that. As there were editorial changes that had as declared goal to replace any such places with the real meaning, and this was not touched, it has to be obviously interpreted as program. If you really want to deal in unconvincing semantic arguments, consider that the clause says the program, which indicates that it's assuming the whole of the DFSG is only being applied to programs. Since GR2004-003 established that the DFSG applies to everything in Debian, program can only consistently be interpreted here as everything in Debian. Why didn't the GR then change the wording to program? Because this word is in the DFSG, not the SC. Please stop making up ridiculous interpretations. 2004-03 was modifying the SC. It did not modify the DFSG. That's all there is to see here. And before anybody starts making up more daft ideas about why the DFSG wasn't changed, it was for one reason and one reason alone: Updating the SC took quite enough of my time, I didn't want to do the DFSG as well right then. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 12:22:34AM +0100, Matthew Garrett wrote: Florian Weimer [EMAIL PROTECTED] wrote: * Matthew Garrett: There's two main issues here. 1) Does everything in main have to include the preferred form of modification? I don't believe so, We had a GR that is usually interpreted in a manner which disagrees with you. We had a GR that stated that everything in main must include source code. Actually that's a myth. We have never had a GR on this subject. We did have a *release manager* who stated this, at one point. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On 20050723T013237+0100, Matthew Garrett wrote: So if I write C with comments and then remove them that's not DFSG free, but if I fail to add them in the first place then it's fine for main? This is not a universally applicable rule, but: When a good programmer writes uncommented code, it's usually written in a way that requires no comments for understanding it. When a good programmer writes commented code, the comments are often actually important for understanding the code (say, the code is necessarily so hairy that one needs to have a high-level understanding of it to be able to make sense of it; that understanding will be induced by the comment). In the second case, removing the comments will make the source code unmaintainable, while in the first case, the commentless source code is perfectly maintainable. As to whether this affects DFSG freeness, I cannot say. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 10:44:36AM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: One provided source, the other did not, and Debian considers having source fundamental to having a free program. Because it is, damnit? No, because one provided source, and the other did not, and Debian considers having source fundamental to having a free program. If you don't accept a simple reference to Debian's actual requirements (DFSG#2) used to determine whether something is free or non-free as a response to how is one of these free and the other non-free, then I don't know what you possibly will. (In any case, we were trying to figure out what source means, not what's more or less free.) If the ease of modification is equivalent in both cases, then I'd consider them to be equally free. If it's impractical for anyone to modify either, then I'd consider them non-free. Free software that provides no practical way of excercising its freedoms is not something that we should be supporting or holding up as an example to others. The third sentence does not support the first two. Indeed, software that is poorly written, and is unmaintainable as a result, is not something that should stand as an example, and shouldn't be in Debian; but that has no relevance to whether or not it's source. You skipped the more relevant question: Is disassembly of a compiled program source to you, if the disassembly is as usable as hand-written assembly? I havn't seen explanations of how disassembly output, or any forms of code obfuscation (eg. removing of comments or symbolic constants), can possibly be seen as source code. You say it's just as free, but we're discussing what source is, not what free is. You seem to be arguing that preferred form for modification is a poor definition of source based on the fact that it doesn't permit passing off obfuscated code (such as, perhaps, nVidia's) as source, and that seems to me to be one of its strengths. (That is, from my perspective, it's self-evident that obfuscated code is not source, and preferred form gets this case right. Maybe it's self-evident to you that obfuscated code is source. If that's the case, we may be at an impasse, having fundamentally different notions of what source code means.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Thu, 21 Jul 2005 21:15:12 -0400 Glenn Maynard wrote: I think it would be massive negligence for the project to accept as source something which it knows has been obfuscated. If that's the case, I'm rather disgusted. It's hard to take a project seriously which claims to require source, but whistles and looks the other way when given something that is obviously not source, because it wants that particular piece of software more than it wants to stick to its founding principles. If Debian is going to drop its principles and loosen the Social Contract, so be it, but don't try to hide it by pretending obfuscated code is source. I really hope Debian is *not* going to drop its principles. If there is evidence that this driver code is not directly modified by its maintainer, but is instead generated by a filter (i.e. an obfuscator) from a more comfortable form, then this form is the real source code. If this is the case, we are not given the actual source to this driver and we should seek clarification from upstream and ask for the actual source. P.S.: just a note to say that I agree with basically everything said so far by Glenn Maynard in this sub-thread. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpmyKk3PNfuJ.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005 01:01:07 +0200 Florian Weimer wrote: * Steve Langasek: It's clear from the context (and previous discussion) that this has to be interpreted as software. No, it isn't. Considering we went through all the effort of a GR to amend the DFSG and this still says program, not software, I don't see how you can claim it *has* to be read as software. So you think that the DFSG clauses 2, 6, 7, 8 do not apply to documentation, only to executables? I asked Steve basically the same question in Message-Id: [EMAIL PROTECTED] http://lists.debian.org/debian-legal/2005/03/msg00149.html during the long nv driver thread (which unfortunately I do not have time to reread now). So far I got no answer... :-( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpdLJ2mHxnFc.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
* Matthew Garrett: On Sat, Jul 23, 2005 at 12:47:03PM +0200, Florian Weimer wrote: * Matthew Garrett: How is one of these free and the other non-free? In the end, you have to take upstream intent into account. We already do this when interpreting licenses (at least in one direction), so I don't think this makes things worse. What difference does upstream intent make to the freedoms that our users receive? If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Patents on encoders in Europe
Hi, With the recent clarifications on software patents in Europe, would it be possible to distribute encoders packages from Europe? My current understanding is that the algorithm can be patented, but a pure software implementation is not violating such a patent. Is that correct? Bye, -- Loïc Minier [EMAIL PROTECTED] Come, your destiny awaits! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
23.07.2005 pisze Florian Weimer ([EMAIL PROTECTED]): What difference does upstream intent make to the freedoms that our users receive? If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. Are you missing the point deliberately? The question was: if we have two examples of source code; one stripped of comments by obfuscation and the second one written without comments, both released under the same Free Software license, how do you tell, which one is free and which one is not? Jubal, eagerly awaiting the precious moment when we'll require the full internal documentation of any software released before considering it free. -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Tact, n.: The unsaid part of what you're thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
If upstreams sues you, the freedoms granted by the license texts don't matter much. A court case is a great inconvenience, even if the defendant wins in the end. Are you missing the point deliberately? The question was: if we have two examples of source code; one stripped of comments by obfuscation and the second one written without comments, both released under the same Free Software license, how do you tell, which one is free and which one is not? The first author's intent was to make the creation of derivative works harder, irrespective of what the license says. This makes the work non-free (at least I'd rather refrain from using it). In the second case, the author may just be a suitable skilled developer (either he's too bad or too good for writing commented source code). Jubal, eagerly awaiting the precious moment when we'll require the full internal documentation of any software released before considering it free. In order to exercise my right to create derived works, I need to understand some of the internal workings of the program. From a practical point of view, software freedom needs some degree of maintainability. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patents on encoders in Europe
* Loïc Minier: With the recent clarifications on software patents in Europe, would it be possible to distribute encoders packages from Europe? No, the parliament didn't change the existing legal framework, which means it's still not clear how effective patents can be enforced against software distribution activities.
Re: A question about converting code to another programming language
* Arnoud Engelfriet: If the transformation from Fortran to C involves creative activity, then the person who did the transformation may hold a copyright in the C-version. Compare a translation from French to English of a book. If it's just a literal translation, then the translator has no copyright. Literal in this context means simple word substition, not the usual sense of literal translation. If the original work is copyrightable, the translation very likely is as well. This does not affect the original copyright in the Fortran version. Agreed. And the translator needs permission to create this derivative work. Indeed. If the original program infringes on a patent, then the transformed program will also infringe. Patents cover functionality, not specific programs. It's possible that the patent refers to specific FORTRAN constructs, such as storage layout of arrays, or syntactic elements of the language. This may bite you in the other direction, too. In short, no general answer to this question is possible. Usually, it's not even possible if you are confronted with specific patents. 8-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about converting code to another programming language
Florian Weimer wrote: * Arnoud Engelfriet: If the transformation from Fortran to C involves creative activity, then the person who did the transformation may hold a copyright in the C-version. Compare a translation from French to English of a book. If it's just a literal translation, then the translator has no copyright. Literal in this context means simple word substition, not the usual sense of literal translation. If the original work is copyrightable, the translation very likely is as well. Agreed, and in the vast majority of the cases the translation is a creative work. A babelfish translation would be a literal translation. If the original program infringes on a patent, then the transformed program will also infringe. Patents cover functionality, not specific programs. It's possible that the patent refers to specific FORTRAN constructs, such as storage layout of arrays, or syntactic elements of the language. This may bite you in the other direction, too. Perhaps, but I've never seen a patent like that. Arnoud -- Arnoud Engelfriet, Dutch European patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patents on encoders in Europe
On 20050723T144156+0200, Loïc Minier wrote: With the recent clarifications on software patents in Europe, would it be possible to distribute encoders packages from Europe? Actually, the recent decision had the side-effect that the swpat situation was *not* clarified (the parliament's decision was refusal to clarify it in a way that we find bad). The situation, therefore, is unchanged. -- Antti-Juhani Kaijanaho, Debian developer http://kaijanaho.info/antti-juhani/blog/en/debian signature.asc Description: Digital signature
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005 07:29:19 -0400 Glenn Maynard wrote: You seem to be arguing that preferred form for modification is a poor definition of source based on the fact that it doesn't permit passing off obfuscated code (such as, perhaps, nVidia's) as source, and that seems to me to be one of its strengths. Agreed: that is a *feature* of the preferred form for modification definition of source, not a *bug*! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpayLCQSM0Vy.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Fri, 22 Jul 2005 18:09:56 -0400 Glenn Maynard wrote: On Fri, Jul 22, 2005 at 11:47:09PM +0200, Florian Weimer wrote: [...] I think it's not acceptable to yse pregenerated files to prevent software from entering contrib. (Look at all the Java programs, for instance.) If there's a povray dependency, the software cannot be included in main. If you mean images generated from povray are non-free because they can't be built from source without a non-free component, I'd have to disagree on the grounds that the conclusion is so patently absurd, the premises must be flawed (whether or not I'm able to pinpoint that flaw). I don't think Florian meant that povray-generated images are non-free. I think he said that they are not eligible for inclusion in main and belong in contrib (as long as they are under a free license and are provided with source). Looking at it more closely, nothing in DFSG#2 requires that the source be usable; only that it be source. That is, if the source to a program is written in an expensive, proprietary language, it's still source, and satisfies DFSG#2. That doesn't mean Debian has to accept it; meeting the DFSG is a prerequisite, but not a guarantee of inclusion, and Debian is free to refuse to include software for other reasons (such as we can't build this source). I just can't agree that a freely-licensed work, with source (such as an image with povray source) can be accurately branded non-free because the tools to build that source are non-free. I agree with you, but suspect that Florian agrees too! ;-) P.S.: Florian, could you confirm or otherwise correct me? Rest assured it's not my intention to put words in your mouth, I simply noticed what I believe is a misunderstanding between you and Glenn, and wanted to point it out... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVDl6McpWm5.pgp Description: PGP signature
Re: generated source files, GPL and DFSG
On Fri, Jul 22, 2005 at 11:28:54PM -0700, Michael K. Edwards wrote: On 7/22/05, Glenn Maynard [EMAIL PROTECTED] wrote: In other words, we'll take something as source that we know isn't, because we like nVidia. ... Hey, I didn't say I liked the idea myself. I'm just calling it like I see it. I would say that the core functionality of the nv driver is not maintainable or improvable by anyone outside nVidia, but at least it can be recompiled to pick up changes in X.org data structure layout or whatever and there is some chance of point fixing it. It's not entirely my idea of source code -- but then neither are the Emacs internals. This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. On a more practical note, you're going to have a very difficult time convincing me to move the nv driver to non-free. This not even borderline case is the only thing that stands in the way of having every single nvidia owner use the binary nvidia drivers which I can not support in *any way at all*. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patents on encoders in Europe
Hi, With the recent clarifications on software patents in Europe, would it be possible to distribute encoders packages from Europe? We won a battle that shouldn´t be fought. Currently the situation is *exactly* the same as before, nothing has changed. Better it would have been if the directive as amended by parlament had been approvated. Software patentes are still illegal according to the european patent agreement of Munchen. EPO -created by the same agreement- is still granting patent software. But only a judge can establish if the patent are legal or not. The very function of EPO in granting patents is give a *legal* date of the invention, in case in future software patents becoms legal in UE (that is not europe, EPO is not a UE institution!). My current understanding is that the algorithm can be patented, but a pure software implementation is not violating such a patent. Is that correct? I would say that the current situation neither permits pure alghritms to be patented. Have you time and money to prove that through a trial? ;-) thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 10:40:36AM +0100, Matthew Garrett wrote: Machine generated assembly is, in general, significantly less modifiable than hand-written assembly. And code in which information that the original coder inserted has been removed is less modifiable than code written without that information in the first place. Can give you a good reason why the two situations we described are significantly different? -Peff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
On Sat, Jul 23, 2005 at 09:50:56AM -0700, Ken Arromdee wrote: On Sat, 23 Jul 2005, David Nusinow wrote: This is true, but not because the driver isn't commented. It's because the specs for the card have not been released, and as such we don't know what the magic numbers mean. The hardware specs are entirely external to the source code for the driver itself, and as such it doesn't affect the freeness of the driver. If the guys at Nvidia maintain the driver by referring to a separate copy of the hardware specs and copying numbers from it into the driver when needed, then the hardware specs are external to the source code of the driver. If the guys at Nvidia maintain the driver by maintaining a version of the code which has symbols in it, and give the driver to us by removing the symbols, then to the extent which the symbols provide information about the specs, the specs are *not* external to the source of the driver. But understanding it is contingent on those specs. You have all the rights to modify the code that is the nv driver as it is under a Free license. Upstream also likely keeps the driver in revision control with its own set of comments and metadata that they use to maintain the driver, but not having access to that does not qualify the thing as non-free. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about converting code to another programming language
On Saturday 23 July 2005 02:40 am, Arnoud Engelfriet wrote: [EMAIL PROTECTED] wrote: 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). If the transformation from Fortran to C involves creative activity, then the person who did the transformation may hold a copyright in the C-version. Compare a translation from French to English of a book. If it's just a literal translation, then the translator has no copyright. To be clear, if someone translates something from Language A to Language B, they do not hold a copyright in the Language B version. What they hold is a copyright in the expression that is the translation. This is important because the translator cannot authorize the translation from Language B to Language C, as he does not control the copyright to the underlying work on which any translation effort is based. This, of course, is the default rule and can be circumvented with good licensing allowing the translator to have full control over their derivative... but outside of a copyleft context, I can't imagine an author wanting a translator to have the authority to translate back into the initial language and sell competing versions. -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: Patents on encoders in Europe
On 7/23/05, Loïc Minier [EMAIL PROTECTED] wrote: With the recent clarifications on software patents in Europe, would it be possible to distribute encoders packages from Europe? Very inadvisable without an encouraging opinion from competent counsel, which (IANAL, TINLA) you won't get without cooperation with Thomson. Based on their recent statements, however, it appears to me that there might be an approach towards them that could result in a modus vivendi; thread at http://lists.debian.org/debian-legal/2005/07/msg00273.html . My current understanding is that the algorithm can be patented, but a pure software implementation is not violating such a patent. Is that correct? No. Mathematical methods and computer programs as such are explicitly not patentable under the EPC, but that is currently understood to mean that the invention must have a technical effect beyond the manipulation of numbers and bits in a computer's memory. This is very similar AFAICT to the concrete, tangible, and useful result standard applied in the US since the 1994 In re Alappat ruling. Thread, with references to case law and the participation of an actual European lawyer, at http://lists.debian.org/debian-legal/2005/07/msg00323.html . Cheers, - Michael (IANAL, TINLA)
Re: A question about converting code to another programming language
* Arnoud Engelfriet: It's possible that the patent refers to specific FORTRAN constructs, such as storage layout of arrays, or syntactic elements of the language. This may bite you in the other direction, too. Perhaps, but I've never seen a patent like that. There are patents on certain Visual Basic language constructs, for example. Maybe one of them covers programs using these constructs (and not just implementations of Visual Basic). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about converting code to another programming language
The prospect of this patent application resulting in a patent that can be successfully litigated is zero. (IANAL, TINLA.) http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220040230959%22.PGNR.OS=DN/20040230959RS=DN/20040230959 The principal inventor himself is less than impressed with his employer's attempt to patent such a triviality, which is in any case long since part of the prior art. http://www.panopticoncentral.net/archive/2004/11/20/2321.aspx Blame Microsoft for stupidity if you like, but IMHO the rapacity award goes to Woodcock Washburn LLP. Filing such a patent application is such a waste of the time and money of everyone involved, and will result in so much abuse heaped on the participants if it is not quietly abandoned, that it's hard not to see it as a political maneuver on someone's part (perhaps against IBM, whose participation in the patent system is far larger than Microsoft's). An attorney who would play ball with such a stunt is risking public excoriation of himself and his firm. Cheers, - Michael (IANAL, TINLA)
Re: A question about converting code to another programming language
And while we're naming and shaming IP law firms who should, in my non-lawyer opinion, know better, let's add Lee Hayes PLLC: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=/netahtml/PTO/srchnum.htmlr=1f=Gl=50s1='20030028685'.PGNR.OS=DN/20030028685RS=DN/20030028685 If the Federal circuit finds a concrete, tangible, and useful result in the .NET class framework, I will certainly abandon any attempt to defend any part of the US patent system. Cheers, - Michael
Re: A question about converting code to another programming language
Yep, here's the associated politics: http://blogs.zdnet.com/BTL/?m=20050311 and especially: http://www.eweek.com/article2/0,1759,1775159,00.asp It will play well to the cheap seats if Microsoft can cram a few obvious stupidities of its own through the examination process (which, as we have seen, is not the arena where real challenges to patents are brought) and then say, see, we have something to lose by tightening patentability standards too. Then they can sponsor legislation that makes it harder to enforce genuine, valid patents in the courts under cover of USPTO reform. Catch this bit of Microsoft's proposal: Create a special court that would consolidate and hear all patent cases at the federal district level in order to improve consistency and predictability of patent litigation. In other words, take the power to investigate the facts surrounding patent infringement out of the hands of Federal district courts nationwide, which are quite difficult to systematically subvert, and concentrate it in a single, brand new, revolving-door, D.C.-based court of fact. Now do Microsoft's efforts to play both ends against the middle start to make sense? Cheers, - Michael
Re: Question about license compatibility
On Fri, 22 Jul 2005 00:03:56 -0700 Sean Kellogg wrote: Anyone else have thoughts? Yes, I have one: |3. The licensee agrees to obey all U.S. Government res- trictions |governing redistribution or export of the software and |documentation. That sounds non-free. Suppose I'm *not* a U.S. citizen[1]: why should I be bound to obey U.S. Government restrictions? [1] as I was born in Italy, *live* in Italy, and am an Italian citizen, this is actually the case! ;-) -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgppH5eawcWpj.pgp Description: PGP signature
Re: Is an upgrade to the Open Publication License possible?
On Thu, 21 Jul 2005 08:40:43 -0400 Evan Prodromou wrote: I was surprised to see in this list of non-free documentation packages soon to be moved out of main so many works licensed under the Open Publication License (OPL): Well, I was not, taking into account that even Debian website is (IIRC) licensed under this non-free license... I think something should be done to solve this issue too (your approach would nuke'em all, of course, so it's worth trying) http://packages.debian.net/non-free-docs.html I note that the recommended boilerplate used for the OPL is as follows: Copyright (c) year by author's name or designee. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, vX.Y or later (the latest version is presently available at http://www.opencontent.org/openpub/). I think that documentation currently in main that uses the OPL could be salvaged if we can convince the controlling body for the OPL to upgrade to a version that's compatible with the DFSG. Yes, this would possibly solve all the issues with this license in a single clever move! I have not, however, examined the OPL carefully enough to determine if this is possible without fundamentally changing the license. I've read it (very very quickly) and it seems to me that the OPL resembles more to a non-copyleft license than to the GPL. Maybe we could persuade the controlling body to state that the Expat (a.k.a. MIT) license[1] is elected as the OPL v2.0... That would be the best of all possible outcomes, I think... [1] http://www.jclark.com/xml/copying.txt -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp9Bvvkro5AP.pgp Description: PGP signature
Re: Question about license compatibility
On Saturday 23 July 2005 04:41 pm, Francesco Poli wrote: On Fri, 22 Jul 2005 00:03:56 -0700 Sean Kellogg wrote: Anyone else have thoughts? Yes, I have one: |3. The licensee agrees to obey all U.S. Government res- trictions |governing redistribution or export of the software and |documentation. That sounds non-free. Suppose I'm *not* a U.S. citizen[1]: why should I be bound to obey U.S. Government restrictions? [1] as I was born in Italy, *live* in Italy, and am an Italian citizen, this is actually the case! ;-) This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is it Debian's stance that I cannot do so? Can the United State's Government bar me from contributing to Debian by imposing export restrictions? I wasn't on d-l at the time, but wasn't this the point of non-US. Whatever happened to that? -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: Question about license compatibility
On Sat, 2005-07-23 at 17:11 -0700, Sean Kellogg wrote: This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is this really true? It is entirely possible that the law forbids our project's current work habits, especially when said work habits involve interaction with the people responsible for enforcing this law. (And didn't those same people cite us as a model for others to follow in regards to compliance?) I suppose, though, that it would be good to find out for sure. When all this came down, it is my recollection that the regulations treated freely available software differently from proprietary software, with fewer regulations placed upon it. Could you perhaps have overlooked this distinction? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about license compatibility
On Saturday 23 July 2005 08:04 pm, Jeff Licquia wrote: On Sat, 2005-07-23 at 17:11 -0700, Sean Kellogg wrote: This is a difficult situation that is worth commentary. Assume for a moment that the U.S. has some strict export restriction. As a U.S. citizen I am bound by those laws and cannot legally violate them. Further, if I am to distribute software it is entirely possible that the law prohibits me from distributing that software to citizens of certain nations and to ensure those who receive copies do the same. This means I have have a responsibility to ensure others don't distribute and cause me to break the law. The only tool by which I have to do that is the license. Is this really true? Sorry if I didn't make it clear that I am very much talking about hypothetical. I know that with embargoes American citizens have certain responsibilities to ensure the goods the ship internationally do not end up in the hands of certain nations. I can't say this applies to software, or if such an embargo is even going on (outside of our long standing Cuban embargo). My interest, I guess, is whether the DFSG will forbid a developer from having their code distributed if they live in a country with restrictive export laws? -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
