Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. On Sat, Oct 30, 1999 at 12:16:40PM -0700, Bruce Perens wrote: Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). Considering the difficulty Bernstein is having -- establishing his first amendment rights in Bernstein v. US Dept. of Justice -- I doubt there's much basis in considering a computer program as a purely static work. -- Raul
jdk1.1 license changes
The attached file will be part of the jdk1.1 upload entering Incoming some time later tonight. I trust it resolves bugs #37599 #40696. -- Stephen So if she weighs the same as a duck, she's made of wood And therefore?... A witch! The GNU/Debian linux distribution of the Java(tm) Development Kit is subject to the following additional terms and conditions: 1. The software is provided to the GNU/Debian linux distribution (Debian) by me, Stephen Zander, in accordance with the terms of the JAVA(TM) DEVELOPMENT KIT VERSION 1.1.x INTERNAL NONCOMMERCIAL USE SOURCE LICENSE (Source License), a copy of which appears below. 2. Persuant to clause 1.2 in the Source License, I hereby give permission for Debian to make unlimited electronic copies of the Java(tm) Devlopment Kit for archival and distribution purposes only. JDK Version 1.1.x Internal Noncommercial Use Source License2 of 4 Nov 10, 1998 Rev. 3.4 JAVA(TM) DEVELOPMENT KIT VERSION 1.1.x INTERNAL NONCOMMERCIAL USE SOURCE LICENSE 1.0 LICENSE GRANT 1.1 Sun grants to you (Licensee) a nontransferable, nonexclusive, royalty-free, limited license to use a copy of the Java Source Code (Licensed Software) in the United States, Canada, Japan, Australia and the European Union (constituted as of the Effective Date), at the location identified below, for internal evaluation, research and educational purposes only, including the right to: (i) modify only the Platform Dependent Portion of the Licensed Software to create ports of the Software not available from Sun; and (ii) compile the Licensed Software. Other than the limited rights granted in this License, Licensee acquires no right, title or interest in or to the Licensed Software, and Licensee shall have no right to distribute the Source Code of the Licensed Software, except that Licensee may post to the internet only those modifications to the Source Code created by Licensee during porting (i.e., diffs). Sun owns all modifications, enhancements and bug fixes made by or for Licensee to the Licensed Software. Licensee shall retain all rights to any software such as applets and applications that are independently developed by Licensee without use of the Licensed Software. In the event that Licensee creates additional classes or otherwise extends the public programming interface to the Licensed Software, Licensee must promptly publish an accurate specification for such extensions for free use by third party developers of Java-based software. If Licensee desires that its use of the Licensed Software be for commercial or productive use such as product development or product or customer support, Licensee must execute a commercial license agreement with Sun. 1.2 Sun grants to Licensee the royalty-free right to distribute binary code developed and compiled from the Licensed Software in accordance with Subsection 1.1 above (Derived Binaries), provided that: (i) Derived Binaries are not integrated, bundled, combined or associated in any way with a product, (ii) there is no charge associated with such distribution, (iii) Derived Binaries are fully compatible with the then-current version of the publicly available test suite supplied by Sun which verifies Java compatibility (JavaTest Suite) and must remain compatible with subsequent versions of the JavaTest Suites and upgraded Licensed Software, and (iv) Derived Binaries are distributed subject to a license agreement containing terms and conditions at least as protective of Sun as those included in the binary code license used by Sun for internet distribution of the Java binaries. In the event that Licensee desires that such distribution be fee-based, or be associated with a product, Licensee must execute a commercial license agreement with Sun. 1.3 This License, including any licenses and rights granted hereunder, the Licensed Software and Derived Binaries may not be sold, leased, assigned, sublicensed or otherwise transferred, in whole or in part, by Licensee. Sun is under no obligation to provide maintenance or support for the Licensed Software, or to notify Licensee of upgrades to the Test Suites or Licensed Software. If Sun, in its sole discretion, makes upgrades generally available, use of such upgrades by Licensee will be subject to the terms of this License. 2.0 COPYRIGHTS AND TRADEMARKS 2.1 Licensee shall reproduce and apply any copyright or other proprietary rights notices included on or embedded in Licensed Software to any copies of Licensed Software or Derived Binaries, in whole or in part, in any form. 2.2 Licensee acknowledges that Sun owns all Java-related trademarks, logos and icons (Java Marks) and agrees to: (i) not use Java Marks in the names of internet domains or businesses, or applets, applications implementations, ports, modifications, classes, extensions, Derived Binaries or other software, developed with or from the Licensed Software (Apps); (ii) not use Java-related logos or icons in Apps, webpages or other marketing materials,
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 10:16:38PM -0400, Raul Miller wrote: On Sat, Oct 30, 1999 at 12:16:40PM -0700, Bruce Perens wrote: Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). This analogy doesn't really hold up, though: I don't know of any scores that as well as requiring royalties for perfomance or duplication forbid you to perform them with other songs. In particular, if you have a script that has some dialogue followed by ``now do the scene from foo, where Bar bazzes'' sure, you have to get permission to perform `foo', but that's it. This is as opposed to if the script writer had merely cut and pasted the words directly from foo, which would be a copyright violation. And we already have permission to use both dpkg and the Corel frontend. Just because you only use dpkg when Corel tells you too, well, so what? (As I understand it, the `you can't dynamic link against GPLed libraries from non-GPL programs' is more a case of `you can't #include GPLed header files in non-GPLed programs', which is a very different scenario (involving copying copyrighted works, rather than merely linking them)) Hmmm. I also suspect that the performance of a play would constitute a derived work, whereas I can't quite imagine how the execution of a program could. Odd. IANAL. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds pgp9BcfS0dCVP.pgp Description: PGP signature
Re: Corel's apt frontend
On Oct 30, Bruce Perens wrote: From: Raul Miller [EMAIL PROTECTED] Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. Well, I'd like the law to agree with you, actually. The problem is that copyright law does not consider _reference_ a form of derivation. This would give us problem with dynamic libraries, too, except that the headers get copied into the application. I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. (In any event, you're talking about double-indirection here; I assume apt's authors don't give a rat's ass who calls their program, and apt is the program that runs dpkg.) Chris -- = |Chris Lawrence |Get Debian GNU/Linux CDROMs| | [EMAIL PROTECTED]| http://www.lordsutch.com/cds/ | | | | | Open Directory Editor |Join the party that opposed the CDA| | http://dmoz.org/| http://www.lp.org/| =
Re: Corel's apt frontend
Hmmm. I also suspect that the performance of a play would constitute a derived work You can also perform a computer program, it's generally called _use_. The program's output may be derivative. Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Copyright law allows you to control public performance of your work, I think this is a separate concept from use. You could use this control, for example, to control use of your program on a web server, where the output of the program is presented to clients. Thanks Bruce
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 10:16:38PM -0400, Raul Miller wrote: The difference between mere reference and derivation, in this case, is the difference between treating the computer program as a static work (like a book) and a dynamic work (like a screen play or music score). On Sun, Oct 31, 1999 at 02:17:04PM +1000, Anthony Towns wrote: This analogy doesn't really hold up, though: I don't know of any scores that as well as requiring royalties for perfomance or duplication forbid you to perform them with other songs. Are you suggesting that what you don't know is legally relevant? And we already have permission to use both dpkg and the Corel frontend. Just because you only use dpkg when Corel tells you too, well, so what? Are you suggesting that that front end merely provides documentation on how to use dpkg? If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. If I don't have that right it doesn't matter whether my cdrom is a regular music cdrom or some computer program that plays back encrypted mp3s. And it most certainly doesn't matter whether that computer program is statically linked or whether it uses a command interface to call the part that plays the hit single (unless the license on the hit single was sensitive to this point). Now, if you can show my anything in copyright law, or in the GPL, which makes any kind of distinction about the mechanics of how control is passed from the part of the work as a whole which is represented in one file to a part of that work which is represented in another file then I'll be happy to talk about that issue. But, last time I read through title 17, the *only* special provisions in copyright law for computer programs had to do with backups. And, the GPL is very careful to define what it means by program -- and that definition most definitely isn't restricted to a single binary object which runs in a single memory space or any other such thing. Anyways, unless you want to provide a reference to back up your point, why are we even discussing this? -- Raul
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 11:40:16PM -0500, Chris Lawrence wrote: I really can't even see the point of forbidding non-free programs from calling dpkg... either (a) they'll reimplement dpkg as non-free software (reimplementing dpkg might be a good idea in and of itself, but a non-free dpkg is pretty worthless to everyone, and probably a source of confusion to boot) or (b) adopt another package manager. Or (c) change the license on that program. And, if someone wants to re-implement dpkg, more power to them. Meanwhile, I think Ian has the right to talk to Corel about this issue. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:28:39AM -0500, Raul Miller wrote: If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. A better analogy might be if that cdrom automatically went over to the next CD and played a track from it mid-song. Could the copyright holders of the next CD have any control over you selling a CD that does that? As someone pointed out, this would prohibit you from running perl from bash, or running bash from a non-GPL x-terminal or any GPL program on a proprietary X server. Those would be the same sort of aggretion as get_it calling dpkg. -- David Starner - [EMAIL PROTECTED]
Re: Corel's apt frontend
Hmmm. I also suspect that the performance of a play would constitute a derived work On Sat, Oct 30, 1999 at 11:27:50PM -0700, Bruce Perens wrote: You can also perform a computer program, it's generally called _use_. The program's output may be derivative. It's not the output that's the issue here, but the interaction between the two pieces of the program. I think the real problem in this discussion is that the word program means different things to different people. But the GPL is very careful about how it defines program. In understanding this distinction, it's probably worth noting that, as linux programmers, we're working in an environment where program has a specific, technical meaning -- at the moment, we tend to think of a program as a specific executable file. However, the GPL was written by (or for) a lisp programmer and from that point of view the mechanical issues of storage and parameter passing were never all that important. In the lisp environment there's all sorts of things which could reasonably be called programs... Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. Copyright law allows you to control public performance of your work, I think this is a separate concept from use. You could use this control, for example, to control use of your program on a web server, where the output of the program is presented to clients. In all the examples I can think up with that's a different issue. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:46:56AM -0500, Raul Miller wrote: Given that the GPL has language that is extremely un-restrictive regarding use, I doubt it could be applied to restricting front-ends that run across the exec() interface. Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. Let's assume for a moment and for the purposes of argument that running get_it does in fact create a single combined work consisting of get_it and dpkg. The user who's lawfully aquired both dpkg and get_it may modify either one by incorporating the other therein as he sees fit without violating copyright law, so long as the result is not distributed. This is the law in both the US and in Europe. Since in a legal context, actions performed by a machine are considered to be performed by the operator of that machine and not the machine itself, it is the operator of the computer running get_it that requests the combination of the two copyrighted works. I see no reason why get_it's use (or incorporation) of dpkg at the operator's request would be in any way affected by copyright law. This has been tested in court by a software package called Game Genie, which patches video game software to enable cheating and then executes the result. Game Genie can also begin execution of a game from a point other than the intended start. A federal judge ruled that the Game Genie software was not a derived work of the copyrighted software that it patched and executed, nor was its publisher responsible for contributory infringement. -- Brian Ristuccia [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] If I sold a cdrom which played music, and the music it played was a few bars of my own and some hit single I picked up from a music store, I'd have to have a legal right to sell that hit single. Well, this is different in that you are copying the hit single. Also, hit singles have different rights from GPL programs. Now, if you can show my anything in copyright law, or in the GPL, which makes any kind of distinction about the mechanics of how control is passed from the part of the work as a whole which is represented in one file to a part of that work which is represented in another file then I'll be happy to talk about that issue. That is just the problem. Copyright law does not say _anything_ about passing of control. It deals with copying. So, if you are not copying a work into another work in order to produce a derivative work, copyright law is silent upon the issue. Thanks Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:59:24AM -0500, Raul Miller wrote: But the xterminal example is a bit more constrained. Here, you could still run into trouble -- but only if you were distributing both the proprietary x software and the GPLed software as composite parts of some larger work. [And, the mere aggregation clause of the GPL restricts the sorts of larger works which can get into trouble this way.] I must say this thread is VERY disturbing. Have you people considered what you're talking about? How is a non-GPL shell or environment spawning a GPL app different than a GPL shell spawning a non-GPL app? Either way it's the same sort of run-time connection, using the same interface. If one is not allowed, the other is not allowed either. If that is the case the GPL contaminates other software (like the Debian distribution as a whole) by requiring that EVERY SINGLE THING we distribute be GPL. A specific example of something that the GPL would be trying to contaminate would be Apache. Fortunately, the GPL does not do this. I think it's approaching dellusional to believe otherwise, nothing in the GPL itself indicates that simply running a program or having another program run it should be considered a combined work. ANd in fact the GPL is careful to say that mere aggregation of GPL packages is perfectly acceptable if we follow the other restrictions in the GPL. The reason Richard has not tried to close this apparently obvious loophole in the GPL is probably quite simply that he couldn't do it--the law just doesn't work that way. A Copyright license should not cover usage because it can't legally enforce usage restrictions. And IM(NS)HO, if he tried Richard would find he'd lost just about all respect anyone has for him. If Richard came up to me and told me that Debian couldn't distribute Apache anymore (advertising clause isn't GPL compatible) because it's init.d script uses /bin/sh--bash on a Debian system and therefore violates the GPL on bash, I'd tell him what he could do with the GPL... I have no choice to believe he's got more sense than that. I think we could do a lot better to focus on educating people as to why free software is important---and not just why it makes for better software either. Sure that's nice and all, but in the end it's that the freedom and openness that make the software as good as it is so quickly. Case in point, Netscape may have released their source but it wasn't until they actually tried to open the development process that things started moving at any measurable progress level. Having published source is nice, but it's not enough on its own. FWIW, I think this is a problem with Qt still today. They pretty much want you to make whatever changes you want, diff them, and submit the patch for their approval and possible future inclusion or not. Not exactly a major encoaragement for people to want to work on it is it? -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- Knghtbrd mariab - don't think Debian hasn't had some very stupid and obvious bugs before Knghtbrd of course, we usually fix ours BEFORE we release =D pgpFF8BZbLclv.pgp Description: PGP signature
Re: Corel's apt frontend
One problem this thread illustrates is that the GPL is too darned easy to circumvent today. When it was written, there was less use of dynamic linking, less client-server computing, and no object brokers. Bruce
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:59:37AM -0500, David Starner wrote: A better analogy might be if that cdrom automatically went over to the next CD and played a track from it mid-song. Could the copyright holders of the next CD have any control over you selling a CD that does that? On Sun, Oct 31, 1999 at 01:59:24AM -0500, Raul Miller wrote: As I understand it, Corel would be distributing their front end with dpkg -- this conflicts with the distinction you're trying to raise. On Sun, Oct 31, 1999 at 01:32:45AM -0600, David Starner wrote: Okay, you sell the other CD with it. Still doesn't matter. Sure, because you're intending that they both be copied onto the same system. That's not the same as independent cds. As someone pointed out, this would prohibit you from running perl from bash, or running bash from a non-GPL x-terminal or any GPL program on a proprietary X server. Those would be the same sort of aggretion as get_it calling dpkg. But the xterminal example is a bit more constrained. Here, you could still run into trouble -- but only if you were distributing both the proprietary x software and the GPLed software as composite parts of some larger work. [And, the mere aggregation clause of the GPL restricts the sorts of larger works which can get into trouble this way.] I don't understand you're emphasize on distributing them together. So far, we don't know that the CD won't contain dpkg and the first step of installation is to download it from the net. Why would that be - why should it be - any different? Distributing them together is just part of the picture. To understand why it's a part of the picture you'd have to have read the GPL. Rather than try to explain the GPL, yet again, I'll just suggest you read it and pay attention what it's allowing you to do. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 01:46:56AM -0500, Raul Miller wrote: Once again, this isn't an issue of use, it's an issue of definition. The combination of dpkg plus the front end is an example of what the GPL defines as a program. On Sun, Oct 31, 1999 at 02:17:01AM -0500, Brian Ristuccia wrote: Let's assume for a moment and for the purposes of argument that running get_it does in fact create a single combined work consisting of get_it and dpkg. Feel free, but that's not what I've claimed. I've claimed that get_it (is that really the name of the front end?) has been designed to enhance dpkg, and that get_it is being distributed to enhance dpkg. Running it just illustrates the intentions of the authors, nothing more. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:58:29AM -0500, Raul Miller wrote: If that is the case the GPL contaminates other software (like the Debian distribution as a whole) by requiring that EVERY SINGLE THING we distribute be GPL. A specific example of something that the GPL would be trying to contaminate would be Apache. If people are distributing derivative works that include GPLed code and apache, sure. But if apache is just calling /bin/sh, there's nothing special about that -- any /bin/sh can be used. And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? Fortunately, the GPL does not do this. I think it's approaching dellusional to believe otherwise, nothing in the GPL itself indicates that simply running a program or having another program run it should be considered a combined work. ANd in fact the GPL is careful to say that mere aggregation of GPL packages is perfectly acceptable if we follow the other restrictions in the GPL. Sure, and that has nothing to do with the Corel front end. The Corel front end for dpkg is obviously intended to enhance dpkg. The line HAS to be drawn somewhere. ANY program can be said to enahnce ANY OTHER program. How clearly a program enhances another is completely an arbitrary opinion. Licenses should not be applied arbitrarily. (FWIW in this case I agree---their front end IS an attempt to enhance apt which is an attempt to enhance dpkg. They're seperate works though..) -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- tigah_- i have 4gb for /tmp Knghtbrd What do you do with 4G /tmp? Compile X? tigah_- yes pgpInu7hulCh3.pgp Description: PGP signature
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 02:41:52AM -0800, Joseph Carter wrote: And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? I'm having trouble imagining a work which involves apache and bash where bash is an inseperable aspect of the whole. Bashisms are so.. trivial.. and so unrelated to web serving. I guess it might be possible for you to create one, though -- and if you did you'd have to address the copyright issues before you could distribute it. [Do you know anyone distributing apache and bash together along with such software? If so, you might want to suggest that they not use bashisms...] -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:44:47AM -0500, Raul Miller wrote: It's true that the GPL was written for programs, not music. However, many countries have a legal concept of a moral right of integrity for a copyrighted work, to prevent its mutilation. The U.S. doesn't recognize this as an automatic right, From looking at http://www.smithlyons.ca/it/laws/copyright_act.htm, Canada does though. I just love the whole `linking with non-free software as vandalism' aspect of this. :) I didn't think this was so much about the right of integrity, so much though as just regular copyright. I'm not entirely sure the GPL's definition of derivative work would matter so much in this case, though. The Canadian law apparently is something like: 28.2 (1) The author's right to the integrity of a work is infringed only if the work is, to the prejudice of the honour or reputation of the author, (a) distorted, mutilated or otherwise modified; or (b) used in association with a product, service, cause or institution. `used in association with' is much broader than `derived from', or `based on'. I'd happily concede that that's the case here, and I wouldn't be entirely surprised if you can make a case of `to the prejudice of the honour or reputation of the author'. I'll reserve the right to find it really funny though :) And it most certainly doesn't matter whether that computer program is statically linked or whether it uses a command interface to call the part that plays the hit single (unless the license on the hit single was sensitive to this point). Please back this up. I'm saying that there's no text in title 17 of the U.S.Code which raises this issue. And, I'm saying that there's no text in the GPL which raises this issue. If I'm wrong, it's trivial to prove me wrong: quote the text which raises this issue. Okay, forget this. I was assuming you were saying that having system(dpkg --help); in your program meant that you had to put that program under the GPL. I think this is wrong, because you're not actually copying any of dpkg, and thus copyright law doesn't come into effect. Whereas what you're really saying, is that when you create a CD, or ftp site, or distribution, or whatever, containing both dpkg and your dpkg_help program, you've created a derived work. Which I agree with. You're also saying that this isn't `mere aggregation', so you're not allowed to use the easy-out the GPL gives you. So it'd be perfectly okay for Corel to do something like setup their own ftp site, that doesn't contain dpkg, but does contain their frontend, and tell people to include both the Corel and Debian sites in their apt sources.conf. We'll blithely assume they can get to the point where Apt's functional without infringing, although I'm not sure how they'd manage this. In this case, since they're never distributing dpkg, or any part of it, they don't possibly infringe. In spite of the system() call in the frontend. Agreed? But let's work with a single CD that contains both get_it and dpkg. From the appropriate section of the GPL: ] These requirements apply to the modified work as a whole. If Hmmm. Note, `modified work'. First thought, is that this may not even apply at all. Under section (1) they can simply copy dpkg verbatim as they receive it (from the Debian mirror network), and ignore section (2) entirely. This could work quite legitimately. It'd even force them to cooperate with Debian, since they'd have to distribute exactly what we give them which means if they want a bugfix made, they have to give it to us first. Well. Theoretically. This'd be pretty easy to work around. OTOH, you could claim that making a CD is actually getting dpkg, and making some modifications (namely, adding a whole bunch of other stuff). This seems more like a legal technicality than anything I'd really want to be a part of, though. ] identifiable sections of that work are not derived from the Program, ] and can be reasonably considered independent and separate works in ] themselves, This exception kind-of applies: identifiable sections are not derived from dpkg, and can reasonably be considered separate. It's questionable whether you'd consider them independent... ] then this License, and its terms, do not apply to those ] sections when you distribute them as separate works. ...but, since this section seems to be for `if you add a function in a separate source file, you're allowed to license that source file however you like, as long as its GPL compatible', I think we can consider it independent. ] But when you ] distribute the same sections as part of a whole which is a work based ] on the Program, the distribution of the whole must be on the terms of ] this License, whose permissions for other licensees extend to the ] entire whole, and thus to each and every part regardless of who wrote it. ...but that doesn't matter for the CD anyway. The paragraph after the next one is
Re: Corel's apt frontend
On Sat, Oct 30, 1999 at 11:40:16PM -0500, Chris Lawrence wrote: I suspect a blanket prohibition on reference by non-GPL'ed software would be incredibly dumb, even if it were permitted by copyright law. It would forbid anything non-free from operating as a shell (and would even prohibit KDE programs from launching GNU software). Not to mention that it'd be impossible to launch GNU software on a non-GNU system, or even boot a GNU system in the first place (as the boot sector is referenced by a non-free BIOS or other boot rom). It's amazing how often this is misunderstood. Use of a GPL program is not restricted, or even covered by the GPL. Only copies, modifications and distributions are. So, a blanko prohibition on reference would only affect the distribution (etc) of a derived work, not the use. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: jdk1.1 license changes
On Sat, Oct 30, 1999 at 08:49:04PM -0700, Stephen Zander wrote: The attached file will be part of the jdk1.1 upload entering Incoming some time later tonight. I trust it resolves bugs #37599 #40696. Content-Description: GNU/Debian license for jdk1.1 The GNU/Debian linux distribution of the Java(tm) Development Kit is subject to the following additional terms and conditions: What the hell is GNU/Debian linux 2. Persuant to clause 1.2 in the Source License, I hereby give permission for Debian to make unlimited electronic copies of the Java(tm) Devlopment Kit for archival and distribution purposes only. Well, here it is Debian, which hopefully means us anyway, so I guess it's okay... (what does persuant mean, btw?) 1.1 Sun grants to you (Licensee) a nontransferable, nonexclusive, royalty-free, limited license to use a copy of the Java Source Code (Licensed Software) in the United States, Canada, Japan, Australia and the European Union (constituted as of the Effective Date), at the location identified below, Erh, what about Russia? What about India, Korea, Vietnam? What about China? What about the all the small isles on the world? Where are our non-free mirrors? If this is superceeded by point 2. above, point 2. above should probably say so. Anyway, this license scares the hell out of me. I am sure it's well meaning, but compared with most other licenses in Debian, it's really cutting the edge of what is legal for us in many areas. Thanks, Marcus going back to work on GNU/Debian hurd. ;) -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 04:44:47AM -0500, Raul Miller wrote: It's true that the GPL was written for programs, not music. However, many countries have a legal concept of a moral right of integrity for a copyrighted work, to prevent its mutilation. The U.S. doesn't recognize this as an automatic right, On Sun, Oct 31, 1999 at 10:43:29PM +1000, Anthony Towns wrote: From looking at http://www.smithlyons.ca/it/laws/copyright_act.htm, Canada does though. I just love the whole `linking with non-free software as vandalism' aspect of this. :) I didn't think this was so much about the right of integrity, so much though as just regular copyright. I agree with you completely. I brought up this issue to show that the underlying concept isn't unique to the GPL. What I really should have done was come up with an example of a Broadway play where the license limited the forms the performance could take -- but I didn't want to take that much time for legal research. So I just settled for showing that the there's similar legal concepts. ... Okay, forget this. I was assuming you were saying that having system(dpkg --help); in your program meant that you had to put that program under the GPL. I think this is wrong, because you're not actually copying any of dpkg, and thus copyright law doesn't come into effect. Whereas what you're really saying, is that when you create a CD, or ftp site, or distribution, or whatever, containing both dpkg and your dpkg_help program, you've created a derived work. Which I agree with. You're also saying that this isn't `mere aggregation', so you're not allowed to use the easy-out the GPL gives you. So it'd be perfectly okay for Corel to do something like setup their own ftp site, that doesn't contain dpkg, but does contain their frontend, and tell people to include both the Corel and Debian sites in their apt sources.conf. We'll blithely assume they can get to the point where Apt's functional without infringing, although I'm not sure how they'd manage this. In this case, since they're never distributing dpkg, or any part of it, they don't possibly infringe. In spite of the system() call in the frontend. Agreed? That's almost exactly what I'm saying. I say almost exactly because of the relatively new concept of contributory infringement. Rather than spend a lot of time defining this concept, I'll just refer you to http://www.dcl.edu/lawrev/97-4/muroff.htm#24 If it weren't for this, then yes: I would agree. But let's work with a single CD that contains both get_it and dpkg. From the appropriate section of the GPL: ] These requirements apply to the modified work as a whole. If Hmmm. Note, `modified work'. First thought, is that this may not even apply at all. Under section (1) they can simply copy dpkg verbatim as they receive it (from the Debian mirror network), and ignore section (2) entirely. This could work quite legitimately. It'd even force them to cooperate with Debian, since they'd have to distribute exactly what we give them which means if they want a bugfix made, they have to give it to us first. Well. Theoretically. This'd be pretty easy to work around. OTOH, you could claim that making a CD is actually getting dpkg, and making some modifications (namely, adding a whole bunch of other stuff). This seems more like a legal technicality than anything I'd really want to be a part of, though. Well, for example, editorial notes are considered modification, for the purposes of copyright -- even though anyone who edits material would consider the underlying document to be unmodified. But the real kicker is contributory infringement. Because the front end is designed to incorporate dpkg, it doesn't really matter that Corel is allowed to distribute verbatim copies of dpkg -- using that permission to create massive quantities of installed systems which are running what is clearly a composite program is still an issue. ] identifiable sections of that work are not derived from the Program, ] and can be reasonably considered independent and separate works in ] themselves, This exception kind-of applies: identifiable sections are not derived from dpkg, and can reasonably be considered separate. It's questionable whether you'd consider them independent... ] then this License, and its terms, do not apply to those ] sections when you distribute them as separate works. ...but, since this section seems to be for `if you add a function in a separate source file, you're allowed to license that source file however you like, as long as its GPL compatible', I think we can consider it independent. Sure, and even if the corel front end were in the same executable file as dpkg it would be reasonable for the corel front end to have its own copyright for the parts supplied by Corel. But you still wouldn't be allowed to distribute the result if the corel license conflicted with the GPL. ] But when you ]
Re: jdk1.1 license changes
BTW; if anyone is discussing this exclusively on debian-legal, please cc me: I'm not on that list. Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Marcus What the hell is GNU/Debian linux The jdk *as it stands* doesn't even support Hurd, so refering to it in a licence is pointless. Marcus Well, here it is Debian, which hopefully means us Marcus anyway, so I guess it's okay... (what does persuant Marcus mean, btw?) Debian is used everywhere else to refer to the GNU/Debian linux distribution because it's less typing. Again, Hurd has no relevance here, this software only works in a linux environment unless you've got Hurd emulating linux in which case try the current package, there are no noticable differences. Persuant is a typo, it's pursuant: conforming to or in accordance with. 1.1 Sun grants to you (Licensee) a nontransferable, nonexclusive, royalty-free, limited license to use a copy of the Java Source Code (Licensed Software) in the United States, Canada, Japan, Australia and the European Union (constituted as of the Effective Date), at the location identified below, Marcus Erh, what about Russia? What about India, Korea, Vietnam? Marcus What about China? What about the all the small isles on Marcus the world? Marcus Where are our non-free mirrors? If you'd read the entire text, you'd see that the section you just quoted is part of Sun's Non-commercial source licence, an agreement between Sun and myself which I explicitly noted appears *for reference only.* -- Stephen So if she weighs the same as a duck, she's made of wood And therefore?... A witch!
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] quote 0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. 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. (Hereinafter, translation is included without limitation in the term modification.) Each licensee is addressed as you. Surely you can see that is circular. To paraphrase, The program is the program or a derivative work of the program. There is no definition there, unless you consider A rose is a rose to be a definition. The act of running the Program is not restricted This is going to make it extremely difficult to convince anyone that the act of running th program through its intended interface, or packaging the program with a work that runs it through its intended interface, can possibly create a derived work. So, you can circumvent the GPL through various kinds of interfaces that allow one program to refer to another without explicit copying. It's a problem in the GPL that should be fixed. I don't believe we can talk our way around it without fixing the GPL first, and then it only applies to future work. Thanks Bruce
Re: Corel's apt frontend
From: Joseph Carter [EMAIL PROTECTED] Given the choice between making the GPL a non-free license and having a way to potentially do something bad with a GPLed program, I would say it's better to leave things as they are. It's a false dichotomy. I think we could keep it a free license and close this loophole too. Thanks Bruce
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. A front end is a front end is a front end. It's capable of controlling any program that has a user interface that coincides with a certain subset of dpkg's user interface. Claiming that this makes the front end a legal deriviate of any random program it can control is suspiciously close to claiming an interface copyright. In a wierd, backwards way, but an interface copyright nevertheless. -- Henning MakholmMake it loud, make it complicated, make it long, and make it up if you have to, but it'll work all right.
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:19:30AM -0800, Bruce Perens wrote: The copying that's relevant here is the copying which goes into the production of the cdroms. That's the same whether dpkg is in the same file as corel's front end or a different file. But that can not possibly be relevant, because it's explicitly excluded in the GPL. Could you be more specific? My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. My argument is that courts don't care whether a file has a .o extension, a .so, or no extension at all -- that they aren't really concerned how many files make up the program, and that they don't care all that much about the technical details of which system calls where made or what address spaces are in use. So if you're talking about the verbatim copy permission in the GPL I'm saying that it's irrelevant for this argument because we're not talking about a verbatim copy but a derivative work. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 10:53:31AM -0800, Bruce Perens wrote: Given the choice between making the GPL a non-free license and having a way to potentially do something bad with a GPLed program, I would say it's better to leave things as they are. It's a false dichotomy. I think we could keep it a free license and close this loophole too. Please keep trying then--but the discussion is headed the wrong way right now. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- * o-o always like debmake because he knew exactly what it would do... ibid o-o: you would ;-) pgpFb3bw5rUf3.pgp Description: PGP signature
Re: Corel's apt frontend
[EMAIL PROTECTED] (Bruce Perens) writes: The act of running the Program is not restricted This is going to make it extremely difficult to convince anyone that the act of running th program through its intended interface, or packaging the program with a work that runs it through its intended interface, can possibly create a derived work. Which is fine. It *can't* possibly. It's a problem in the GPL that should be fixed. I don't see any problem. -- Henning Makholm*Se*!! Nu hælder den vand ud af ørerne *igen*!! *Et mirakel*!!!
Re: Corel's apt frontend
Raul Miller [EMAIL PROTECTED] writes: Sure, but a frontend isn't mere aggregation -- in this case if you take out the GPLed part of the system, the performance of that front end can't happen. On Sun, Oct 31, 1999 at 08:36:39PM +0100, Henning Makholm wrote: A front end is a front end is a front end. A variable is a variable is a variable. That doesn't mean that all variables are equivalent. It's capable of controlling any program that has a user interface that coincides with a certain subset of dpkg's user interface. Clearly you're not talking about all front ends here -- you can't be talking about ddd, for example. So you're talking about the Corel front end for dpkg. And that's very clearly not designed to be a program which interfaces to arbitrary package managers, but a program which interfaces specifically to dpkg. Corel would be distributing it in conjunction with dpkg and not, for example, in conjunction with sun's package manager. And I think it would utterly fail if you renamed pkgadd as dpkg. Claiming that this makes the front end a legal deriviate of any random program it can control is suspiciously close to claiming an interface copyright. In a wierd, backwards way, but an interface copyright nevertheless. More like a copyright for where there is no interface. For example, if Corel supplies its own implementation of dpkg to run under the front end then there would obviously be no problem. Here, the commonality between two distinct implementations create an interface and there's no interface copyright on that interface. To give an example of the other extreme, consider a program which used the command line interface plus the ptrace interface to interact with a verbatim copy of gcc. With a little thought you can do anything in this fashion that you can do with relinking (and more). Would you argue that that's legal? If not, and if the part of the program which implemented ptrace was itself released under the GPL, would that make the derived compiler legal under the GPL? Allow me to repeat the definition of a computer program under us copyright law: A ''computer program'' is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. Do you see anything in there which says that if execve() is used then the instructions it executes aren't part of the computer program? So yeah, for the purposes of copyright law, it's reasonable to consider that all programs called by a shell script are a part of that computer program. And, yeah, this can have interesting implications if you're trying to distribute this computer program. Then again, if you don't have the right to distribute all the pieces of a program why would you be distributing it? Mostly this is a non-issue... -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 05:53:31AM -0500, Raul Miller wrote: And if the apache module in question calls /bin/bash specifically? Or if /bin/bash calls apache? I'm having trouble imagining a work which involves apache and bash where bash is an inseperable aspect of the whole. Bashisms are so.. trivial.. and so unrelated to web serving. I guess it might be possible for you to create one, though -- and if you did you'd have to address the copyright issues before you could distribute it. [Do you know anyone distributing apache and bash together along with such software? If so, you might want to suggest that they not use bashisms...] The GPL doesn't say there are legal issues involved with doing so. Also if Corel's front-end calls apt, the fact that apt uses dpkg as a backend is arguably apt's problem since it is intended for apt to also support rpm at some point. -- - Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43 - [EMAIL PROTECTED] 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 -- California, n.: From Latin calor, meaning heat (as in English calorie or Spanish caliente); and fornia' for sexual intercourse or fornication. Hence: Tierra de California, the land of hot sex. -- Ed Moran pgpwlguzsUCiq.pgp Description: PGP signature
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. I agree that it enhances dpkg. The problem is that it does it without copying. You could postulate that the use of a command-line interface is a device contrived for the explicit purpose of circumventing the copyright, but only if the command-line interface was created for that purpose. The command-line interface, however, pre-existed Corel's work and was made explicitly for other programs, such as shell scripts, to call it. If we want to assert a copyright on that command-line interface, what we need is a copyright on the list of commands that can be fed to that interface, so that all programs that call those commands are infringing on that copyright. Then, we have to write in exceptions for shell scripts and normal use, everything except enhanced front-end programs. I doubt the result would be a DFSG-compliant license. And it's clearly an API copyright. If we want to modify the GPL to prevent this from happening in the future, I think we can do that and keep it free software. I don't see how we can do this retroactively without shooting ourselves in the foot. Thanks Bruce
Re: Corel's apt frontend
From: Raul Miller [EMAIL PROTECTED] My argument is that since the corel front end enhances dpkg it counts as a derivative work based on dpkg for the purpose of copyright law, just as editorial notations on a screen play create a derivative work even though the text of the screen play is in some sense unchanged. On Sun, Oct 31, 1999 at 01:47:31PM -0800, Bruce Perens wrote: I agree that it enhances dpkg. The problem is that it does it without copying. But you do need a copy of dpkg or it won't work. So I don't see how this can be a problem. You could postulate that the use of a command-line interface is a device contrived for the explicit purpose of circumventing the copyright, but only if the command-line interface was created for that purpose. The command-line interface, however, pre-existed Corel's work and was made explicitly for other programs, such as shell scripts, to call it. Why make this postulate? ld wasn't invented to circumvent copyright, why must execve() have been invented for this purpose? If we want to assert a copyright on that command-line interface, what we need is a copyright on the list of commands that can be fed to that interface, so that all programs that call those commands are infringing on that copyright. Then, we have to write in exceptions for shell scripts and normal use, everything except enhanced front-end programs. I doubt the result would be a DFSG-compliant license. And it's clearly an API copyright. We're not asserting copyright on that command-line interface. We're asserting copyright on a derived work which happens to use that command line interface. Once again, there's nothing in the GPL about linkages, and there's nothing in copyright law about linkages. A function call that happens to use fork(), execve(), waitpid() isn't singled out from any other machine instructions in copyright law. The problem here is that the front end relies on GPLed code to create its result, but uses a proprietary license. So to distribute the resulting program (which happens to not reside in a single file) Corel would need to fix the licensing conflict between these two pieces of the program. If we want to modify the GPL to prevent this from happening in the future, I think we can do that and keep it free software. I don't see how we can do this retroactively without shooting ourselves in the foot. And I don't think it's necessary to modify the GPL at all. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 12:34:09PM -0800, Joseph Carter wrote: Also if Corel's front-end calls apt, the fact that apt uses dpkg as a backend is arguably apt's problem since it is intended for apt to also support rpm at some point. How does apt's license conflict with dpkg's? [Or with rpm's?] Last time I checked you could distribute all of these under the GPL. -- Raul
Re: Corel's apt frontend
On Sun, Oct 31, 1999 at 12:08:22PM -0800, Joseph Carter wrote: Please keep trying then--but the discussion is headed the wrong way right now. Where would you like the discussion to head? Thanks, -- Raul
