Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
* Daniel Jacobowitz | On Wed, May 11, 2005 at 03:50:29PM +0200, Tollef Fog Heen wrote: | > * Andreas Barth | > | > | Agreed. We should IMHO make such a requirement to be part of etchs | > | release policy. | > | > How are you going to solve the problem ia32-libs solves if not in this | > way? | > | > (Unless we want to make etch fully multiarchified, which I don't think | > we will.) | | I didn't see the previous message, so I'm not sure exactly what problem | you're referring to [...] Shipping other source and binary packages in your own source package. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, May 11, 2005 at 03:50:29PM +0200, Tollef Fog Heen wrote: > * Andreas Barth > > | Agreed. We should IMHO make such a requirement to be part of etchs > | release policy. > > How are you going to solve the problem ia32-libs solves if not in this > way? > > (Unless we want to make etch fully multiarchified, which I don't think > we will.) I didn't see the previous message, so I'm not sure exactly what problem you're referring to - but regardless of multiarch, I want the -libs packages to die in etch. They should be built from biarch source packages instead. I just didn't have time to work on that before sarge. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
* Andreas Barth | Agreed. We should IMHO make such a requirement to be part of etchs | release policy. How are you going to solve the problem ia32-libs solves if not in this way? (Unless we want to make etch fully multiarchified, which I don't think we will.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
* Stephen Quinney ([EMAIL PROTECTED]) [050509 17:20]: > On Mon, May 09, 2005 at 04:45:44PM +0200, Martin Schulze wrote: > > Christian Hammers wrote: > > > I could package the whole libsnmp source code into the Quagga file, and > > > simply compile it with --without-openssl and then link it statically > > > or something similar brute force and ugly. > > > > FWIW: Please don't. This would mean creating a security-support nightmare. > I know of at least one package that already does this. The > gibraltar-bootsupport package includes the source for coreutils, curl, > discover and expat. I have no idea how the security team are meant to > be aware of this if/when a security hole is discovered in any of those > 4 packages. IMO this sort of packaging should not be allowed in stable > releases. Agreed. We should IMHO make such a requirement to be part of etchs release policy. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Mon, May 09, 2005 at 04:45:44PM +0200, Martin Schulze wrote: > Christian Hammers wrote: > > I could package the whole libsnmp source code into the Quagga file, and > > simply compile it with --without-openssl and then link it statically > > or something similar brute force and ugly. > > FWIW: Please don't. This would mean creating a security-support nightmare. I know of at least one package that already does this. The gibraltar-bootsupport package includes the source for coreutils, curl, discover and expat. I have no idea how the security team are meant to be aware of this if/when a security hole is discovered in any of those 4 packages. IMO this sort of packaging should not be allowed in stable releases. Supposedly this is an improvement on the previous approach it used of downloading all the source files using apt-get as part of the build process... Stephen Quinney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Christian Hammers wrote: > I could package the whole libsnmp source code into the Quagga file, and > simply compile it with --without-openssl and then link it statically > or something similar brute force and ugly. FWIW: Please don't. This would mean creating a security-support nightmare. Regards, Joey -- MIME - broken solution for a broken design. -- Ralf Baechle Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
> I don't, except insofar as C - "the Program" attempts to paraphrase E > - "the Program" (= D). Oh for Pete's sake, (E - "the Program") (= D). What a great place for a word wrap. - Michael
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote: > On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote: > > > I believe you're objecting to the "that is to say" phrase, which restates > > > what > > > "work based on the Program": means. > > > > Attempts to, anyway. > > I think this "attempts to" quip is meaningless. How would you like me to say it? "Purports to"? "Professes to"? "Makes an honest but flawed effort to"? Do you not understand my interpretation that the use of quotes around "work based on the Program" means that the writer is defining it as shorthand for "either the Program or any derivative work under copyright law"? And that an attempt is then made to paraphrase (restate, whatever) the latter phrase, and that restatement is just plain wrong? You don't have to agree with it, of course, but surely you get it now. > > > Yes. And that "either/or" clause says what "work based on the Program" > > > means. > > > > Yep. That phrase is, in its entirety: "either the Program or any > > derivative work under copyright law". And that's the definition of > > "work based on the Program" for the duration of the GPL, as far as I'm > > concerned. > > To recap: > > W: "work based on the program" > D: "derivative work" > E: either/or phrase > C: phrase after the colon. > > W means E > C paraphrases E > > Thus, you have concluded, C attempts to paraphrase D No. E defines W, which appears in quotes in the original to indicate that it is being given a formal meaning. C is grammatically a paraphrase of E. However, C and E are not the same thing according to law; and grammatically and legally, E is the definition of W, and C is not. Neither is C \union E, C - D, or some other way to assign W a meaning based on the wording of W, the content of an unrelated document, or the distance to the moon. > Should we keep going back and forth on this, trying to show why > you believe C attempts to paraphrase D? I don't, except insofar as C - "the Program" attempts to paraphrase E - "the Program" (= D). Are we done? And if you're going to move it to private e-mail, do it, don't grandstand about it. That is also more characteristic of others around here than it previously has been of you. Cheers, - Michael
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote:
> > On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> [snip]
> > > Second sentence in Section 0: The "Program", below, refers to any
> > > such program or work, and a "work based on the Program" means either
> > > the Program or any derivative work under copyright law: that is to
> > > say, a work containing the Program or a portion of it, either verbatim
> > > or with modifications and/or translated into another language.
> >
> > I believe you're objecting to the "that is to say" phrase, which restates
> > what
> > "work based on the Program": means.
>
> Attempts to, anyway.
I think this "attempts to" quip is meaningless.
> > > As I read it, the phrase after the colon is a paraphrase of the
> > > "ether/or" clause it follows, i. e., an attempt to restate it in
> > > layman's terms.
> >
> > Yes. And that "either/or" clause says what "work based on the Program"
> > means.
>
> Yep. That phrase is, in its entirety: "either the Program or any
> derivative work under copyright law". And that's the definition of
> "work based on the Program" for the duration of the GPL, as far as I'm
> concerned.
To recap:
W: "work based on the program"
D: "derivative work"
E: either/or phrase
C: phrase after the colon.
W means E
C paraphrases E
Thus, you have concluded, C attempts to paraphrase D
Should we keep going back and forth on this, trying to show why
you believe C attempts to paraphrase D?
Also, either:
(1) Your other paragraphs are logically based on this concept
("C attempts to paraphrase D"), and therefore are based on
a false premise, or
(2) Your other paragraphs are not related to this paragraph by
theme or logic, and thus there's little point in continuing unless
they contain some worthwhile independent theme (personally,
I've not spotted one -- they just seem like a bunch of statements
with little cohesive logic).]
Or something else?
I don't know why it's important that all this be sent to debian-devel. After
this post, I'm probably going to delete debian-devel from my followups
(and a great sigh of relief is heard throughout the land).
--
Raul
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote: > On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: [snip] > > Second sentence in Section 0: The "Program", below, refers to any > > such program or work, and a "work based on the Program" means either > > the Program or any derivative work under copyright law: that is to > > say, a work containing the Program or a portion of it, either verbatim > > or with modifications and/or translated into another language. > > I believe you're objecting to the "that is to say" phrase, which restates what > "work based on the Program": means. Attempts to, anyway. > > As I read it, the phrase after the colon is a paraphrase of the > > "ether/or" clause it follows, i. e., an attempt to restate it in > > layman's terms. > > Yes. And that "either/or" clause says what "work based on the Program" > means. Yep. That phrase is, in its entirety: "either the Program or any derivative work under copyright law". And that's the definition of "work based on the Program" for the duration of the GPL, as far as I'm concerned. > > And it's incorrect, as I explained, and for which I > > have previously given references to treaty, several countries' > > statutes, and lots of case law, in messages on -legal to which you > > responded (generally constructively and courteously, I might add). > > I disagree: > > "work based on the Program" is not the same thing as "derivative work". > > The definition of "work based on the Program" uses the "derivative > work" concept, but builds on that concept. > > I think claiming they're equivalent is silly. Right. "either the Program or any derivative work under copyright law" \superset "derivative work". But collections containing the Program don't fit. "That is to say" introduces an (incorrect) paraphrase -- not a further expansion of the category. To read otherwise is to do violence to both the grammar and the legal sense of the definition; and as I wrote, would result in an unacceptable scope for the license (any "work" containing GPL material, up to and including an entire CD set and the shelf of books bundled with it). People who say publicly and often enough that they accept the FSF FAQ's statement that programs using GPL libraries must be released under the GPL ( http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL ) may well be estopped from arguing otherwise in court. I prefer not to be numbered among them. (And no, before you say it, I'm not trolling to build a defense for some court case.) But that's completely different from affecting the legal meaning of the license (see Linus's LKML post again). I'd be sorry to see, say, a GR swearing allegiance to the FSF FAQ; that would probably estop Debian in perpetuity from linking GPL against non-GPL, trigger the "automatic termation" provision immediately and retrospectively due to any of a zillion inadvertent build bugs in the past decade, and lead to the Death Of Debian (TM). But it wouldn't have any effect on what license terms I or any Debian user or derivative would be obligated to accept. Cheers, - Michael
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote: > > On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > > > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > > > The GPL simply defers to copyright law to define "derivative work". > > > > > Actually, it tries to define "work based on the Program" in terms of > > > "derivative work under copyright law", and then incorrectly > > > paraphrases that definition. > > > > It's probably worth noting that "derivative work" and "work based on the > > Program" are spelled differently. What's not clear, to me, is whether the > > word "that" refers to the "d" phrase or the "w" phrase. Careful study sheds > > no insight into this burning issue. > > > > [If I read the GPL, I can't find where it paraphrases the "d" phrase. On > > the > > other hand I can't figure out how someone could claim that the GPL > > incorrectly paraphrases the "w" phrase.] > > Second sentence in Section 0: The "Program", below, refers to any > such program or work, and a "work based on the Program" means either > the Program or any derivative work under copyright law: that is to > say, a work containing the Program or a portion of it, either verbatim > or with modifications and/or translated into another language. I believe you're objecting to the "that is to say" phrase, which restates what "work based on the Program": means. > As I read it, the phrase after the colon is a paraphrase of the > "ether/or" clause it follows, i. e., an attempt to restate it in > layman's terms. Yes. And that "either/or" clause says what "work based on the Program" means. > And it's incorrect, as I explained, and for which I > have previously given references to treaty, several countries' > statutes, and lots of case law, in messages on -legal to which you > responded (generally constructively and courteously, I might add). I disagree: "work based on the Program" is not the same thing as "derivative work". The definition of "work based on the Program" uses the "derivative work" concept, but builds on that concept. I think claiming they're equivalent is silly. -- Raul
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/6/05, Raul Miller <[EMAIL PROTECTED]> wrote: > On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > > Sorry to spam debian-devel -- and with a long message containing long > > paragraphs too, horrors! -- in replying to this. > > Who is sorry? How sorry? > > Let's assume, for the sake of argument, that this sorry-ness is not > something that matters enough to you to avoid posting long and > elliptical messages to debian-devel. As I wrote, debian-devel is where the "Urgently need GPL compatible libsnmp5-dev replacement" discussion is happening. Andrew's somewhat disingenuous "This part of the thread belongs on -legal" notwithstanding, it had not previously been moved to -legal, just copied there. I was uncertain whether to remove -devel from my reply, but eventually decided to leave it as it was; was there some onus on me to remove -devel? I am hardly a major source of -devel noise, by message count or by bandwidth. But perhaps -devel is reserved for short, erroneous, discourteous messages? (That's not really aimed at Raul, actually.) > > > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > > The GPL simply defers to copyright law to define "derivative work". > > > Actually, it tries to define "work based on the Program" in terms of > > "derivative work under copyright law", and then incorrectly > > paraphrases that definition. > > It's probably worth noting that "derivative work" and "work based on the > Program" are spelled differently. What's not clear, to me, is whether the > word "that" refers to the "d" phrase or the "w" phrase. Careful study sheds > no insight into this burning issue. > > [If I read the GPL, I can't find where it paraphrases the "d" phrase. On the > other hand I can't figure out how someone could claim that the GPL > incorrectly paraphrases the "w" phrase.] Second sentence in Section 0: The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. As I read it, the phrase after the colon is a paraphrase of the "ether/or" clause it follows, i. e., an attempt to restate it in layman's terms. And it's incorrect, as I explained, and for which I have previously given references to treaty, several countries' statutes, and lots of case law, in messages on -legal to which you responded (generally constructively and courteously, I might add). Ignoring the actual definintion and taking the paraphrase would mean that the largest possible "work" containing GPL licensed material would still be subject to GPL constraints (modulo the "mere aggregation" clause, which, if it has legal meaning, applies only to Section 2). And yes, anything copyrightable under the Berne Convention is a "work", including (for instance) a Debian CD set. That's obviously problematic, it's obviously not what any GPL licensee believes (GPL section 3 0wns my distro? yeah, right), and it's obviously not a reading any court would accept, even absent the rule of construction against the offeror. > > There has been so much silliness written about this topic ... > > Agreed. Lots of sarcasm and cheap shots, too; of which I have sometomes been guilty as well. But they do not constitute negative silliness, and are not something I have associated with your by-line in the past. Cheers, - Michael
Re: GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/5/05, Michael K. Edwards <[EMAIL PROTECTED]> wrote: > Sorry to spam debian-devel -- and with a long message containing long > paragraphs too, horrors! -- in replying to this. Who is sorry? How sorry? Let's assume, for the sake of argument, that this sorry-ness is not something that matters enough to you to avoid posting long and elliptical messages to debian-devel. > > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > The GPL simply defers to copyright law to define "derivative work". > Actually, it tries to define "work based on the Program" in terms of > "derivative work under copyright law", and then incorrectly > paraphrases that definition. It's probably worth noting that "derivative work" and "work based on the Program" are spelled differently. What's not clear, to me, is whether the word "that" refers to the "d" phrase or the "w" phrase. Careful study sheds no insight into this burning issue. [If I read the GPL, I can't find where it paraphrases the "d" phrase. On the other hand I can't figure out how someone could claim that the GPL incorrectly paraphrases the "w" phrase.] > There has been so much silliness written about this topic ... Agreed. -- Raul
GPL and linking (was: Urgently need GPL compatible libsnmp5-dev replacement :-()
On 5/4/05, Andrew Suffield <[EMAIL PROTECTED]> wrote: > [This part of the thread belongs on -legal] Sorry to spam debian-devel -- and with a long message containing long paragraphs too, horrors! -- in replying to this. But that's where this discussion is actually happening now, and I'm afraid I can't agree with Andrew's implication that this issue is settled on debian-legal in favor of the FSF FAQ's interpretation. This isn't about license text, this is about GPL FUD and Debian's maintainers and other contributors, and debian-devel as a whole needs to hear it once in a while. I argue largely in the context of US law because it's been convenient for me to research, but I welcome counter-arguments from other legal systems -- with concrete references. > On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > [Paul TBBle Hampson] > > > This of course assumes the phrase "derived work" is legalese for > > > "code dependancy" or something. I'm sure the GPL actually defines > > > what _they_ mean by it... > The GPL simply defers to copyright law to define "derivative work". Actually, it tries to define "work based on the Program" in terms of "derivative work under copyright law", and then incorrectly paraphrases that definition. Under contract law (in most US jurisdictions at least, IANAL, etc.) the recipient is entitled to have this ambiguity construed against the drafter. More below. > > I might add that > > claiming a program that uses a library's published API is a "derived > > work" is a bit shaky from the get-go. If you actually cut and paste > > code from the library into your program, it's a lot more clear-cut. > > We talk about APIs on forums like -legal to save time, because > everybody (supposedly) knows what we're talking about there. They > aren't directly relevant, it's just that certain aspects of program > design will normally have certain legal implications because that's > how those things are normally implemented. I think Peter has it right, and I'd like to know what grounds there may be to demur. See my recent posts to debian-legal archives for US case law on the matter, which I (IANAL) would summarize as "published APIs are not copyrightable in their role as 'methods of operation' as distinct from their role as creative expression". It's kind of an odd stance for the law to have arrived at -- a difference of usage changes not just whether an act of copying is an infringement but whether the copied material is copyrightable at all. But it makes sense in the context of the prescribed sequence of legal analysis, in which recognizing a protected use "too late" in the sequence leaves the copier open to lawsuits de novo for subsequent acts of copying the same material. The last time I know of that the US Supreme Court looked at the issue -- an appeal from Lotus Development Corporation v. Borland International, Inc.,49 F.3d 807 (1995) -- they deadlocked 4-4 in one justice's absence. The court transcript is fascinating. The latest and greatest analysis at circuit court level appears to be Lexmark v. Static Control (2004). Yes, the US is not the world. Other legal systems are perfectly within their rights to arrive at different conclusions, and the Berne Convention is far from explicit on the matter. But what actual grounds are there for a belief that some particular country's legal system would rule that the arm's-length use of a published API creates a derivative work? Chapter and verse, folks; even if precedents are not law in your legal system, they're a lot more reliable than reasoning outside a courtroom with no judge in sight. > Changing static linking to dynamic, or replacing a linker call with a > dlopen() call, *always* has precisely *zero* effect on whether > something is a derivative work or not. A work is created derivative, > or not, at the time of inception. For source code, this is the time > when the code is written. The way in which it is compiled is > irrelevant. For a binary, this is the time when the binary is built > and linked. A statically linked binary is a derivative work of > everything it links because it contains verbatim copies of those > things. Every binary, static, dynamic, or other, is a derivative of > everything that any part of its source was derived from. I do not think that the binary part of this analysis is correct in any country that implements the Berne Convention. My rebuttal is long enough without the case law references, but you can find them all in the debian-legal archives. Whether statically linked or provided as multiple dynamically linked files, a program composed of separately identifiable independent works of authorship is a "collection" (in some countries' implementation, "compilation") as defined in Article 2 Section 5. Derivative works are defined in Article 2 Section 3 to be "[t]ranslations, adaptations, arrangements of music and other alterations of a literary or artistic work". These exist as categories
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Andrew Suffield wrote: [This part of the thread belongs on -legal] So, there it goes. On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: [Paul TBBle Hampson] This of course assumes the phrase "derived work" is legalese for "code dependancy" or something. I'm sure the GPL actually defines what _they_ mean by it... The GPL simply defers to copyright law to define "derivative work". (most jurisdictions') copyright law defines "derivative work" as "a work that, being a novel intellectual creation by itself, results in a transformation of another (original) work", the key word being "transformation". This is a part of copyright law originally thought for controlling instrument re-arranging of musical works, translations of a work from a language to another, and sequels and prequels re-using characters from a literary/theatrical work. Anyway, this is a very foggy issue, because the GPL uses thoughout the license text the expression "work based on the Program" (as opposed to the [legally-defined] expression "derivative work"), which it defines in the following (contradictory) phrase of section 0, caput: ''a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.'' Notice that before the colon, it gives one definition; after the colon, it gives another definition (a wrong one, considering that the "that is to say" introduces an explanatory part of the phrase, and that the explanation differs from the copyright law definition, and that copyright laws vary with jurisdictions, etc). This can be contrasted with the infamous "mere aggregation" clause, section 2, paragraph 3: ''In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.'', and with the other occurences of the (legally-defined) expression "derivative work" in the GPL, after section 0: The first one in section 2, paragraph 2: ''the intent [of this section of the GPL, section 2] is to exercise the right to control the distribution of derivative or collective works based on the Program'' [braces mine]; The second one in section 5: ''You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works.''; this one, combined with the "mere aggregation" clause, can be construed as an authorization to distribute collective works containing the GPL'd work; And the last one in section 10: ''Our decision [on licensing any FSF-owned software under different terms] will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally'' [braces mine]; again, without mentioning the collective works, this can be combined with the "mere aggregation" clause as a confirmation of the authorization to distribute collective works containing the GPL'd work. And yes, I noticed that the first one kind of contradicts the other two, too. I might add that claiming a program that uses a library's published API is a "derived work" is a bit shaky from the get-go. If you actually cut and paste code from the library into your program, it's a lot more clear-cut. Yes, in the former case there was no transformation of the library's source code; in the latter, there was. We talk about APIs on forums like -legal to save time, because everybody (supposedly) knows what we're talking about there. They aren't directly relevant, it's just that certain aspects of program design will normally have certain legal implications because that's how those things are normally implemented. Changing static linking to dynamic, or replacing a linker call with a dlopen() call, *always* has precisely *zero* effect on whether something is a derivative work or not. A work is created derivative, or not, at the time of inception. For source code, this is the time Yes! I could not agree more. when the code is written. The way in which it is compiled is irrelevant. For a binary, this is the time when the binary is built and linked. A statically linked binary is a derivative work of I disagree here: there is no novel intellectual work involved in building/linking a binary. A binary can be, at most, a collective (anthology) work, and this makes a difference in some point in time. Especially if the GPL is involved. everything it links because it contains verbatim copies of those things. Every binary, static, dynamic, or other, is a derivative of everything that any part of its source was derived from. Nope. Collective. No intellectually-novel transformation was a
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
[This part of the thread belongs on -legal] On Wed, May 04, 2005 at 11:51:51PM -0500, Peter Samuelson wrote: > > [Paul TBBle Hampson] > > This of course assumes the phrase "derived work" is legalese for > > "code dependancy" or something. I'm sure the GPL actually defines > > what _they_ mean by it... The GPL simply defers to copyright law to define "derivative work". > I might add that > claiming a program that uses a library's published API is a "derived > work" is a bit shaky from the get-go. If you actually cut and paste > code from the library into your program, it's a lot more clear-cut. We talk about APIs on forums like -legal to save time, because everybody (supposedly) knows what we're talking about there. They aren't directly relevant, it's just that certain aspects of program design will normally have certain legal implications because that's how those things are normally implemented. Changing static linking to dynamic, or replacing a linker call with a dlopen() call, *always* has precisely *zero* effect on whether something is a derivative work or not. A work is created derivative, or not, at the time of inception. For source code, this is the time when the code is written. The way in which it is compiled is irrelevant. For a binary, this is the time when the binary is built and linked. A statically linked binary is a derivative work of everything it links because it contains verbatim copies of those things. Every binary, static, dynamic, or other, is a derivative of everything that any part of its source was derived from. A good rule of thumb for whether one piece of source code is a derivative of another is "Will it function in a reasonable manner without this other piece?". Thusly a telnet client is not a derivative of the socksified tcp library you stuff in with LD_PRELOAD, but the part which sets up ssl connections is a derivative of the ssl library you use. This is a rule of thumb because it fails in pathological cases; don't abuse it. [There are many other, more complicated cases. Consult -legal for consideration of specific examples.] -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
[Paul TBBle Hampson] > This of course assumes the phrase "derived work" is legalese for > "code dependancy" or something. I'm sure the GPL actually defines > what _they_ mean by it... One false assumption and one false premise. "Derived work" is legalese for "this work is based, at least in part, on this other work". Roughly, "if it were not credited, this would be considered plagiarism." Nothing to do with "code dependencies" in particular. Now, the false premise is that it *matters* what the GPL means by "derived work". The GPL is a copyright license, so what actually matters is what copyright law defines as a derived work. For works that are (legally speaking) not derived from a GPL-licensed original, the GPL has no jurisdiction, no matter what it, or the author of your program, or the Free Software Foundation might say. I might add that claiming a program that uses a library's published API is a "derived work" is a bit shaky from the get-go. If you actually cut and paste code from the library into your program, it's a lot more clear-cut. signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
hi I happen to mantain 'snmpkit' ; you may give it a look a. Christian Hammers wrote: > Hello > > [regarding #306840 and with more info in #243870] > > One of my packages, Quagga, is licenced under the GPL but is supposed to > get linked against NetSNMP. That now is problematic, as NetSNMP depends > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. > > Does anybody know a good and easy to replace GPL-compatible SNMP library > that provides SNMP MUX capatiblities for C applications? > > Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? > > bye, > > -christian- > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, 2005-05-03 at 20:15 -0400, David Mandelberg wrote: > On Tue, 2005-05-03 at 19:40 -0300, Henrique de Moraes Holschuh wrote: > > GNU version of OpenSSL (I don't recall how > > it is called). > > GnuTLS I think. Stupid mail misconfiguration, I sent this before I got Christian Hammer's reply (actually almost immediately after I got Henrique's message). -- The attachment "signature.asc" (if it exists) is a digital signature. Unless you know what that is, you can completely ignore it. It is mostly harmless and very small. You will be given a post of trust and responsibility. signature.asc Description: This is a digitally signed message part
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, May 04, 2005 at 02:08:01AM -0400, Theodore Ts'o wrote: > On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote: > > > > The license of the GNUTLS OpenSSL shim is GPL, causing possible license > > problems in the other direction with GPL-incompatible apps. It's also not a > > very complete compatibility layer. > Could the kadmin program be considered a derived work of the readline > library? No, because it was written to call libss *years* ago, long > before libss was modified to potentially call the readline library. I'm not sure this is the right list for this, but... (If you decide that I need learnin', and take this to another list, please CC me. ^_^) Surely the above statement (out of context) is actually an expected side-effect of Copyleft? Specifically, if you drag something GPL into your library, you _are_ requiring that all users (even the historical ones) be GPL-compatible, or not use that version of the library. Obviously kadmin is not a directly derived work of readline, but it is a derived work of libss, which is _now_ a derived work of readline. (Or would be, barring the dlopen solution. ^_^) This of course assumes the phrase "derived work" is legalese for "code dependancy" or something. I'm sure the GPL actually defines what _they_ mean by it... On the other hand, I agree the dlopen-interface argument below trumps this, but I would have to go re-read the GPL before I relied upon that myself. > The kadmin program called the libss *interface*, and at the time the > author of the kadmin program had no idea that it might subsequently > end up calling a GPL'ed library indirectly via libss. And > furthermore, the BSD-licensed libss program does not even directly > link against the readline library, but rather uses dlopen() and > dlsym() to call a particular *interface* which could be satisified > either by a GPL or BSD licensed library. So how can you say that the > libss program is a derivitive work of either library? -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgp28XPT7aKgz.pgp Description: PGP signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, May 03, 2005 at 07:06:36PM -0700, Steve Langasek wrote: > > The license of the GNUTLS OpenSSL shim is GPL, causing possible license > problems in the other direction with GPL-incompatible apps. It's also not a > very complete compatibility layer. > So dynamically link against _an_ SSL library, using dlopen(), and this completely trumps the issue. The fact that there are multiple libraries, implementing the OpenSSL interface, means that as long as the application calls the *interface* it can't be derived from *either* library, and it escapes the license incompatibility issues. (Remember, license compatibility can only be an issue if the program can be shown to be a derived work of a particular library. If it is calling an interface which is implemented by more than one library, then clearly it can't be a derived work, and once it is not a derived work, copyright law by definition can't apply.) Example: The libss library searches for the readline, editline, and libedit libraries via a search path, and dlopen()'s the first one it can find. It the calls those interfaces to get readline functionality. The Solaris SEAM (Solaris Enterprise Authentication Mechanism), which is a propietary program which is derived from the MIT Kerberos V5 sources, also happens to call the libss library, with which it is dynamically linked. Yet now when you run the Kerberos administration CLI program from SEAM, and install the newer version of libss library so that it dynamically links with it, and then the libss library could possibly dlopen the GNU readline library you can a process containing propietary Solaris code, BSD licensed libss code, and GPL'ed readline library, all in the same address space. But has there been a GPL violation? No, since, the only time a derivitive work can conclusively shown to be created is when the user ran the kadmin program, and the GPL does not restrict use, only distribution. Could the kadmin program be considered a derived work of the readline library? No, because it was written to call libss *years* ago, long before libss was modified to potentially call the readline library. The kadmin program called the libss *interface*, and at the time the author of the kadmin program had no idea that it might subsequently end up calling a GPL'ed library indirectly via libss. And furthermore, the BSD-licensed libss program does not even directly link against the readline library, but rather uses dlopen() and dlsym() to call a particular *interface* which could be satisified either by a GPL or BSD licensed library. So how can you say that the libss program is a derivitive work of either library? I believe you can use a similar solution to solve the openssl library problem. If there is a shim layer, and the application uses a search path to find a library which it then dlopen()'s, this should completely trump the license compatibility issue, since in this case it is clear that it is not a derived work of any one particular library, but rather it is calling an interface which can be satisified by multiple libraries, and which library will get used can only be determined at run-time. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, May 03, 2005 at 07:40:24PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 04 May 2005, Christian Hammers wrote: > > One of my packages, Quagga, is licenced under the GPL but is supposed to > > get linked against NetSNMP. That now is problematic, as NetSNMP depends > > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. > A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license > allowing for linking to OpenSSL is probably the easiest way to fix this (and > since that is a documentation change, it would get into sarge). The license of the GNUTLS OpenSSL shim is GPL, causing possible license problems in the other direction with GPL-incompatible apps. It's also not a very complete compatibility layer. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Tue, 2005-05-03 at 19:40 -0300, Henrique de Moraes Holschuh wrote: > GNU version of OpenSSL (I don't recall how > it is called). GnuTLS I think. -- The attachment "signature.asc" (if it exists) is a digital signature. Unless you know what that is, you can completely ignore it. It is mostly harmless and very small. Tempt not a desperate man. -- William Shakespeare, "Romeo and Juliet" signature.asc Description: This is a digitally signed message part
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On May 04, Christian Hammers <[EMAIL PROTECTED]> wrote: > I could package the whole libsnmp source code into the Quagga file, and > simply compile it with --without-openssl and then link it statically > or something similar brute force and ugly. Or even better just disable SNMP support, which is not terribly useful anyway. -- ciao, Marco signature.asc Description: Digital signature
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
Hello On 2005-05-03 Henrique de Moraes Holschuh wrote: > On Wed, 04 May 2005, Christian Hammers wrote: > > One of my packages, Quagga, is licenced under the GPL but is supposed to > > get linked against NetSNMP. That now is problematic, as NetSNMP depends > > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. > > A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license > allowing for linking to OpenSSL is probably the easiest way to fix this (and > since that is a documentation change, it would get into sarge). The extension itself would be easy, more problematic is that it would have to be signed by all significant contributers to the Quagga source code and those are many. Not to mention that Quagga was a "frustrated" fork from Zebra which is no longer part of Debian so there may be problems when begging for a licence change... > > Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? > > That would be etch-land. The most sane way to fix this would be to get > NetSNMP to be able to link to the GNU version of OpenSSL (I don't recall how > it is called). I could package the whole libsnmp source code into the Quagga file, and simply compile it with --without-openssl and then link it statically or something similar brute force and ugly. Replacing OpenSSL by GnuTLS is indeed something for etch if the upstream maintainer from NetSNMP does have ambitions doing this at all as NetSNMP is BSD licenced and has no need to do so. bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Urgently need GPL compatible libsnmp5-dev replacement :-(
On Wed, 04 May 2005, Christian Hammers wrote: > One of my packages, Quagga, is licenced under the GPL but is supposed to > get linked against NetSNMP. That now is problematic, as NetSNMP depends > on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. A simple extension to Quagga's (*and* NetSNMP if it is GPLed) license allowing for linking to OpenSSL is probably the easiest way to fix this (and since that is a documentation change, it would get into sarge). > Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? That would be etch-land. The most sane way to fix this would be to get NetSNMP to be able to link to the GNU version of OpenSSL (I don't recall how it is called). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Urgently need GPL compatible libsnmp5-dev replacement :-(
Hello [regarding #306840 and with more info in #243870] One of my packages, Quagga, is licenced under the GPL but is supposed to get linked against NetSNMP. That now is problematic, as NetSNMP depends on OpenSSL (for SNMPv3 crypto support?) which is not GPL compatible. Does anybody know a good and easy to replace GPL-compatible SNMP library that provides SNMP MUX capatiblities for C applications? Or would it be possible to fork NetSNMP into a libsnmp5-gpl-dev package? bye, -christian- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
