Re: libdts patent issue?
[EMAIL PROTECTED] wrote: To me the distinction is clear: you have to add something to the algorithm before you arrive at patentable matter. You apparently consider the addition (a computing device with a memory) to be irrelevant, and hence you don't see a distinction. The addition should be irrelevant because there's no inventiveness involved in the addition. :-P This is why I noted that the US standard, theoretically, allows a new piece of *artwork* plus a generic computer to be patented. The inventiveness is entirely in the artwork, but by adding the computer, you could arrive at patentable matter (a device which displays a person holding some dogs, for the entertainment of the user, for instance). This is obviously bad law. The European standard is that the claim must cover a piece of technology: a device or method that exhibits a technical effect. And no, I don't have a definition for technical. The dispute is quite specific here: it is over whether (a) the innovation must be in the technical area. If it doesn't have to be, you get results exactly like the US results: patentable artwork. (b) the technical area must be a patentable area. If it doesn't have to be, you get results exactly like the US results: patentable artwork. If the end result is something technical, then it's patentable. This is no good if there's no innovation in the technical area. I invent a machine to display a woman holding dogs in a certain manner. It's inventive because the woman is holding dogs in an unusual and inventive manner. It's technical because it's a machine to display the image. Well, actually it's just a computer plus a unique piece of art, and I've used twisted language to get a patent on something unpatentable. Now nobody can display my artwork -- or indeed any similar artwork -- on a computer without getting a patent license. This is, sadly, precisely analogous to the patents being issued on mathematics today. A method of solving linear equations? Come on. The inventiveness is in the mathematics, not in the relation to the physical world. There's a reason the FFII preferred standard is that the inventive part of a patent must be on some method of manipulating the physical world. That's the That's what European patent law also pretends to be. FFII is pushing a very restrictive definition of what manipulating the physical world means, but otherwise they're completely in line with how patent law works. I'm not sure whether you caught the key point here. The key point here is that the *inventive* part must be attached to the manipulation of the physical world. Innovative software patents generally feature an *uninventive* part which manipulates the physical world -- a generic bit-twiddling machine -- combined with inventive mathematics. The problem is exactly the same: European patent law does not exclude patents on mathematical methods, but only on mathematical methods _as such_. Apparently this is not the same thing for the people who wrote that law. This is such an overuse of as such so as to render the entire list of exclusions from patentability meaningless, and as such (ahem) is invalid under traditional rules of statute construction. By the same argument, only artwork *as such* is unpatentable, and my art patent should work. I could go on and write a similar, equally valid patent relating to putting the artwork on walls. Do you see the problems with this line of argument? The as such phrase is presumably intended to allow patents on material which happens to use a mathematical method/artwork/etc., not on material for which the entirety of the inventive portion is the mathematical method/artwork/etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: libdts patent issue?
Arnoud Engelfriet wrote: If you provide the program loaded into a computer, ready to execute, then the court may likely hold that you infringe. If you publish a printed piece of paper with the program's source, then you likely do not infringe. Like I said somewhere, non-tech-savvy judges making a very questionable dead-tree vs. electronic distinction. What if I provide it on diskette, ready to do whatever with? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdts patent issue?
Michael Edwards wrote: Dualism is on the retreat, processes and machines are on an equal footing, and what makes something not an abstract idea as such is that it be susceptible of industrial application to reliably achieve a particular useful result. In practice, that's another distinction without a difference. *sigh* If industrial was any sort of limitation at all, it might mean something. As it is -- with solving a system of linear equations being an industrial application -- this means that EVERY piece of mathematics is susceptible of industrial application. Without exception. Anyway, this interpretation, although it is apparently the interpretation taken by the Board of Appeals, is again contrary to standard rules of statutory interpretation, and therefore presumably wrong. The requirement that something be susceptible of industrial application to be patentable is given explicitly in a different clause of the EPC. If not a mathematical method as such is read to mean merely susceptible of industrial application, then it is redundant surplusage and means nothing. Accordingly, it should be assumed to mean something stronger. Ahem. the subject matter test is there to distinguish the theoretical from the applied Nice idea, except that it's being used that way. *Everything* is applied under the current standards and *nothing* is theoretical. The first problem is that all theoretical mathematics is *applicable*, although not *applied* until it is actually applied to a specific problem. Software patents are not limited to a particular inventive application (say, playing mp3 files), but apply to future applications using the same mathematical method (say, converting mp3 files to ogg vorbis files). They are patenting the applicable, not the applied. The second (smaller) problem is that applications to mathematics are apparently considered applied (viz. a method to solve a system of linear equations), which really puts everything in the applied category without exceptions. I don't dispute that European judges are reading the EPC to allow all kinds of crap. I say that it does not allow that kind of crap, and I have the better legal arguments. It is sad that so many judges are incompetent, but there you are. not to exclude applied science whose underlying natural law is that of computational complexity and theory of approximation instead of chemistry or physics. This so-called applied science is a field of mathematics. Ahem. Computational complexity theory is *not* a description of the natural world -- you can't test its predictions or do physcial experiments to see how accurate it is -- it's a description of mathematics. Do you really think it's fair to characterize as pro-patenters people who are simply pointing out: the actual state of the law as embodied in decisions by the relevant administrative and judicial authorities; Well, that's fine. I never denied that. Some of these decisions are contrary to statute, of course. Arguing that they are supported by statute is a pro-patent argument. the difficulty courts had in applying a physical effect test consistently when it was believed to be the prescribed procedure; Pointing out the incompetence of courts is all well and good, but saying that it means they should give up is not. and the absence of a public policy rationale for denying the same sort of encouragement to applied researchers (and their financial backers) in fields where the work is done at a computer keyboard as in those where it is done at a lab bench? Nobody has pointed this out, and you've misframed the debate with several false assumptions in this paragraph. * Standard economic theory considers monopolies bad as a public policy matter except when they are (a) natural monopolies, which patents never are, or (b) they can be proven to have benefits outweighing their costs. Amazingly, nobody has ever collected any evidence that any patents have benefits outweighing their costs (except in the pharmaceutical industry, where there are some inconclusive results which might tilt that way). The evidence that software patents inhibit innovation, drive up costs, and generally waste economic resources is quite complete. Therefore there is a strong public policy rationale for denying them. The burden of proof is on *you* to show that the incentive of patents is *necessary*, not on us to show that it is unnecessary. * Your argument imagines people working at keyboards who are applied researchers much like those working at lab benches. But what are they actually doing? Software engineering is not engineering, as anyone who compares the two carefully will realize. Research in the fundamentals of engineering is research in the natural sciences, but practical engineering requires a lot of additional skills too. Research in software *is* pure mathematics, and the additional skills in practical
Re: generated source files, GPL and DFSG
[EMAIL PROTECTED] wrote: However, when I found that (some of) the graphics had a source from which they could be compiled, I concluded two things: - To satisfy the GPL, the source for those graphics needs to be distributed as well, so it must be in the source package. Probably correct. Also necessary for the DFSG. Possible exception: The required *source* is the preferred form for *modification*. If you would normally want to modify the .xpm files directly, then there is no need to include the povray files. If you would normally want to modify the povray files, you need to include them. - I don't know if it's actually written anywhere, but I thought everything that has source and can be compiled should be compiled at package build time. This means the .h-files have to be regenerated (with pov-ray, in this case). Well, this is considered nice, but is not totally mandatory. Consider the case of autoconf-generated configure scripts. They do not have to be rebuilt at package build time. It's considered nice, but if technical reasons discourage it, you don't have to. Now that's where the problem starts: pov-ray is in non-free, so any package with a Build-depends: on it must be in contrib (if it is itself free). True... but you don't need to Build-depends:, as noted above. The sole question is in the interpretation of the following clause of the Social Contract: We will never make the system require the use of a non-free component. The package itself is free as long as the source is included, even if the compiler is unavailable, so it satisfies all the *other* requirements of the Social Contract. Does including this package in main, although certain parts of it cannot be recompiled without non-free software, violate that clause of the Social Contract? I guess it depends on what it means by make the system require. My gut instinct is no, it's fine, put it in main, because the compiler is not required by the system, since the system functions fine without recompiling the graphics (and will continue to). I may be wrong, though! The main/contrib distinction is tricky to say the least. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: generated source files, GPL and DFSG
Andreas Barth wrote: Obviously e.g. fonts are no programms, even if they are in main. Read TrueType instructions and say that again! Some fonts are most certainly programs. PDFs are arguably executables designed for a PDF interpreter. But let's not get into that again right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is an upgrade to the Open Publication License possible?
[EMAIL PROTECTED] wrote: 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. I have not, however, examined the OPL carefully enough to determine if this is possible without fundamentally changing the license. Well, these are the problems with it: (1) No explicit permission is given for modification, or for distribution of modified versions. Sloppy, sloppy. (2) Any publication in standard (paper) book form shall require the citation of the original publisher and author. The publisher and author's names shall appear on all outer surfaces of the book. On all outer surfaces of the book the original publisher's name shall be as large as the title of the work and cited as possessive with respect to the title. This needs to be removed (or substantially weakened) for it to be free. Well, if it applies to modified versions, it does, anyway; it might be acceptable for unmodified versions. For modified versions, it would be ridiculously burdensome. (3) All modified versions of documents covered by this license, including translations, anthologies, compilations and partial documents, must meet the following requirements: The modified version must be labeled as such. The person making the modifications must be identified and the modifications dated. Unclear whether this means the person must *really* be identified (not OK) or whether a pseudonym is acceptable (OK). Acknowledgement of the original author and publisher if applicable must be retained according to normal academic citation practices. (fine) The location of the original unmodified document must be identified. This is normally non-free, but might pass under the patch clause if the unmodified document was located in the source package. It becomes deeply obnoxious if derived works are *also* OPL-licensed, but since it's not a copyleft, that can be avoided. The original author's (or authors') name(s) may not be used to assert or imply endorsement of the resulting document without the original author's (or authors') permission. (fine) And, of course, the license options are non-free, but nobody uses them anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Public Domain and Packaging
Sean Kellogg wrote: There is no such thing as software that isn't copyrighted. He means software written after 1988, of course. All original expression that is fixed in a tangible form is immediately copyrighted (at least, that's the U.S. rule). Since the passage of the Berne Convention Implementation Act in 1988. (Which was a Big Mistake.) Mr. Crowther is better off accepting he has a copyright and simply attaching a COPYING file that says Well, what it should say is this: I hereby grant everyone an irrevocable license to treat this work exactly as if it were in the public domain. That's the closest you can get to the public domain with certainty, in the US at the moment. The problem is that it's not actually clear that it's possible to voluntarily place a work in the public domain in the US since the BCIA passed. (Before that, it was easy.) The irrevocable is important in case your heirs decide to contest your public domain dedication and steal the work back from the public (unlikely, but very nasty). :-( -- 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 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. I don't think the law can really require that I ensure the behavior of those I distribute copies to; after all, it's a completely impossible requirement! I was always under the impression that I was simply not allowed to export them *myself*, or *encourage* others to do so. If the law imposes a positive requirement that I police the behavior of anyone I distribute the software to, that's pretty evil. I sure hope it doesn't do that. 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. Not that that would work. If ensure were really the requirement, surely a clause in the license would be not nearly enough; you would presumably be expected to keep track of everyone you distributed it to, monitor their behavior, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdts patent issue?
Nathanael Nerode wrote: [EMAIL PROTECTED] wrote: To me the distinction is clear: you have to add something to the algorithm before you arrive at patentable matter. You apparently consider the addition (a computing device with a memory) to be irrelevant, and hence you don't see a distinction. The addition should be irrelevant because there's no inventiveness involved in the addition. :-P Inventiveness has nothing to do with whether something is statutory subject matter. Today, the wheel is patentable in principle, but you will never get that patent because the wheel is known. A wheel of exactly 38.25 diameter is also statutory subject matter, it's (probably) new but such a specific choice of diameter is obvious. This is why I noted that the US standard, theoretically, allows a new piece of *artwork* plus a generic computer to be patented. US patent law would say that this computer with artwork is statutory subject matter. It'd probably be rejected for lack of inventiveness though, as computers that show artwork are well-known so it would be obvious to a skilled person to pick yet another piece of artwork and display it. The dispute is quite specific here: it is over whether (a) the innovation must be in the technical area. If it doesn't have to be, you get results exactly like the US results: patentable artwork. (b) the technical area must be a patentable area. If it doesn't have to be, you get results exactly like the US results: patentable artwork. See above. The claim _as a whole_ must be in a patentable area. In Europe that means it must be in a technical area. And in Europe, the _innovation_ must be in a technical area as well. For instance, A method of selling items, involving giving a 10% discount if you buy more than five items at once is not in a patentable area in Europe. That's what we would call a pure business method. (I don't know if it is statutory in the USA). I can rewrite that claim to A cash register that is configured to count the number of items rung up during one transaction and to give a 10% discount if the counted number exceeds five. This is _statutory subject matter_ in Europe, because cash registers are technical devices. Same for the USA. But the application will be rejected because it does not involve an inventive step. The innovation (giving the discount) is purely a business method, which by definition cannot be inventive. This is no good if there's no innovation in the technical area. I invent a machine to display a woman holding dogs in a certain manner. It's inventive because the woman is holding dogs in an unusual and inventive manner. It's technical because it's a machine to display the image. In Europe, we'd say yes, this is technical -it's a machine- but there's no inventiveness involved in displaying yet another picture. So it's just a trivial variation on a known machine. If I take a washing machine and paint it purple, would you say it's no longer a machine? That's what European patent law also pretends to be. FFII is pushing a very restrictive definition of what manipulating the physical world means, but otherwise they're completely in line with how patent law works. I'm not sure whether you caught the key point here. The key point here is that the *inventive* part must be attached to the manipulation of the physical world. There is a difference in approach here. FFII (and apparently you as well) judges whether something is _statutory_ by looking only at the contribution over the prior art. European patent laws by and large determine this question by looking at the _claim as a whole_. A washing machine is a washing machine is a washing machine. That kind of machine is statutory subject matter. If the contribution you claim to have invented is no _technical contribution_ then you have an obvious variation on a washing machine. FFII would say in this example the invention is not statutory. The EPO would say the invention is statutory but trivial. This is the difference between 'Kerntheorie' and 'whole claim approach'. Innovative software patents generally feature an *uninventive* part which manipulates the physical world -- a generic bit-twiddling machine -- combined with inventive mathematics. The inventive step is part maths and part practical (technical) application of the mathematics. A formula by itself is not a patentable contribution. A method of recognizing spoken words, comprising using new formula X to recognize the words provides a technical contribution: the _use_of_ the formula to manipulate the physical world. The problem is exactly the same: European patent law does not exclude patents on mathematical methods, but only on mathematical methods _as such_. Apparently this is not the same thing for the people who wrote that law. This is such an overuse of as such so as to render the entire list of exclusions from patentability meaningless, and as such (ahem) is
Re: EUPL draft
OK. Problems found. Please forward these to the appropriate authority, since I couldn't work out how to. Distribution requirements require the provision of way too much information about the licensor. Geographic and electronic address? Come on. Geographic address is a matter of privacy, most certainly. I don't like the jurisdiction requirements, either. They appear biased towards Europeans and against everyone else. The attribution right should be restricted to *accurate* notices, which it isn't. I raised this issue with the Apache License and they fixed it. There's some really odd language in which it seems to imply that distribution makes you a Licensor, which I don't think is right at all. Everything else appears DFSG-free, though I may have missed something. There are some other oddities, though. It requires that in the case of distribution you provide the different technical steps to follow to conclude the License. But the License is accepted upon exercise of otherwise prohibited rights, as with all normal free software licenses, as it says in section 10. What's up with that? The definition of Source Code is substantially worse than the GPL's definition. The use of website in Provision of Source Code is too specific and not future-proof. It's a bad example of license proliferation, because it's a new, GPL-incompatible copyleft license. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: libdts patent issue?
Nathanael Nerode wrote: Arnoud Engelfriet wrote: If you provide the program loaded into a computer, ready to execute, then the court may likely hold that you infringe. If you publish a printed piece of paper with the program's source, then you likely do not infringe. Like I said somewhere, non-tech-savvy judges making a very questionable dead-tree vs. electronic distinction. What if I provide it on diskette, ready to do whatever with? There's no caselaw on this point. I doubt anyone would bring a case if you were distributing diskettes to give people electronic versions of the material of your speech or whatever. If you were selling the diskettes with the intent that people can now get the patented feature on their computer, then it gets tricky. I honestly don't know. 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: off topic again
Michael K. Edwards wrote: Patent is not copyright; you don't obtain a monopoly on describing your method, you obtain a monopoly on its commercial application. No patent prohibits you from making a computer program implementing any algorithm you like; but if you sell it as a solution to the problem addressed in the patent, without authorization from the patent holder, you are infringing. The same goes for selling its output, if that's covered by the patent -- compare against the enforcement of chemical process patents. Thanks for this informative comment. So I guess you would phrase the problem differently, but perhaps you agree on the existence of the problem. As far as I can tell, (a) mathematical problems are being used as problems in the patent domain (apart from solving a system of linear equations, a cipher is a mathematical transformation and the problem of finding one is a mathematical problem); (b) giving things away is considered just as bad as selling them; and (c) selling it as a solution for a different problem is considered just as much a violation as selling it as a solution for the same problem. I really hope one or all of these is not true, but every time I look at something in software, they all seem to be true. So I think Arnoud's point is that, if a formula or other abstract idea were patentable without any indication of the result being achieved, then a textbook would be just as much an infringement of this counterfactual patent as a computer program or a machine that embodies it. His make, use, or sell language is a little bit over-broad, but essentially accurate insofar as the maker may be liable for infringing use of the program by third parties even if he cannot be demonstrated to have made infringing use of it himself or to have profited from its sale. Well, there you go. You seem to have just said that I was right about (b) and (c). If people bought the textbook principally so they could copy down sections that amounted to an implementation of the patented invention, and proceeded to use them in an infringing way, then AIUI you could be liable for contributory infringement. I won't cry First Amendment; I'll note that a major part of the patent bargain is the requirement that patents be published, so that future work can be developed based on them! Which makes this result rather contrary to the goals of the patent system! applications of software techniques to practical problems are just as patentable when stated using process lingo as when using machine lingo, certainly now (per ATT v. Excel) but AFAICT all along. Well, it's straightforward, anyway. Any algorithm is a process by definition. The problem is that it's a *mathematical* process. If you don't have a prohibition on the patenting of mathematics -- and apparently we don't have one on the statute books in this country -- algorithms are obviously patentable. The really nasty thing is that I can losslessly transform a large number of other mathematical constructs into algorithms. Practical problems, of course, is not a restriction at all, since a patent on using a process to do one thing apparently applies to using the exact same process to do anything else too. :-P (Although a new patent can be granted for the novel use, AFAICT that just means that a user has to license *both* patents.) Not that patentable mathematics is bad for me personally; in fact, I may make money off of it. But it is patentable mathematics, and people shouldn't kid themselves that it's anything else. I am glad that I do not live in the dystopic fantasy world you describe, with incompetent judges obsessed by sophomoric deductions from Plato and easily led by the nose. Well, you're quite right that incompetent judges aren't clever enough to do deductions from Plato. Ignorance of logic is one of the reasons the law is such a mess. Most judges are not software engineers but few are utter fools, Well, they could just as well be crooks as fools. I describe them as fools purely out of politeness. The ADA case, in which the majority of the U.S.Supreme Court ruled that if you weren't too disabled to work, you weren't disabled -- thus rendering an entire section of the ADA meaningless and contravening the obvious intent of Congress -- was the point at which I knew that supposedly well-qualified judges often really are less competent at interpreting the law than your average high school student -- or else they're crooks. The Federal Circuit has had such a biased record in favor of patent holders that it's really hard to respect them at all (contrast the case law before the consolidation). Now there are obviously lots of thoughtful, honest, honorable judges who understand logic and statute interpretation. However, if bad judges are in at the higher levels, it doesn't really matter. Bound by higher court rulings and all that... Judges are no worse on average than
Re: EUPL draft
On Fri, 22 Jul 2005 20:23:33 +0100 Rich Walker wrote: 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. Oh my goodness, another license! :-( Someone should really explain people that license proliferation is a Bad Thing(TM)... 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. Thanks! My comments follow. Short summary: I think this license does *not* comply with the DFSG. Page breaks have been retained. EUPL v.01-EN European Union Public Licence V.01 EUPL © the European Community 2005 [...] The Source Code: the human-readable form of the Work which is required in order to make modifications to it. Very ambiguous: many different forms of the same work may satisfy this definition, which one is to be taken as Source Code? The Executable Code: any code which has generally been compiled and which is meant to be interpreted by a computer as a program. Limited in scope: does a PDF file qualify as Executable Code? I don't think so. It often doesn't qualify as the above-defined Source Code, either. Let's see if this turns up to be problematic... The Licensor: the physical or legal person that distributes and/or communicates the Work under the Licence. Weird: anyone who distributes is a Licensor! This could have 'interesting' consequences: wait and see... [...] © European Community 2005 Whoah! The copyright holder of the license text is the... the whole European Community! 8-| That seems pretty broad... It sounds like Copyright (c) The United States of America! :-/ Are we sure it does make sense? [...] 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, [...] sub-license rights in the Work or copies thereof. This probably addresses my concerns about the Licensor=distributor weirdness... [...] 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. This seems to be a legal no-op, as moral rights are inalienable. But it could be useful in case the law changes... 3. Communication of the Source Code The Licensor may provide the Work either in its Source Code form, or as Executable Code. Mmmh: may the Licensor (that is: anyone who distributes!) provide the Work in a form that is neither Source Code, nor Executable Code (e.g. a PDF file)? Or is that forbidden? 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. Remember this clause for later discussion... [...] The Licensee must cause any Derivative Work to carry prominent notices stating that he modified the work, OK. indicating the name and contact information of the Contributor. Hey! Cannot a Contributor be anonymous? Does this pass the Dissident Test? [...] 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. Since anyone who distributes is a Licensor, why repeating something that has already been stated above (the clause I marked as 'remember this')? Moreover, now it speaks about websites and thus is not technology-neutral. When the web is history, Licensees will be unable to indicate a website (I don't know when this will happen, but sooner or later the WWW will be obsoleted by something else...) [...] 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. A
OT: How I learned to stop worrying and love software patents
[Note to d-l readers: the subject is tongue-in-cheek, mmmkay? Film reference.] On 7/24/05, Nathanael Nerode [EMAIL PROTECTED] wrote: Michael K. Edwards wrote: Patent is not copyright; you don't obtain a monopoly on describing your method, you obtain a monopoly on its commercial application. No patent prohibits you from making a computer program implementing any algorithm you like; but if you sell it as a solution to the problem addressed in the patent, without authorization from the patent holder, you are infringing. The same goes for selling its output, if that's covered by the patent -- compare against the enforcement of chemical process patents. Thanks for this informative comment. So I guess you would phrase the problem differently, but perhaps you agree on the existence of the problem. As far as I can tell, (a) mathematical problems are being used as problems in the patent domain (apart from solving a system of linear equations, a cipher is a mathematical transformation and the problem of finding one is a mathematical problem); (b) giving things away is considered just as bad as selling them; and (c) selling it as a solution for a different problem is considered just as much a violation as selling it as a solution for the same problem. I really hope one or all of these is not true, but every time I look at something in software, they all seem to be true. I think these are all judgment calls under the current system, and doomed to be judgment calls under any system that is making an honest effort to promote progress in the useful arts and sciences. Let's take your example of ciphers as mathematical problems. Cryptanalysis is higher math, all right, and no patent on a technique of cryptanalysis should be permitted to issue (and as far as I know, none ever has). But the design of a cipher resistant to cryptanalysis shades over into industrial application of that math as well as the more mundane techniques of efficient coding, just as the design of a corrosion-resistant alloy is an industrial application of surface chemistry as well as metallurgy per se. As for (b) and (c): There is not ordinarily a distinction between giving away and selling an infringing item -- after all, there are ways to profit from undermining part of a rival's business model other than extracting per-unit revenues from his potential customers. And while the domain of application and the nature of the useful result are supposed to be part of the statement of a patent's claims, there is some leeway to argue that the disclosure equally teaches an invention in a closely related area (such as video vs. still image compression). But constructing a device or writing a program that has both infringing and non-infringing uses, and taking some care not to encourage or extract revenues from infringing use, can be a pretty good defense against a contributory infringement claim -- especially where the novelty claimed in the patent is limited to applying a well-known technique to an unexpected problem. (IANAL, TINLA.) There isn't a lot of litigation (as opposed to bluster, brinksmanship, and political posturing) on software patents, and AFAICT what there is is pretty benign. I think the State Street decision is somewhat dubious (as I have written earlier), simply because it risks a major change in the effective scope of patent protection without any indication of a legislative or Supreme Court mandate to do so. Ditto EPO parallels such as Sohei (T 769/92) and Pettersson (T 1002/92). The useful arts and sciences are traditionally understood to be those that manipulate the natural world, not markets. But I don't really have any problem with jettisoning the dualist baggage and adopting the Alappat test to call digital results tangible if they represent a useful advance in the state of the art in an applied field. In any case, just because a patent issues doesn't mean it isn't complete crap. Don't be fooled into lumping USPTO howlers (or, for that matter, their EPO parallels) in with those which have survived scrutiny in an adversarial setting. [snip] applications of software techniques to practical problems are just as patentable when stated using process lingo as when using machine lingo, certainly now (per ATT v. Excel) but AFAICT all along. Well, it's straightforward, anyway. Any algorithm is a process by definition. The problem is that it's a *mathematical* process. If you don't have a prohibition on the patenting of mathematics -- and apparently we don't have one on the statute books in this country -- algorithms are obviously patentable. Whether or not the statute calls it out explicitly, mathematics per se is in the domain of laws of nature, natural phenomena, and abstract ideas (quoted from Diehr, paraphrasing cases going back to 1853), which are reliably excluded from patentable subject matter. I invite you to question the assumption that algorithms are mathematics.
Re: generated source files, GPL and DFSG
On Sun, 24 Jul 2005 03:17:59 -0400 Nathanael Nerode wrote: My gut instinct is no, it's fine, put it in main, because the compiler is not required by the system, since the system functions fine without recompiling the graphics (and will continue to). I may be wrong, though! Huh? Are you saying that a program can be shipped in main even if it's written in a language with no DFSG-free compilers?!? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpLd1bhZpRCW.pgp Description: PGP signature
Re: Is an upgrade to the Open Publication License possible?
On Sun, 24 Jul 2005 03:37:05 -0400 Nathanael Nerode wrote: And, of course, the license options are non-free, but nobody uses them anyway. I wish this were true... :-( I recall seeing those clearly non-free options used more than once (and take into account that I haven't seen so many OPL'd works!). -- :-( 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 pgpp3a9zSnlPw.pgp Description: PGP signature
Re: Question about license compatibility
On Sat, 2005-07-23 at 21:46 -0700, Sean Kellogg wrote: 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. Thanks for the clarification. 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? The old crypto export regulations in the US did have the effect of prohibiting Debian developers in the US from doing any work on crypto in Debian. See also the MIT Kerberos bones project, from which Heimdal Kerberos sprung. So, it would seem, the answer to your question is yes. On the other hand, in the US, there's a sense in which sharing source code has freedom of speech implications (see Bernstein v. DOJ and the various projects to print crypto code on T-shirts). This limits the extent to which the government can use export regulations to forbid citizens from participation in free software activities, assuming the linkage is upheld. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: How I learned to stop worrying and love software patents
Michael K. Edwards wrote: ... On 7/24/05, Nathanael Nerode [EMAIL PROTECTED] wrote: ... I invite you to question the assumption that algorithms are mathematics. My preferred US dictionary (American Heritage, third edition) has it that an algorithm is a step-by-step problem solving procedure, and goes on to describe the computational specialization of this idea. That's not really theoretical mathematics any more than a titration technique is theoretical chemistry. Algorthms are, in a general sense, semiotics, for the step-by-step problem solving procedure processes data. When the processing is to be done by a digital computer, the instruction set in which the algorithm can be encoded sets and encloses, since Alan Turing's seminal work in the 1930's, the procedure into the realm of theoretical mathematics. And until Alonzo Church's thesis (cathegorizing this enclosure) is disproved, this enclosure is definite. Either way, whether specifically as theoretical mathematics (via computers), or generally, for being semiotics, algorithms are in the domain of laws of nature, natural phenomena, and abstract ideas (refer to Charles Peirce, Ferdinand de Sausurre or Umberto Eco going back to 1867, only foourteen years later than the oldest quote allegedly paraphrased from Diehr) -- Prof. Pedro Antonio Dourado de Rezende /\ Ciencia da Computacao (61)3072702-212 / \ Universidade de Brasilia, DF, Brasil /\ ?http://www.cic.unb.br/docentes/pedro/sd.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: How I learned to stop worrying and love software patents
On 7/24/05, Pedro A.D.Rezende [EMAIL PROTECTED] wrote: Algorthms are, in a general sense, semiotics, for the step-by-step problem solving procedure processes data. When the processing is to be done by a digital computer, the instruction set in which the algorithm can be encoded sets and encloses, since Alan Turing's seminal work in the 1930's, the procedure into the realm of theoretical mathematics. And until Alonzo Church's thesis (cathegorizing this enclosure) is disproved, this enclosure is definite. Yes, all very lovely, I've read Douglas Hofstadter's books too. Likewise, chemistry is physics and psychology is biology. But that doesn't tell us anything about the skills applied by practicioners in the field (hint: most coders can't do Big O analysis, let alone solve an integral), or about which useful arts and sciences the Constitution authorizes Congress to encourage through the patent monopoly. If you want to understand how far a court is willing to go with you along the mathematics is in the realm of abstract ideas and therefore unpatentable, you have to step from Church and Turing's world into Von Neumann and T. J. Watson's. Either way, whether specifically as theoretical mathematics (via computers), or generally, for being semiotics, algorithms are in the domain of laws of nature, natural phenomena, and abstract ideas (refer to Charles Peirce, Ferdinand de Sausurre or Umberto Eco going back to 1867, only foourteen years later than the oldest quote allegedly paraphrased from Diehr) Nice allegedly -- translates to I didn't bother to check, right? My quote from Diehr (1981) was exact; the Diehr opinion in turn quotes from various other cases back to Le Roy v. Tatham (1853). Here's the Diehr link again, for your convenience: http://laws.findlaw.com/us/450/175.html . Allow me to suggest that, if you do read it this time in search of rebuttal material, you at least read Section III of both opinion and dissent. You might also evaluate the merits of Judge Plager's response to the concerns raised in Justice Stevens's Diehr dissent, found in Section D of ATT v. Excel ( http://caselaw.lp.findlaw.com/data2/circs/Fed/981338v2.html ). In any case, the writings of the most respected of philosophers and novelists are of less precedential value than the most pedestrian of appellate court decisions. It is entirely possible that policy-makers in Brasil have drawn the line differently -- as is well within their rights -- but to prove it to me you will need to show me how it works in your courts. Cheers, - Michael P. S. Watch for a possible grant of certiorari in Laboratory Corp. of America Holdings v. Metabolite Laboratories, Inc., which could be followed by a Supreme Court ruling giving better guidance on the whole laws of nature, natural phenomena, and abstract ideas business from Diehr. The heads-up came from http://www.ipfrontline.com/printtemplate.asp?id=4357 , which lists a number of interesting upcoming decisions.
Re: Is an upgrade to the Open Publication License possible?
On Sun, 2005-07-24 at 03:37 -0400, Nathanael Nerode wrote: Well, these are the problems with it: Lemme see if I can condense these down. I had a hard time reading your response. Add explicit permission to make and distribute modified versions. Remove or soften requirements for author publisher names on book covers, esp. for modified versions. Add explicit allowance of pseudonyms for identifying contributors to modified versions. Modify requirement to provide location of original document. These sound more like collateral damage than that the license was designed to be non-free. That is, I think that a salvaged license would be reasonably in the spirit of the original. The controlling body, if such a body exists, wouldn't be betraying the copyright holders' intentions by making these changes, as far as I can tell. I'm going to join the OPL authors' list and see what I can do to get these changes effected. ~Evan -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
LGPL module linked with a GPL lib
Hi, The GStreamer suite ships a lot of plugins which are dlopened() when needed. Some of them link with GPL libraries. I received a bug report (#317129) to change the copyright files of libgstreamer0.8-0 and gstreamer0.8-mad to GPL. The upstream README mentions the situation, so I think I will mention it in the README.Debian with the next upload, but is the copyright supposed to reflect this? Does the whole distribution switch to GPL? I believe not, but would like a confirmation. 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: LGPL module linked with a GPL lib
On Sun, 2005-07-24 at 20:50 +0200, Loïc Minier wrote: The GStreamer suite ships a lot of plugins which are dlopened() when needed. Some of them link with GPL libraries. I received a bug report (#317129) to change the copyright files of libgstreamer0.8-0 and gstreamer0.8-mad to GPL. The upstream README mentions the situation, so I think I will mention it in the README.Debian with the next upload, but is the copyright supposed to reflect this? Does the whole distribution switch to GPL? I believe not, but would like a confirmation. The copyright of all the source code is independent of its dependencies. Thus, the license of the source is the LGPL, full stop. The copyright of the plugin binary itself is affected by dynamically linked libraries, since it's the combined work that's involved. I would expect the MAD plugin binary is effectively the GPL, since it cannot function without the MAD library. Still, technically, the binary has its own license, which is only required to be GPL-compatible (as the LGPL is). The copyright of the rest of GStreamer depends on how it's distributed. In Debian, it's clear that GStreamer is distributed with MAD support, which makes its effective license the GPL. However, someone interested in distributing proprietary plugins or apps for GStreamer (as part of a derivative, for example) could do so by removing the GPL plugins from the distribution before adding the non-free bits. This wouldn't even require a recompile to do. Unless, of course, Debian elects to exercise the upgrade-to-GPL clause in its particular copies of GStreamer. As I understand it, you're not asking about what's allowed, but what's required, so this isn't relevant. All this probably warrants mention in the copyright file, but overall I do not think it's accurate to say that the license, effective or otherwise, for GStreamer is the GPL. There are too many exceptions. IANAL, TINLA, etc.
Re: OT: How I learned to stop worrying and love software patents
I wrote, in response to Prof. de Rezende: Yes, all very lovely, I've read Douglas Hofstadter's books too. ... This was a cheap shot, and I'm ashamed to re-read it. I didn't mean by this that Prof. de Rezende was not right to ground the algorithms are mathematics perspective in the primary literature of computer science, or even that it isn't more correct in a theory-of-knowledge sense than other perspectives. It's just that I don't think this calculus is helpful when interpreting a patent statute, because that formal relationship is neither what the legislators had in mind nor representative of the economics of the field. In any case, Pedro didn't get those ideas secondhand from Douglas Hofstadter, nor would they be any less valid if he had (I rather enjoyed Hofstadter's books myself and appreciate his popularization of topics that would perhaps otherwise be much less widely discussed outside academia). It really wasn't nice of me to dismiss Pedro's comments in those terms, and I apologize and ask his pardon. Cheers, - Michael
