Re: Bug: 111609 RFP for cathedral-book; license question
On Mon, Apr 07, 2003 at 09:26:52PM -0400, Jay Bonci wrote: > When looking at the RFP for cathedral-book at #111609, the license is > mentioned as the Open Publication License 2.0. The only specific > mention I see of that is at: > > http://opencontent.org/opl.shtml > and > http://opencontent.org/openpub > > http://opensource.org/licenses/ doesn't mention anything about this > either > > These are listed as 1.0 versions. Is there a version 2 that I am not > aware of, or are these (somewhat old) DRAFTs considered to be a version > two of that license? Or is this just something that I'd have to break > down and ask ESR for a copy of. > > Please reply-to-all, as I am not on the debian-legal list. > > Thank you, Heh, I just contacted the original ITP'er (Stephen Stafford) last week about taking over the ITP, and he said he'd never been able to clarify the license either. I emailed Eric Raymond about this directly, but I'm yet to receive a response. Sorry for not keeping the BTS informed, I'll forward Eric's reponse if/when I get one. -- Rob Weir <[EMAIL PROTECTED]> http://www.ertius.org/ GPG keys: 1024D/1E73B7CD, 4096R/3ABDE5EC | Do I look like I want a CC? Words of the day: AUTODIN sniper attack clones BLU-97 A/B analyzer CIDA spies pgptYh2xfoSUs.pgp Description: PGP signature
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> wrote: > Walter Landry writes: > > So if the LaTeX > > people become evil and later decide to change the format so that you > > get different behavior with non-validating files, then there has been > > a retroactive change in the licensing terms. What exactly the format > > is needs to be nailed down. > > good point. not in the license terms but in the result -- bad > > but again something along the lines of > > 1. You must make your modified package output to the screen a message > that it isn't the original package > > 2. If the environment where your modified package is intended to be > used provides a documented standard way of emitting such messages > without making any other processing changes, you must use that. > > would take care of that, or not? (2) would apply only if not evil and if we > turn evil you only have to do (1) I think I understand what you're trying to say, but I'm not sure. You're saying you must either 1) notify the user or 2) use the standard method if it doesn't change anything That would mostly cover it, but I don't think that you're actually happy with it. Consider this: I make a fork of LaTeX called FubarTeX. The main feature of this reimplentation is that it aborts if it sees any attempts to notify by individual files. Now I can (indeed must) modify all of my LaTeX files to not do any notification. Since they're all "intended" to be run with FubarTeX, I'm free to distribute these modified LaTeX files. Actually, since LaTeX can be manipulated from the inside, it seems like it wouldn't even be hard to modify standard LaTeX to do this. All that you really need to do is redefine the notification macros to abort or do nothing. I could then distribute this redefinition along with my modifications, with the note that they should be used together. The basic problem is that the individual files are not the whole program. Trying to specify what is the "intended" interpreter leads to non-free conditions. Regards, Walter Landry [EMAIL PROTECTED]
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> wrote: > Brian T. Sniffen writes: > > > > Would it be possible to use GPL wording for this? The ability NOT to do > > > this when written for non-interactive use is important. > > > > I seem to recall a line of argument that this is OK when only a small > > number of things do it, but non-free in cases where hundreds of > > components must do so (say, system boot time, or LaTeX). Thousands of > > lines of "this is non-Standard LateX" flying by would prevent use in > > many circumstances; would a single, collected "This is non-Standard > > Latex; see logfile for which components are non-Standard" meet the > > LaTeX group's requirements? > > this is precisely one of the reasons why we want (2) ie to require that the > standard facility is used. that enables the base format to provide only that > single message and refer to the log for details. Actually, this is a good reason for someone to use the standard facility, not for the license to require the standard facility. All that you really care about is that the information gets to the user, not how it gets to them. Regards, Walter Landry [EMAIL PROTECTED]
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > Jeremy Hankins writes: > > I'm not all that knowledgeable about latex, but I do use it and I have > > read the discussions here. So correct me if I'm wrong, but my > > understanding is that a package file has a very intimate level of > > contact with LaTeX-Format (and, in fact, other package files that are > > currently loaded). It may rewrite other bits of code loaded by the > > TeX binary, and even if that's not happening it has virtually > > (completely?) unrestricted access (i.e., not restricted to an API) to > > the other code. > > all statements correct, it is virtually completely unrestricted access > > > Either of those seems to raise the possibility of creating a derived > > work. Whether anything's compiled and whether anything resembling > > linking is happening isn't really the issue. > > well that i don't believe at least not as long a as such packages are really > separate entities that are only put together for a moment during use. To be honest, I don't really know for sure. But the tricky part is that I don't know that anyone else does either. The fundamental question (which isn't technical at all) is when two works, used in conjunction, become a derived work. I'm sure lots of other folks can give you a more knowledgeable answer, but in the end it boils down to a big question mark with lots of theories. At some point they clearly do (static linking is pretty well accepted as such a point). Other points (dynamic linking, which the FSF supports as creating a derived work) may be less clear, but my impression is that most people, even if they disagree, aren't certain enough to want to argue against it in court. Once they become a derived work the copyright of both works "infects" that of the other -- the GPL didn't invent it, it just uses this fact. But one of the ideas (I think RMS supports this view, but I can't find a reference) is that the degree of conectedness -- i.e., how intimate the connection is, is a good indicator of whether a derived work is created. If that's the case, LaTeX files would clearly create a derived work, since they're if anything more intimately connected than even static linking. Another argument for LaTeX files creating a derived work is the simple fact that, in at least some cases, they literally rewrite some of the code. This is a modification, which seems pretty clearly to make it a derived work. > if that would be legally true then by the same argument then EvilDoer could > dream up EvilLicense put it on on evil.el use it together with emacs and then > claim that EvilLicense has an effect on emacs What would happen in that you wouldn't be able to distribute evil.el. It and emacs (or perhaps not emacs, since it's an interpreter which is a bit of a special case, but some other GPL'd elisp files maybe) together would be a derived work and thus to distribute you'd have to be able to meet the terms of the GPL for evil.el. In the end I (as an ignorant, non-lawyer) suspect that there is no clear answer to this question. But precisely because it's not clear anyone writing GPL'd LaTeX files ought to be aware of the possible consequences. Naturally, this problem would disappear if the LPPL were GPL compatible, which is a reason to shoot for that if possible. But it seems pretty clear that that's not compatible with your goals, so that's not possible. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > Thomas Bushnell, BSG writes: > > Frank Mittelbach <[EMAIL PROTECTED]> writes: > > > > > for the sake of an argument, what about > > > > > > 1. You must make your modified package output to the screen a message > > > that it isn't the original package > > > > > > 2. If the environment where your modified package is intended to be > > > used provides a documented standard way of emitting such messages > > > without making any other processing changes, you must use that. > > > > > > i don't think the wording is good, but that aside, would that lift your > > > concern? > > > > I'd prefer just saying that the documentation must make clear what the > > provenance is. The problem is still one of context. If there is some other program which reads what is "output to the screen" and its behavior changes, then it must be possible and legal to fake that output to the screen to fake out that other program.
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > > I'd prefer just saying that the documentation must make clear what the > > provenance is. > > I take this as a yes, though you do not like it, correct? Neither.
Re: Revised LaTeX Project Public License (LPPL)
Jeremy Hankins writes: > Frank Mittelbach <[EMAIL PROTECTED]> writes: > > Jeremy Hankins writes: > > > > Hrm. So using a package file with LaTeX-Format is not analogous > > > to linking (i.e., doesn't result in a combined, derived work)? > > > > it is not at all like linking in my understanding. I take it that > > you are not familar with the TeX world. The best analogy that i can > > think of right now is this (there might be better ones): > > I'm not all that knowledgeable about latex, but I do use it and I have > read the discussions here. So correct me if I'm wrong, but my > understanding is that a package file has a very intimate level of > contact with LaTeX-Format (and, in fact, other package files that are > currently loaded). It may rewrite other bits of code loaded by the > TeX binary, and even if that's not happening it has virtually > (completely?) unrestricted access (i.e., not restricted to an API) to > the other code. all statements correct, it is virtually completely unrestricted access > Either of those seems to raise the possibility of creating a derived > work. Whether anything's compiled and whether anything resembling > linking is happening isn't really the issue. well that i don't believe at least not as long a as such packages are really separate entities that are only put together for a moment during use. if that would be legally true then by the same argument then EvilDoer could dream up EvilLicense put it on on evil.el use it together with emacs and then claim that EvilLicense has an effect on emacs > > Chances are this wouldn't be all that serious of a problem in any > case, though. As I said, GPL packages would need an exception to be > used with LaTeX-Format, but since they're clearly intended for use > with LaTeX-Format it can probably be assumed implicitly (IANAL, of > course). The only serious problem would be if any of them > incorporated GPL code from some other non-LaTeX project, where the > author of that code didn't clearly expect their code to be used with > LPPL'd code. I have a feeling this isn't terribly likely, but you > know better than I. right now it is not very likely but not impossible, ie all base formats that are sufficient similar to allow full or partial package exchange are either LPPL based or using a similar license (eg ConTeXt, plain TeX by Knuth, etc) however even if not, I can't really believe that a viral effect is possible just by the possibility to use something with something else. if that would be true then why has nobody wrote some MS-Word .dot put in under GPL and forced MS to open their code? :-) or do i miss something? I mean I can understand that there could be a problem if you give me some GPL code and I integrate it into LaTeX-format and distribute the thing as a whole. > In other words, I'm just pointing out an issue to be aware of (or at > least, for GPL-licensed package authors to be aware of), not something > I think is a show-stopper. well, it is an interesting and important point (if there really is an issue), as i said, I can't believe there is, but most of you have more experience with licenses than I do, so further opinions are welcome. perhaps my way of thinking is flaky at some point frank
Re: Revised LaTeX Project Public License (LPPL)
Thomas Bushnell, BSG writes: > Frank Mittelbach <[EMAIL PROTECTED]> writes: > > > for the sake of an argument, what about > > > > 1. You must make your modified package output to the screen a message > > that it isn't the original package > > > > 2. If the environment where your modified package is intended to be > > used provides a documented standard way of emitting such messages > > without making any other processing changes, you must use that. > > > > i don't think the wording is good, but that aside, would that lift your > > concern? > > I'd prefer just saying that the documentation must make clear what the > provenance is. I take this as a yes, though you do not like it, correct?
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > for the sake of an argument, what about > > 1. You must make your modified package output to the screen a message > that it isn't the original package > > 2. If the environment where your modified package is intended to be > used provides a documented standard way of emitting such messages > without making any other processing changes, you must use that. > > i don't think the wording is good, but that aside, would that lift your > concern? I'd prefer just saying that the documentation must make clear what the provenance is.
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > Jeremy Hankins writes: > > Hrm. So using a package file with LaTeX-Format is not analogous > > to linking (i.e., doesn't result in a combined, derived work)? > > it is not at all like linking in my understanding. I take it that > you are not familar with the TeX world. The best analogy that i can > think of right now is this (there might be better ones): I'm not all that knowledgeable about latex, but I do use it and I have read the discussions here. So correct me if I'm wrong, but my understanding is that a package file has a very intimate level of contact with LaTeX-Format (and, in fact, other package files that are currently loaded). It may rewrite other bits of code loaded by the TeX binary, and even if that's not happening it has virtually (completely?) unrestricted access (i.e., not restricted to an API) to the other code. Either of those seems to raise the possibility of creating a derived work. Whether anything's compiled and whether anything resembling linking is happening isn't really the issue. Chances are this wouldn't be all that serious of a problem in any case, though. As I said, GPL packages would need an exception to be used with LaTeX-Format, but since they're clearly intended for use with LaTeX-Format it can probably be assumed implicitly (IANAL, of course). The only serious problem would be if any of them incorporated GPL code from some other non-LaTeX project, where the author of that code didn't clearly expect their code to be used with LPPL'd code. I have a feeling this isn't terribly likely, but you know better than I. In other words, I'm just pointing out an issue to be aware of (or at least, for GPL-licensed package authors to be aware of), not something I think is a show-stopper. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Revised LaTeX Project Public License (LPPL)
Jeremy Hankins writes: > Frank Mittelbach <[EMAIL PROTECTED]> writes: > > > you can, of course, combine/run GPL packages with the base format > > LaTeX-Format, there are a packages of packages licenced in this way > > Hrm. So using a package file with LaTeX-Format is not analogous to > linking (i.e., doesn't result in a combined, derived work)? it is not at all like linking in my understanding. I take it that you are not familar with the TeX world. The best analogy that i can think of right now is this (there might be better ones): emacs binary TeX binary emacs core elc files LaTeX-Format vmsome package now emacs bin, the core elc files, and vm may all be under GPL but even if not would one influence the other? i seriously doubt it even if vm would rewrite several functions of the core elc files. it is using something together, eg my emacs lisp package might as well work with some other lisp if i'm careful or vice versa > Have you > confirmed this in any way, or is this your opinion? Because if there > are GPL'd package files this may be an important issue. Especially if > any of them incorporate GPL code from other sources. i must confess it is only my opinion, but i think it stands to reason. nobody ever suggested otherwise. i guess you would have a certain point on the level of the base format as that could be byte compiled (for speed reasons), ie the files making up the LaTeX format are usually precompiled into a single file but even that is not a requirement, you can load them directly. However, there is no GPL code involved and (will not be ever if that is a danger) > > i don't think it is a problem. you can not relicense an LPPL file simply as > > GPL that is true, but you can relicense it as GPL plus a restriction given > > by > > 7a->5a. > > Ok. As you say, something can still be free and yet not GPL > compatible. The only reason this would be a problem is if the GPL's > "viral" properties come into play when used with LaTeX-Format. To me > (IANAL) this seems likely since a package file is actually rewriting > the base format, as I understand it. If so it's fairly important that > the LPPL be GPL compatible, or that the GPL'd packages include an > exception allowing "linking" with LPPL stuff. i understand about the "viral" properties of GPL but i don't think they would apply to packages which are inidividual things that can be used seperately with several "base formats" are distributed separately etc. please tell us if you think otherwise. frank
Re: Bug#188158: ITP: libjta-java -- JTA is the JavaTM Transaction API from SunTM
On Tue, Apr 08, 2003 at 01:13:58PM -0400, Joe Drew wrote: > Regardless of whether it's necessary, it seems we don't do it. (Linux is > Linus' trademark.) Shouldn't we include a file in our distribution in wich we state that Linux is a trademark of Linus, "this" is a trademark of "that" and so on (or perheps we already do, and i simply do not know). ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language.
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: > you can, of course, combine/run GPL packages with the base format > LaTeX-Format, there are a packages of packages licenced in this way Hrm. So using a package file with LaTeX-Format is not analogous to linking (i.e., doesn't result in a combined, derived work)? Have you confirmed this in any way, or is this your opinion? Because if there are GPL'd package files this may be an important issue. Especially if any of them incorporate GPL code from other sources. > i don't think it is a problem. you can not relicense an LPPL file simply as > GPL that is true, but you can relicense it as GPL plus a restriction given by > 7a->5a. Ok. As you say, something can still be free and yet not GPL compatible. The only reason this would be a problem is if the GPL's "viral" properties come into play when used with LaTeX-Format. To me (IANAL) this seems likely since a package file is actually rewriting the base format, as I understand it. If so it's fairly important that the LPPL be GPL compatible, or that the GPL'd packages include an exception allowing "linking" with LPPL stuff. -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Bug#188158: ITP: libjta-java -- JTA is the JavaTM Transaction API from SunTM
On Tue, 2003-04-08 at 11:57, Luca - De Whiskey's - De Vitis wrote: > On Tue, Apr 08, 2003 at 11:36:30AM +0200, Arnaud Vandyck wrote: > > Description : JTA is the JavaTM Transaction API from SunTM > > I'm not sure you need to place `TM' after Java or Sun, so i'm Cc-ing -legal. pisces:~$ apt-cache search linux | wc -l 1146 pisces:~$ apt-cache search linuxtm | wc -l 0 Regardless of whether it's necessary, it seems we don't do it. (Linux is Linus' trademark.) -- Joe Drew <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> "This particular group of cats is mostly self-herding." -- Bdale Garbee
Re: Bug#188158: ITP: libjta-java -- JTA is the JavaTM Transaction API from SunTM
On Tue, Apr 08, 2003 at 11:36:30AM +0200, Arnaud Vandyck wrote: > Description : JTA is the JavaTM Transaction API from SunTM I think that "Java Transaction API" should be enough for the short description: `from SunTM' will be clear in the copyright file, and JTA is redundant (and not so self explanatory). I'm not sure you need to place `TM' after Java or Sun, so i'm Cc-ing -legal. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][-A-Za-z]*[iy]'?s$ | as fine or rude sentences have Infinite loop: see `Loop, infinite'.| something in common: they Loop, infinite: see `Infinite loop'.| don't depend on the language. pgpEJlG21h2iO.pgp Description: PGP signature
Re: Revised LaTeX Project Public License (LPPL)
Jeremy Hankins writes: > Frank Mittelbach <[EMAIL PROTECTED]> writes: > >> Jeff Licquia <[EMAIL PROTECTED]> writes: > > >>> Except that you can't make GPL code validate with the LPPL > >>> validator, since the GPL and LPPL are not compatible. So, since > >>> there's no danger that the code will be run through the validator > >>> and identify itself as "standard", the GPL satisfies 7a. So the > >>> GPL is a valid license to relicense LPPL code under. > >>> > >>> (At least, that's my understanding.) > > > > I'm not sure that i understand Jeff here. the intention of 7a is > > that if FOO is under LPPL, then a derived work made from FOO honors > > 5a, ie, it does not claim to the user that it is the original FOO > > either via 5a1 or 5a2 (5a3 is irrelevant as this is "a general do > > what you like" for certain files, so for the discussion we can > > assume that FOO is not of this type) > > He's saying (assuming I'm understanding properly) that since you can't > incorporate GPL files into latex (since the LPPL isn't GPL compatible) > making a file GPL is enough to ensure that the file will never > misrepresent itself to latex -- since it can never be used with latex > at all. it is probably pointless to speculate what he meant, the above interpretation is in any case wrong as far as I can tell. not sure what "latex" in your sentence refer to but you can, of course, combine/run GPL packages with the base format LaTeX-Format, there are a packages of packages licenced in this way you can also produce a base format that is licensed under GPL und combine/run packages licensed under LPPL with it. That base format could, for example, omit the "validation" so that the user is not informed if a modified LPPL package is being used. > But I pointed out that one could imagine someone writing a GPL version > of the latex base, in which case files intended to be used with the > gpl latex (which are gpl'd, and perhaps based years ago on an LPPL'd > file) could be put together with the LPPL latex. yes you could write a NonStandard-LaTeX-format (under GPL) which would treat, say, \ProvidesPackage... as an absolute noop. If \ProvidesPackage is the facility from LaTeX-format referred to in the LPPL for the package FOO then a fork of FOO or a relicense under 7a would mean that you would need to say, for example \ProvidesPackage{FOO gpl version} or whatever you like as long as you don't keep \ProvidesPackage{FOO} unchanged. For your GPL base format this would be a comment and disregarded while if this gets used together with the base format LaTeX-format the user would get the proper information. > If that remote possibility is a problem, and from your comment it is, > then there's no way I could relicense an LPPL'd file as GPL, even for > use in my terminal emulation program (for example). i don't think it is a problem. you can not relicense an LPPL file simply as GPL that is true, but you can relicense it as GPL plus a restriction given by 7a->5a. so yes, this cannot be simply GPL without some strings attached, but i don't think you should make that a point against the license; after all 7a is an extra, other licenses often do not allow you to relicense derived works under anything than the exact conditions of the original license, e.g., I can't take your GPL code and use it and distribute the result under LPPL or under some other license, can I (GPL 2b)? frank
Re: Revised LaTeX Project Public License (LPPL)
Frank Mittelbach <[EMAIL PROTECTED]> writes: >> Jeff Licquia <[EMAIL PROTECTED]> writes: >>> Except that you can't make GPL code validate with the LPPL >>> validator, since the GPL and LPPL are not compatible. So, since >>> there's no danger that the code will be run through the validator >>> and identify itself as "standard", the GPL satisfies 7a. So the >>> GPL is a valid license to relicense LPPL code under. >>> >>> (At least, that's my understanding.) > > I'm not sure that i understand Jeff here. the intention of 7a is > that if FOO is under LPPL, then a derived work made from FOO honors > 5a, ie, it does not claim to the user that it is the original FOO > either via 5a1 or 5a2 (5a3 is irrelevant as this is "a general do > what you like" for certain files, so for the discussion we can > assume that FOO is not of this type) He's saying (assuming I'm understanding properly) that since you can't incorporate GPL files into latex (since the LPPL isn't GPL compatible) making a file GPL is enough to ensure that the file will never misrepresent itself to latex -- since it can never be used with latex at all. But I pointed out that one could imagine someone writing a GPL version of the latex base, in which case files intended to be used with the gpl latex (which are gpl'd, and perhaps based years ago on an LPPL'd file) could be put together with the LPPL latex. If that remote possibility is a problem, and from your comment it is, then there's no way I could relicense an LPPL'd file as GPL, even for use in my terminal emulation program (for example). -- Jeremy Hankins <[EMAIL PROTECTED]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Non-free source package with downloadable parts
Hi, > Ouch. Debian can't do this, and your installer doesn't. Hmm, bundled product means binaries, do they? This license definitely sucks. And this is really stupid, as I don't see how sensitive those 2000 lines of code can be ; not to mention that the SDK is supposed to ease the use of the flash format by providing to developpers the necessary tools. Oh, I tried to convince them to change this license, with no luck. No luck either when trying to report bugs in the SDK (crash on many online flash files). I suppose they just don't care. Unfortunately, many sites have embedded flash content, and many users want to grab them :( > BTW: Will libflash0 do the job? No, unfortunetaly (no links extraction or embedded objects parser ; I can only simulate "play", but I won't get all links anyway) :( I will have to find another workaround One positive point: this license is stup^Wrestrictive enough to be eligible as "bad license example" in Debian :) Thanks for the comments. Xavier
Re: Non-free source package with downloadable parts
3(d) Any direct or indirect distribution of any Bundled Products by you shall be under the terms of a license agreement containing terms that: (i) prohibit any modifications to the Derivative Works or any part thereof, Ouch. Depending on what constitutes a derivative work, this wouldn't allow linking to _anything_ in main. (ii) prohibit any reverse engineering, disassembly or recompilation of the Derivative Works or any part thereof, Ouch. Same as above. [...] (v) require the user to comply fully with all relevant export laws and regulations of the United States to assure that the Bundled Products or any part thereof is not exported, directly or indirectly, in violation of United States law, Ouch. Debian can't do this, and your installer doesn't. BTW: Will libflash0 do the job? signature.asc Description: This is a digitally signed message part