Re: LGPL module linked with a GPL lib
On Mon, Jul 25, 2005 at 09:17:25AM -0500, Jeff Licquia wrote: > On Mon, 2005-07-25 at 11:59 +0200, Loïc Minier wrote: > > GStreamer's build process builds separate binaries for the various > > plugins, these are then dlopened when requested. > > > > I would personnally think that installing only Debian's GStreamer > > packages that are linked to LGPL libraries doesn't make your GStreamer > > installation / packages GPL (that is the build process has nothing to > > do with the resulting packages). > > > > I would even thing that installing GStreamer plugins packages which > > link to GPL libraries don't make your installation nor your running > > GStreamer applications GPL (that is only dlopening() something GPL > > makes the whole program in memory GPL, while it remains in memory). > > In a technical sense, you're right, in that each binary retains its > separate copyright status. Most people, however, are concerned about > the restrictions effectively placed on them more than about the specific > status of any particular binary. I think it'd be a stretch to say that this prohibits proprietary gstreamer plugins, but I doubt you could *include* them in a gstreamer distribution. Third-party ones should still be okay. > I see two ways in which this practically effects people using Debian. > One, Debian could decide to package a plugin linking to a free but > GPL-incompatible library, such as OpenSSL. Two, others might want to > add a few proprietary plugins on top of Debian and distribute the > result. So, I'd say that the former is probably prohibited and the latter is probably allowed. Incorporating proprietary plugins into Debian is somewhere around the borderline case, but I can't see that ever being an issue. > This seems worth mentioning in the copyright file, even if the license > itself doesn't change. Yeah, as far as the above goes. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Unsubscription Confirmation
Thank you for subscribing. You have now unsubscribed and no more messages will be sent. -- 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 01:01:07AM +0200, Florian Weimer wrote: > * Steve Langasek: > >> It's clear from the context (and previous discussion) that this has to > >> be interpreted as "software". > > No, it isn't. Considering we went through all the effort of a GR to amend > > the DFSG and this still says "program", not "software", I don't see how you > > can claim it *has* to be read as "software". > So you think that the DFSG clauses 2, 6, 7, 8 do not apply to > documentation, only to executables? > This is certainly an interesting position. Whether it's a valid one > is indeed harder to decide than I thought. I think that clauses 6, 7, and 8 are applicable to documentation and data as well as to programs, and I think that they're rules that Debian should follow for everything we distribute. I think that clause 2 is *not* clearly applicable to things that aren't programs. Aside from (or perhaps entwined with) the issue of trying to reach a consensus on what constitutes "source" for all of these things, I think we need to consider what the practical aims are that lead us to insist on the availability of source. The ones that strike me as most important are: being able to recompile the source code for porting (to a different architecture, a different library ABI, etc); being able to fix bugs (and security bugs in particular) in the program; and allowing our users to modify the work to meet their needs. Well, the first of these isn't applicable to data; it's just not meaningful to talk about "porting" of data (just as this is largely meaningless when discussing programs written in interpreted languages). It may be useful to be able to *convert* your data from one form to another, but that's not the same thing as porting; and there may be a particular form that's more convenient for use in converting to other forms, but this may or may not be the "preferred form for modification" which most people seem to be arguing should be the definition of source, so insisting on source code here doesn't ensure that we get this benefit. Fixing bugs is important for data as well as for programs, of course; though it's much less likely that data or documentation would contain a security bug or other RC bug. But more importantly, the presence or absence of true "source" in the case of data and documentation is simply not a good proxy for the question of whether we can fix bugs. Source v. binary is important for programs, because fixing bugs in the machine code for a typical program is several orders of magnitude more difficult than fixing the source and recompiling. This is not the case for most data formats! Although there are some opaque documentation formats like PDF that are a concern, most data formats (especially images and video) are edited directly using binary editors; and as for fonts, my personal experience is that trying to edit them is a PITA regardless of whether you have a "source" format available. :P And finally, giving our users the ability to modify data in the same manner that the author would is a nice idea, but they only actually get this if Debian is going to *distribute* all of those "sources". Many of these are quite large (much larger than the resulting target data files), and there's far from universal agreement that Debian *should* distribute all of these pristine sources. I don't think it makes any sense to insist that our upstreams make available sources that we ourselves are unwilling to commit to distributing. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: LGPL module linked with a GPL lib
Hi, On Mon, Jul 25, 2005, Jeff Licquia wrote: > >From the GPL: > > Activities other than copying, distribution and modification are not > > covered by this License; they are outside its scope. The act of > > running the Program is not restricted... > So the particular details of how things are distributed in memory while > running aren't directly relevant. > Modification and distribution are what matters, and it's clear from > looking at the packages that GStreamer is distributed in Debian in > conjunction with GPLed bits in a manner that's more than "mere > aggregation". I'm not sure to understand: you mean that since some LGPL GStreamer plugins are shipped in Debian along with GPL packages and they can play together means that the whole is GPLed? Would it be ok to have a copyright file along these lines: "The source code for all plugins in the GStreamer Plugins source package is licensed under the LGPL, however some plugins are built with the help of header files from GPL libraries, and will be linked to GPL libraries when loaded in memory. Thus, using these plugins will switch their license to GPL, and you can only use them in applications with a license compatible with the GPL. You should have received a copy of the GPL and LGPL licenses ..." Is a list of plugins necessary? I guess it's up to the interested person to check, nowadays it's relatively easy with tags and Debian's "copyright" files, and I don't want to maintain such a list. 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
** Loïc Minier :: > Hi, > > On Mon, Jul 25, 2005, Jeff Licquia wrote: > > >From the GPL: Activities other than copying, distribution and > modification are not > > > covered by this License; they are outside its scope. The act > > > of running the Program is not restricted... > > So the particular details of how things are distributed in > > memory while running aren't directly relevant. Modification and > > distribution are what matters, and it's clear from looking at > > the packages that GStreamer is distributed in Debian in > > conjunction with GPLed bits in a manner that's more than "mere > > aggregation". > > I'm not sure to understand: you mean that since some LGPL > GStreamer plugins are shipped in Debian along with GPL packages > and they can play together means that the whole is GPLed? > > Would it be ok to have a copyright file along these lines: > > "The source code for all plugins in the GStreamer Plugins source > package is licensed under the LGPL, however some plugins are > built with the help of header files from GPL libraries, and will > be linked to GPL libraries when loaded in memory. Thus, using > these plugins will switch their license to GPL, and you can only > use them in applications with a license compatible with the GPL. > > You should have received a copy of the GPL and LGPL licenses ..." > > Is a list of plugins necessary? I guess it's up to the > interested person to check, nowadays it's relatively easy with > tags and Debian's "copyright" files, and I don't want to maintain > such a list. I find this discussion ultimately absurd. Debian is *not* distributing a derivative work. Debian does *not* distribute a work that includes both plugins/libraries. The fact that the things are (dynamically) linked at run time, especially combined with the fact that the plugins are opened with dlopen() and use stable API, is *more* than enough to lift any (inexistent IMHO) "no-link" requirement of the GPL. Please don't do that. -- HTH, Massa
Re: OT: How I learned to stop worrying and love software patents
Michael K. Edwards wrote: > I see your "weasel-words" and raise you "horse-pucky". You are > impugning the intelligence and integrity of a whole class of dedicated > public servants, whose actions are subject to more public scrutiny > that any other branch of government, on pure hearsay. Tell me what > cases you would have decided differently and why -- taking into > account the actual constraints of statutory language and stare decisis > -- and then we can talk about where the error lies on the spectrum > from ignorance to corruption. Hmm. Sticking to patents for the time being, let's note that no court bothered to actually test whether the patent or copyright system falls within the Constitutional power to "promote the Progress of Science and the Useful Arts". Given this, Diamond v. Chakrabarty is wrongly decided; it rules that the Congressional intent to allow "anything under the sun that is made by man" to be patentable subject matter is correct, and furthermore that it is the principle by which questions of patentable subject matter should be interpreted. But that's a issue of major legal philosophy. Well, here's a nice simple one for you. Diamond v. Diehr was wrongly decided; it overturned Parker v. Flook for no particularly good reason, and didn't even have the decency to admit it. "Respondents' claims must be considered as a whole, it being inappropriate to dissect the claims into old and new elements and then to ignore the presence of the old elements in the analysis." This might have been avoided had the following actually been true: "In this case, it may later be determined that the respondents' process is not deserving of patent protection because it fails to satisfy the statutory conditions of novelty under 102 or nonobviousness under 103"; however, footnote 33 of the dissent makes clear that this was not the case. The patent consisted of combining a number of preexisting devices --- including the preexisting temperature sensors -- in a way which was not just obvious, but pretty much unavoidable -- everything in the industry points to it like a laser. Given the description of the problem, *I* would have come up with it, and I don't know the first thing about the subject. The rejection of the Flook method of claim analysis actually rejected precedents dating back to 1854, as noted by Stevens in the dissent. Stevens's dissenting opinion is spot-on. As usual for his later work. AT&T v. Excel was decided wrongly, of course. This court, unlike previous ones, didn't bother to look up the meaning of the terms "formula", "algorithm", or "equation", which can only be described as ignorance. But that's a small matter. 'Thus, the Alappat inquiry simply requires an examination of the contested claims to see if the claimed subject matter as a whole is a disembodied mathematical concept representing nothing more than a "law of nature" or an "abstract idea," or if the mathematical concept has been reduced to some practical application rendering it "useful."' Yep, this is perfectly parallel to arguments allowing patentable artwork. I invent a unique piece of artwork, but if I render it "useful", it's not a "law of nature" or an "abstract idea". "In Alappat , we held that more than an abstract idea was claimed because the claimed invention as a whole was directed toward forming a specific machine that produced the useful, concrete, and tangible result of a smooth waveform display." Yep, my invention as a whole produces the useful, concrete, and tangible result of a pretty picture on a screen. This is the bottom of the slippery slope, as someone wrote in Spectrum. Of course, the broad patentable subject matter wouldn't be nearly as serious a problem if the requirement of non-obviousness/non-triviality had any teeth. But it doesn't. In Re Sang Su Lee, Teleflex v. KSR and the entire line of cases which demand specific suggestions in a particular written reference to determine obviousness are wrongly decided. (And they aren't compelled by the Supreme Court precedents, either.) I actually think this line of cases has done much more serious damage to the patent system than anything else -- it's the primary reason for the substantial drop in patent quality. Patent examiners know that if they reject a patent for obviousness without demonstrating exactly why it's obvious with voluminous written references, they will be overturned. It's very hard to prove something "obvious" now, and very very easy to get it declared non-obvious. Your choice whether this is incompetence or corruption, but it's definitely one or the other. The number of patents overturned on obviousness grounds has dropped from the historical 30-40% to nearly nothing -- and it's not because fewer are being filed. :-P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [osol-discuss] Debian with OpenSolaris: a broken dream]
* Alvaro Lopez Ortega: > Some days ago I asked about the viability the idea of creating a new > architecture of Debian using the OpenSolaris stack. Just the kernel or libc as well? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [osol-discuss] Debian with OpenSolaris: a broken dream]
Florian Weimer wrote: >> Some days ago I asked about the viability the idea of creating a new >> architecture of Debian using the OpenSolaris stack. > > Just the kernel or libc as well? That is something in which we will have to think if there isn't any issue with the license. By the moment there isn't a detailed technical plan over the desk, it is just a proposal. The first step is to check if the CDDL meets with the DFSG. -- Greetings, alo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: [osol-discuss] Debian with OpenSolaris: a broken dream]
* Alvaro Lopez Ortega: > Florian Weimer wrote: > >>> Some days ago I asked about the viability the idea of creating a new >>> architecture of Debian using the OpenSolaris stack. >> >> Just the kernel or libc as well? > > That is something in which we will have to think if there isn't any > issue with the license. By the moment there isn't a detailed > technical plan over the desk, it is just a proposal. The first step > is to check if the CDDL meets with the DFSG. Ah, okay. A CDDLed libc is impossible for Debian because you can't distribute GPLed software that links to it. The operating system exception deliberately does not apply when you are distributing an operating system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hi
This message is being sent to you automatically in response to an email that you sent to <[EMAIL PROTECTED]>. Most likely, you tried to reply to an email that has been sent through this service. If you did not send an email to <[EMAIL PROTECTED]>, please ignore this message. The metacolo Anonymizing Remailer is a free service that allows individuals including crime victims, domestic violence victims, persons in recovery, and others, such as those living under oppressive regimes, to communicate confidentially in a manner that ensures their privacy under even the most adverse conditions. To block individuals using this remailer from sending email to your address in the future, please send a message to <[EMAIL PROTECTED]> containing the line destination-block debian-legal@lists.debian.org anywhere in the body text of the email. You can simply forward this entire email to <[EMAIL PROTECTED]> using your email program for your current email address to be permanently blocked from users of the metacolo Anonymizing Remailer. For more information about the metacolo Anonymizing Remailer Administrator's strict anti-abuse policy, please send a blank email to <[EMAIL PROTECTED]> Sincerely, -- The metacolo Anonymizing Remailer Administrator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LGPL module linked with a GPL lib
On Tue, 2005-07-26 at 11:14 -0300, Humberto Massa Guimarães wrote: > I find this discussion ultimately absurd. Debian is *not* > distributing a derivative work. Debian does *not* distribute a work > that includes both plugins/libraries. The fact that the things are > (dynamically) linked at run time, especially combined with the fact > that the plugins are opened with dlopen() and use stable API, is > *more* than enough to lift any (inexistent IMHO) "no-link" > requirement of the GPL. I find most of this response confusing. First of all, it's clear that Debian *is* distributing a derived work based on GPLed libraries, called "Debian GNU/Linux". The specific case in question may fall under the "mere aggregation" clause of the GPL, but then this is the point you should argue. I abhor imprecision in these discussions, as they are the breeding ground for all kinds of myths and speculation. (Not that I am immune to imprecision, or that I am not occasionally a myth-monger in my own right. But I welcome the correction.) Second, you seem to be asserting that an app and its dynamically linked libraries do not constitute a derived work based on both for the purposes of the GPL. Rather than debate this point, I think it best to point out that this runs counter to accepted precedent within Debian that dates back a long time; see the KDE/Qt controversy for a famous example. Basing conclusions on this past precedent is not "absurd"; indeed, it would seem that the onus is on you to prove your assertion. That's probably enough for starters. If I am indeed confused and you are correct, then there doesn't seem much point to proceed to the dlopen() question.
Re: LGPL module linked with a GPL lib
Jeff Licquia writes: > On Tue, 2005-07-26 at 11:14 -0300, Humberto Massa Guimarães wrote: >> I find this discussion ultimately absurd. Debian is *not* >> distributing a derivative work. Debian does *not* distribute a work >> that includes both plugins/libraries. The fact that the things are >> (dynamically) linked at run time, especially combined with the fact >> that the plugins are opened with dlopen() and use stable API, is >> *more* than enough to lift any (inexistent IMHO) "no-link" >> requirement of the GPL. > > I find most of this response confusing. > > First of all, it's clear that Debian *is* distributing a derived work > based on GPLed libraries, called "Debian GNU/Linux". The specific case > in question may fall under the "mere aggregation" clause of the GPL, but > then this is the point you should argue. US copyright law distinguishes between the classes of work called "derivative works" and "compilations". The usual reading is that a "compilation" or "collective work" (which is a subset of "compilation") is what the GPL means by "mere aggregation", and a "derivative work" is covered by the stricter terms. The Berne Convention makes a similar distinction of a "collection" versus the works that comprise the collection. A compilation or collective work under US law is not necessarily a derivative work of any of its components. The GPL's use of "derivative" and "derived" is fuzzy in this sense, which is one reason the terms from copyright law are used more often than the GPL's terms. Michael Poole
CECILL license status?
[please cc me, i'm not subscribed to d-l] Hi, new digikamimageplugin > 0.7.3 release a) contains now a header file that uses the CeCILL license. http://www.cecill.info/index.en.html http://www.cecill.info/licences.en.html b) this header file is included in files distributed under GPL. Checking http://www.nl.debian.org/legal/licenses/ and googling find lots of discussion, but I found no 'final' debian-legal statement. I'm still not sure what the status of CECILL with respect to DSFG is: o okay for main o goes to non-free o undecided: remove 'CECILL' code for now Thx, Achim -- To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On Tue, 26 Jul 2005 05:17:35 -0700 Steve Langasek wrote: > I think that clauses 6, 7, and 8 are applicable to documentation and > data as well as to programs, and I think that they're rules that > Debian should follow for everything we distribute. > > I think that clause 2 is *not* clearly applicable to things that > aren't programs. I fail to understand how you justify your reading of "program" as program in DFSG#2 while you read "program" as work in the other guidelines at the same time. IOW, why do you agree with me that the other guidelines must be applied to anything in Debian (excluding texts of licenses covering the works, as often reminded) and, at the same time, disagree with me on the scope of DFSG#2, stating that it applies to programs only. Moreover, in the long discussions about the GFDL, the "what is software?" tangent came up many many times. Several people pointed out that there's no clear line to tell programs and non-programs apart: the distinction is blurred (many examples were proposed at the time: e.g. PostScript is a Turing-complete programming language, literate programming creates works that are both program and documentation, ...) Which criterion are you proposing to tell *when* DFSG#2 must be taken into account? > Aside from (or perhaps entwined with) the issue of > trying to reach a consensus on what constitutes "source" for all of > these things, which is not so difficult as you seem to imply, IMHO... > I think we need to consider what the practical aims are > that lead us to insist on the availability of source. Are we *again* going to talk about practical points of view? From a practical point of view, nVidia proprietary drivers seem to work well and make many people happy: are we going to ship them in main? I really hope we aren't! > > The ones that strike me as most important are: being able to > recompile the source code for porting (to a different architecture, a > different library ABI, etc); being able to fix bugs (and security bugs > in particular) in the program; and allowing our users to modify the > work to meet their needs. Please add * avoiding dependence on a single provider * allowing user to study how the work is created by looking at its internals > > Well, the first of these isn't applicable to data; That's true. [...] > It may be useful to be able to *convert* your data from > one form to another, but that's not the same thing as porting; and > there may be a particular form that's more convenient for use in > converting to other forms, but this may or may not be the "preferred > form for modification" which most people seem to be arguing should be > the definition of source, so insisting on source code here doesn't > ensure that we get this benefit. Could you show a concrete practical example in which the "preferred form for modification" is *not* the preferred form to start with for conversions to other formats? > > Fixing bugs is important for data as well as for programs, of course; > though it's much less likely that data or documentation would contain > a security bug or other RC bug. So you say that lacking the preconditions for fixing non-RC bugs is fine... > But more importantly, the presence or > absence of true "source" in the case of data and documentation is > simply not a good proxy for the question of whether we can fix bugs. > Source v. binary is important for programs, because fixing bugs in the > machine code for a typical program is several orders of magnitude more > difficult than fixing the source and recompiling. This is not the > case for most data formats! Although there are some opaque > documentation formats like PDF that are a concern, most data formats > (especially images and video) are edited directly using binary > editors; With no source, how are you going to fix a bug due to the camera position in a pov-ray generated image? [...] > And finally, giving our users the ability to modify data in the same > manner that the author would is a nice idea, but they only actually > get this if Debian is going to *distribute* all of those "sources". That's how it works for programs too... > Many of these are quite large (much larger than the resulting target > data files), and there's far from universal agreement that Debian > *should* distribute all of these pristine sources. Correct me if I'm wrong: Linux kernel source packages are much larger than the corresponding vmlinuz images... Are we going to stop distributing kernel sources? > I don't think it > makes any sense to insist that our upstreams make available sources > that we ourselves are unwilling to commit to distributing. I think we *should* be willing to distribute source: that's one of the key elements of free software! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint
Re: Does DFSG#2 apply to non-programs? [was: Re: generated source files, GPL and DFSG]
On Wed, 27 Jul 2005 00:28:23 +0200 Francesco Poli wrote: [some hopefully useful contributions to the discussion, but with *wrong* Mail-Followup-To:] Please, ignore the wrong Mail-Followup-To: set in the my previous message. I forgot to disable it! :-( I really really apologize. Sylpheed authors should really implement a decent Mail-Followup-To: handling... :-( -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp0IbIbxLOu5.pgp Description: PGP signature
Re: OT: How I learned to stop worrying and love software patents
Summary: There is a real concern with the integrity of the patent process underlying the Federal Circuit's refusal to condone summary patent invalidation without an adequate scrutiny for triable questions of fact. On 7/26/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Hmm. Sticking to patents for the time being, let's note that no court > bothered to actually test whether the patent or copyright system falls > within the Constitutional power to "promote the Progress of Science and > the Useful Arts". Given this, Diamond v. Chakrabarty is wrongly > decided; it rules that the Congressional intent to allow "anything under > the sun that is made by man" to be patentable subject matter is correct, > and furthermore that it is the principle by which questions of > patentable subject matter should be interpreted. But that's a issue of > major legal philosophy. Both the majority and the dissent in Chakrabarty agreed that the only question before the court was a narrow one of statutory interpretation. Even so, Chief Justice Burger addressed the constitutional concern: It is, of course, correct that Congress, not the courts, must define the limits of patentability; but it is equally true that once Congress has spoken it is "the province and duty of the judicial department to say what the law is." Marbury v. Madison, 1 Cranch 137, 177 (1803). Congress has performed its constitutional role in defining patentable subject matter in 101; we perform ours in construing the language Congress has employed. In so doing, our obligation is to take statutes as we find them, guided, if ambiguity appears, by the legislative history and statutory purpose. Here, we perceive no ambiguity. The subject-matter provisions of the patent law have been cast in broad terms to fulfill the constitutional and statutory goal of promoting "the Progress of Science and the useful Arts" with all that means for the social and economic benefits envisioned by Jefferson. Broad general language is not necessarily ambiguous when congressional objectives require broad terms. One can reasonably argue whether Congress excluded bacteria from the Plant Patent Act because they were satisfied with existing administrative and judicial interpretations such as In re Arzberger (the majority's guess), or because the only category of animate "inventions" they intended to authorize was plants (the dissent's). But at least five generations of Supreme Court jurisprudence have agreed that deciding what boundaries on patentable subject matter will best "promote the progress of science and useful arts" is Congress's job, and all the judiciary can do is try to construe the law correctly based on the fact patterns presented. It's interesting that you identify this as a question of legal philosophy, though. I would agree to some extent, noting the parallel to non-obviousness as discussed in Justice Douglas's concurrence in A&P Tea v. Supermarket (1950), and following it back to Justice Bradley in Atlantic Works v. Brady (1882). But the judicially created (Hotchkiss v. Greenwood, 1851) doctrine of non-obviousness was codified by Congress in 1952, and at the next opportunity (Graham v. John Deere, 1966, about which more later) the Supreme Court adopted Congress's "more practical test of patentability" in Section 103. I would suggest that the Supreme Court's deference to Congress where the scope of patentability is concerned, once the non-obviousness requirement was duly codified, foreshadows the corresponding view of copyright in Eldred v. Ashcroft. I think it likely that none of the Justices considered the Sonny Bono Act wise; but as the Eldred opinion states in its concluding paragraph, "The wisdom of Congress' action ... is not within our province to second guess." > Well, here's a nice simple one for you. > > Diamond v. Diehr was wrongly decided; it overturned Parker v. Flook for > no particularly good reason, and didn't even have the decency to admit it. > > "Respondents' claims must be considered as a whole, it being > inappropriate to dissect the claims into old and new elements and then > to ignore the presence of the old elements in the analysis." To my eyes, Footnote 12 of the Diehr opinion does a good job of explaining why they didn't need to overrule Flook to arrive at this conclusion: It is argued that the procedure of dissecting a claim into old and new elements is mandated by our decision in Flook which noted that a mathematical algorithm must be assumed to be within the "prior art." It is from this language that the petitioner premises his argument that if everything other than the algorithm is determined to be old in the art, then the claim cannot recite statutory subject matter. The fallacy in this argument is that we did not hold in Flook that the mathematical algorithm could not be considered at all when making the 101 determination. To accept the analysis proffered by the petitioner would, if carried to its extreme, make all inventi
Re: LGPL module linked with a GPL lib
On 7/26/05, Michael Poole <[EMAIL PROTECTED]> wrote: [snip] > A compilation or collective work under US law is not necessarily a > derivative work of any of its components. The GPL's use of > "derivative" and "derived" is fuzzy in this sense, which is one reason > the terms from copyright law are used more often than the GPL's terms. Almost -- a compilation or collective work is almost _never_ a derivative work of any of its components. The GPL drafter just plain got it wrong in Section 0, and the legal definition in 17 USC 101 (and its parallels in other Berne Convention countries) overrides the GPL's incorrect paraphrase. Extensively discussed on debian-legal in the last few months (disclaimer: only those few d-l participants with actual legal credentials seem to agree with me); you might start at http://lists.debian.org/debian-legal/2005/07/msg00336.html . Cheers, - Michael (IANAL, TINLA)
Re: LGPL module linked with a GPL lib
I wrote: > ... only those few d-l participants with actual legal credentials seem to > agree with me ... Er, that overreaches a bit in both directions; sorry. I'm more strident on the topic than the people with credentials are, and there are certainly other d-l regulars who question the FSF FAQ's stance on the matter. I just meant to say that I seem to be in a minority but it's a minority in which I'm comfortable. :-) Cheers, - Michael
