Re: Plugins, libraries, licenses and Debian
Brian T. Sniffen wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: The package is the result of collection and assembling of two preexisting materials. However, what is the reason for qualifying the resulting work as an original work of authorship? The definition seems to suggest that the _compilation_ must be original, not its parts. I think I'm agreeing with you, but I'm not convinced I entirely undersstand where you're going with this. The original issue, as far as I understood is, was whether it is allowed to bundle a GPL-licensed plugin with a host program under a GPL-incompatible license. Or actually, a host that also uses a second plugin which is under a GPL-incompatible license, but that shouldn't make a difference. The host and the plugin can obviously be distributed separately as they are original works created by different people. But can someone take them, put them together into a single package and distribute the result? Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re: Plugins, libraries, licenses and Debian
Andrew Suffield wrote: On Wed, Dec 10, 2003 at 10:34:28PM +0100, M?ns Rullg?rd wrote: The problem is that all such definitions are based on the notion that a work is either something tangible, or a performance act. They simply don't apply well to computer programs. You're living in the EU I note, so computer programs are explicitly defined as literary works (by an EU directive). Look up your local copyright law's section on literary works for a starting point, and compare the EU copyright directives, because those probably apply as well. The 1991 copyright directive has been turned into national law in all EU countries by now. Directives do not have legal effect by themselves. Think of them as model acts that EU countries have to adopt. But anyway, although computer programs definitely are recognized as subject to copyright in the EU, they do not fit the definition of derivative work or adaptation very well. There just is no guidance in this area. If you translate something, turn a book into a play or putting a poem to music, you can just look it up in the law. But software just isn't discussed much (other than the no-reverse-engineering-unless and one-backup-copy provisions and the like). Copyright law seems to have been written with the traditional idea of selling binaries under proprietary licenses in mind. This makes it very difficult to cope with open source licenses. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re: Plugins, libraries, licenses and Debian
Arnoud Engelfriet [EMAIL PROTECTED] writes: But anyway, although computer programs definitely are recognized as subject to copyright in the EU, they do not fit the definition of derivative work or adaptation very well. There just is no guidance in this area. If you translate something, turn a book into a play or putting a poem to music, you can just look it up in the law. But software just isn't discussed much (other than the no-reverse-engineering-unless and one-backup-copy provisions and the like). Exactly my point. What would the equivalent of dynamic linking be? A book that says on the first page: take chapters 3 and 6 from book Foo and insert after chapter 4 in this book, then read the result. -- Måns Rullgård [EMAIL PROTECTED]
Re: Plugins, libraries, licenses and Debian
Arnoud Engelfriet [EMAIL PROTECTED] writes: Brian T. Sniffen wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: The package is the result of collection and assembling of two preexisting materials. However, what is the reason for qualifying the resulting work as an original work of authorship? The definition seems to suggest that the _compilation_ must be original, not its parts. I think I'm agreeing with you, but I'm not convinced I entirely undersstand where you're going with this. The original issue, as far as I understood is, was whether it is allowed to bundle a GPL-licensed plugin with a host program under a GPL-incompatible license. Or actually, a host that also uses a second plugin which is under a GPL-incompatible license, but that shouldn't make a difference. In my opinion, there is a difference. In the two plugins case, you don't need to use them at the same time. The host and the plugin can obviously be distributed separately as they are original works created by different people. What if they have the same author? If the GPL tries to make restrictions on what independent works users of GPL'd software can create, I would definitely not call it a free license. Would such a restriction even be valid under copyright law (or whatever law applies)? -- Måns Rullgård [EMAIL PROTECTED]
Re: [POSITION SUMMARY] Re: Plugins, libraries, licenses and Debian
On Tue, 2003-12-09 at 17:22, Andrew Suffield wrote: Actually, it's closer than you think. Any product [arbitrary definition] that requires all three components is a derivative work of all of them; that will almost certainly violate one or more of the licenses. It may be; it may not be. Not even the FSF contents that a shell script which requires bash is a derivative work of bash; a perl script of perl; etc. That's why its a discussion for another thread :-) signature.asc Description: This is a digitally signed message part
Re: Plugins, libraries, licenses and Debian
M?ns Rullg?rd wrote: Arnoud Engelfriet [EMAIL PROTECTED] writes: The original issue, as far as I understood is, was whether it is allowed to bundle a GPL-licensed plugin with a host program under a GPL-incompatible license. Or actually, a host that also uses a second plugin which is under a GPL-incompatible license, but that shouldn't make a difference. In my opinion, there is a difference. In the two plugins case, you don't need to use them at the same time. Correct. However, if you do not use them at the same time, the problem does not arise. So the issue is only relevant if you do want to bundle both so that the host loads both at the same time. The host and the plugin can obviously be distributed separately as they are original works created by different people. What if they have the same author? Then you could make an argument that he intended both to work together, so there must be an implicit exception to the GPL license he applied to the plugin. If the GPL tries to make restrictions on what independent works users of GPL'd software can create, I would definitely not call it a free license. Would such a restriction even be valid under copyright law (or whatever law applies)? The GPL does not impose restrictions on independent works. Restrictions are imposed on works based on the GPL-licensed work. So the host never becomes GPL, but a new work consisting of host plus plugin seems to qualify as a derivative of the plugin (and of the host, of course). Then the question is, are you permitted to distribute this new work? For that, you must comply with the licenses of both the host and the plugin. Since the plugin is GPL, the host's license must be GPL-compatible otherwise you cannot fulfill both licenses at the same time. Legally speaking I don't think there is much you can *not* validly require in a license, if you write it as a condition for being granted permission. M$ for example forbids you to distribute their software in conjunction with GPL-licensed software. Of course at some point other issues beyond copyright law become relevant, such as abusing your dominant market position or the reasonableness test for contracts (if licenses without consideration qualify as contracts in your jurisdiction). Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/
Re: Plugins, libraries, licenses and Debian
Måns Rullgård [EMAIL PROTECTED]: Exactly my point. What would the equivalent of dynamic linking be? A book that says on the first page: take chapters 3 and 6 from book Foo and insert after chapter 4 in this book, then read the result. Wasn't there a case with a book containing questions and answers about a television programme that was considered (in the USA) to infringe the copyright of the television programme? Maybe that was dynamic linking ...
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) schrieb: Arnoud Engelfriet [EMAIL PROTECTED] writes: But anyway, although computer programs definitely are recognized as subject to copyright in the EU, they do not fit the definition of derivative work or adaptation very well. There just is no guidance in this area. If you translate something, turn a book into a play or putting a poem to music, you can just look it up in the law. But software just isn't discussed much (other than the no-reverse-engineering-unless and one-backup-copy provisions and the like). Exactly my point. What would the equivalent of dynamic linking be? A book that says on the first page: take chapters 3 and 6 from book Foo and insert after chapter 4 in this book, then read the result. Perhaps more realistic: Exercises and solutions. An add-on book to: A.Uthor, Principles of Somethingology. An undergraduate textbook, PubLisher Inc., Someplace 2002 with chapter 10 containing the exercise: 5. The derivation of the CENTRAL FORMULA in chapter 3 (pp. 64ff) was a little simplified. With the knowledge of the Advanced anything as outlined in chapter 10, you should now be able to understand the complete derivation. a) What is the simplification in the derivation on p. 66? b) How can it be formulated correctly? Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
personal invite -- Ryze business networking
Rahul has invited you to join Rahul's personal and private network on Ryze. To view the invite, click on: http://www.ryze.com/in/yyXOSc48EJOdzekCfQab Ryze is a networking service that helps people grow their careers, businesses and lives. * meet entrepreneurs, CEOs and other neat people through your existing friends and contacts * get expert advice and contacts through special networks focused on your interests and industry * get your own networking-oriented home page * keep in touch with your friends and keep track of their birthdays http://www.ryze.com/in/yyXOSc48EJOdzekCfQab
personal invite -- Ryze business networking
Rahul has invited you to join Rahul's personal and private network on Ryze. To view the invite, click on: http://www.ryze.com/in/P4qjjgGbhzs8pJBCIBfQ Ryze is a networking service that helps people grow their careers, businesses and lives. * meet entrepreneurs, CEOs and other neat people through your existing friends and contacts * get expert advice and contacts through special networks focused on your interests and industry * get your own networking-oriented home page * keep in touch with your friends and keep track of their birthdays http://www.ryze.com/in/P4qjjgGbhzs8pJBCIBfQ
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) schrieb: Wouldn't such a book be allowed? I can't see anything that would stop it. You're probably right. I wasn't looking for something that wouldn't be allowed, but for something that is as close as possible as linking. It seems that what I invented, although it mimicks linking, would not be a derivative work in literature - or if it is, it would be allowed citation. Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Frank Küster) writes: [EMAIL PROTECTED] (Måns Rullgård) schrieb: Wouldn't such a book be allowed? I can't see anything that would stop it. You're probably right. I wasn't looking for something that wouldn't be allowed, but for something that is as close as possible as linking. It seems that what I invented, although it mimicks linking, would not be a derivative work in literature - or if it is, it would be allowed citation. If that analogy is indeed an appropriate one, it would imply that dynamic linking isn't controlled by the GPL. Not that I'd mind. -- Måns Rullgård [EMAIL PROTECTED]
Status of new LPPL version?
Dear all, does anybody know what is going to happen with regard to LPPL-1.3, and in which timeline? The latest mails I found were http://lists.debian.org/debian-legal/2003/debian-legal-200306/msg00206.html (a new draft) and two analyses by Branden Robinson, with one follow-up by Frank Mittelbach. I would be glad to be pointed to some place where I can find further information on that. The actual reason why I looked for it is that I am thinking of incorporating some code from a GPL'ed LaTeX add-on package into mine, but do not want to license mine under GPL, but rather under a DFSG-free LPPL. I guess it will be much easier to convince the author to re-license his package if I can tell him that LPPL is also DFSG-free. Thank you, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Plugins, libraries, licenses and Debian
[EMAIL PROTECTED] (Måns Rullgård) schrieb: [EMAIL PROTECTED] (Frank Küster) writes: [EMAIL PROTECTED] (Måns Rullgård) schrieb: Wouldn't such a book be allowed? I can't see anything that would stop it. You're probably right. I wasn't looking for something that wouldn't be allowed, but for something that is as close as possible as linking. It seems that what I invented, although it mimicks linking, would not be a derivative work in literature - or if it is, it would be allowed citation. If that analogy is indeed an appropriate one, it would imply that dynamic linking isn't controlled by the GPL. Not that I'd mind. I guess the analogy is not appropriate... Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Changes in formal naming for NetBSD porting effort(s)
[ Adding -legal to the Cc; it may become inappropriate for -devel, at ] [ some point, in which case folks should remove the -devel Cc. The -bsd ] [ Cc should probably remain no matter what, as this could potentially ] [ affect any of the BSD ports.] On Fri, Dec 12, 2003 at 11:54:09AM -0500, Branden Robinson wrote: [I am not subscribed to debian-bsd.] On Thu, Dec 11, 2003 at 04:39:47PM -0700, Joel Baker wrote: On December 2nd, I was contacted by Luke Mewburn, on behalf of The NetBSD Foundation, asking about the transition to calling the NetBSD port Debian GNU/KNetBSD, and expressing their appreciation for this change, as it reflects (in their opinion) a more accurate statement about what the system is, and avoids any potential dilution of the NetBSD trademark. Uh-huh. I'll go check, but is all of this discussion archived on debian-bsd? [minutes pass] I checked, and I don't see the *specific* grounds for the request explicated anywhere. I guess it depends on precisely what you mean by specific grounds, in this case. If you mean 'specific accusations of dilution of trademark', then I don't believe there have been any. I did, however, say that I (at least) would be happy to try to find a name they found equally suitable, for the same reasons, rather than continue to use the current one. What makes a suitable name? Please be specific. If you don't know, I think you should request this information from the NetBSD Foundation. As far as I can tell, anything which does not use the bare word 'NetBSD' as part of it's name, but I certainly can request clarification from Mr. Mewburn and The NetBSD Foundation about that. On December 3rd, Mr. Mewburn confirmed that The NetBSD Foundation would prefer to see the name changed, and I brought the issue up on the debian-bsd mailing list for discussion. [...] Okay, yeah, I'm caught up on that part. The thread seemed to be mostly concerned with technical issues, which is a completely legitimate concern, but I think the discussion to date, if comprehensively reflected on the -bsd list has almost completely neglected discussion of the central thrust of the request you received. I think that is largely a reflection of nobody had any disagreement on the principle, or a better suggestion for the formal port name, combined with the fact that it triggered reviewing some of the haphazard naming conventions with a critical eye, and making sure that they were reasonable and rational. The thread is, indeed, split into two interleaved parts, and the non-technical part is almost empty. 4) The Debian port name will become 'Debian GNU/KLNetBSD(i386)'[1]. Well, no offense, but that's ugly as hell, and is going to square the amount of confusion people experience when trying to decode our OS names. Agreed, unfortunately - it is, and I suspect it may well. Suggestions for better naming welcome, of course (or even a direction to go in). If anyone objects, or wishes to see further requirements met, please let me know, and I'll do what I can to resolve the situation. I don't understand the nature of your request. They're cool with Debian GNU/KLNetBSD but not Debian GNU/NetBSD? Why, exactly? I believe (note: personal view) that the core is a perceived difference between the bare word 'NetBSD', which has, prior to this port, implied a kernel, libc, *and* userland of a specific form, and a variant of that name which is recognizeable, but distinctive enough to not cause confusion between their product and what we intend to produce. And how does trademark enter into this, exactly? In both cases, the mark is still being used. Yet they're cool with the former and not the latter? As I understand the law[1], the mark is no more or less used or diluted in either case. I do not have anything remotely like the background to discuss this meaningfully - frankly, I wasn't particularly aware that there might be any substantive issue with the assertion. See below for more. Debian either needs a trademark license from the NetBSD Foundation for use of the NetBSD mark, or it does not. If we do, then our hands are tied and we might as well ask them to tell us what they want it called, and what the terms of use are. Since the Debian Project doesn't legally exist, this will probably have to go through SPI. If we don't need a trademark license, then I don't understand why they've grounded their request for a name change on a claim to be preserving the mark. This might well be a reasonable path to take, given that TNF (those making the actual request) are, in many ways, related to The NetBSD Project in the same fashion that SPI and Debian are related; one is a legal entity, the other is a bunch of folks producing an operating system. Certainly, it would make things more explicit and less prone to future problems. It might be best to remove NetBSD from the name of the OS
Re: Bug#223819: RFA: murasaki -- another HotPlug Agent
Scripsit Pierre Machard [EMAIL PROTECTED] Last week a RC bug was filled on this package (#223197). A good solution to close this bug is probably to upload a newer version, No, it seems to be yet another fallout of the linux-kernel-header transition. There are quite a lot of those at the moment. The underlying bug here is already known: it's #221543. but the lastest developpment version dosen't meet requirements to be include in Debian[1]. [1] : http://packages.qa.debian.org/m/murasaki/news/2.html I'm not suggesting that you continue to maintain a package that in your opinion is useless, but the above seems to be based on a misunderstanding. In the email you link to, you say | The problem is that a Debian package has not the right to modify | automaticaly things under the /etc dir. That means that murasaki | itself is not allowed to write anything in /etc/murasaki/*. That is not true. The program *being packaged* is allowed to write to /etc as part of its normal operation. Apart form programs whose *task* is to change things in /etc (visudo, update-*) the most well-known cases are ifupdown and mount. It is generally recogized as being something you ought to do only if you really have no choice, but it is not *forbidden* by policy. | -From the Debian policy : | Note that a package should not modify a dpkg-handled conffile in its | maintainer scripts. Doing this will lead to dpkg giving the user | confusing and possibly dangerous options for conffile update when the | package is upgraded. That has nothing to do with what the program *itself* does to files that are *not conffiles*. | Instead of modifing the content of /etc/murasaki/* please could you | consider moving files under /var/run/murasaki or something like that. | (/var/cache/murasaki or /var/lib/murasaki, etc...) If the upsteam source uses filenames that Debian is not happy with, it is the job of the Debian maintainer to patch the programs such that the filenames conform to policy. It is well and fine to try to whack some sense into upstream *also*, but please change the behavior such-and-such because Debian says so is not a good way to foster respect for Debian and our packaging process. Much better would be I use the attached patch to sanitize the behavior of your program in my Debian package. Please consider applying it to your sources. -- Henning Makholm Hele toget raslede imens Sjælland fór forbi.
