Re: Desert island test
On Thu, Mar 06, 2008 at 08:15:10AM -0800, Ken Arromdee wrote: On Thu, 6 Mar 2008, Adam Borowski wrote: Having a country non-free doesn't make a license non-free. In the chinese dissident test the user chooses to fight against the bloody murderer (who wears an uniform) -- he breaks unrelated laws, yet does not breach the license in any way. A license that fails the dissident test *is* non-free. No, a license that doesn't follow the DFSG is non-free; a license that fails the dissident test is merely not useful for someone who wants to violate local law while obeying copyright law. The claim that protesting is a field of endeavour, and that forcing you to be publically associated with your use, distribution or development of software is discrimination is at best a matter of opinion; it's not a logical necessity. The dissident test is certainly useful for people trying to understand the implications of license conditions; but it's not a simple non-free, no matter how long individual contributors to -legal have thought it, or how emphatically they state it... Cheers, aj signature.asc Description: Digital signature
Re: Questions about liblouis
On Tue, Feb 26, 2008 at 11:40:39PM +, John Halton wrote: On Tue, Feb 26, 2008 at 02:29:05PM -0800, Eitan Isaacson wrote: 3. The translation tables that are read at run-time are considered part of this code and are under the terms of the GPL. Any changes to these tables and any additional tables that are created for use by this code must be made publicly available. This fails the desert island test, and so the package is non-free. I think you're mistaken. You can scratch the tables in a rock on your desert island, with the scratchings facing the sky, and you're done. They're publically available at that point, whether or not the satellite images on Google maps have fine enough resolution, or there's a ship that comes by to visit: it's possible for either to happen, and you're allowing it, and that's all that's required. Cheers, aj signature.asc Description: Digital signature
Re: Desert island test (was: Questions about liblouis)
On Thu, Feb 28, 2008 at 12:20:56AM +, Steve McIntyre wrote: Ben Finney wrote: In other words, the desert island test is a way of expressing [...] So long as you add the rider that some of the debian-legal subscribers believe it (and some of the other common tests) are ridiculously contrived and bogus. What do you think's contrived or bogus about the desert island test? Being able to use, modify and redistribute the software in a poorly connected environment is pretty useful, and a desert island scenario just takes that to an extreme. The dissident test is another matter, given its implied violation of local law. Cheers, aj signature.asc Description: Digital signature
Re: perforce SCM licensing issues
On Mon, Sep 17, 2007 at 12:26:18PM +0100, Sam Clegg wrote: In principal, we also do not object to have Perforce binaries included in the non-free part of the debian distribution, as long as it is clear that you are the sole distributor and maintainer of the packages and Perforce is in no way liable for their content and support. AFAICT the binaries are freely distributable: On Tue, Sep 18, 2007 at 09:49:04AM +0100, Sam Clegg wrote: From the first download page: You may use software downloaded from Perforce for any purpose you want and for as long as you like. The Perforce Server supports only two users and five client workspaces unless used with a Perforce License. We will be happy to issue you a free Evaluation License to remove the user/workspace restrictions for a limited time. From the second download page: Disclaimer of Warranty Please do not download software from this page unless you have read the paragraph below and agree to it. Perforce Software, Inc. disclaims all warranties, either express or implied, including but not limited to the implied warranties of merchantability and fitness for a particular purpose. This means that if you download software from this page, you agree that Perforce Software, Inc. has no liability for any damages that you incur when using it, whether or not those damages are caused by a problem with the software, and whether or not you have brought such problems to Perforce's attention. I beleive this is the extent of the license that applies to those who download the linux binaries. There's no actual permission to distribute there, just a you may use. That leaves your email, but in principle we don't object isn't a very strong grant of permission to redistribute, though it's not completely terrible. Getting something a bit more definite (like Here's what I intend to upload to Debian non-free, does it look okay? Yes) and including that in the debian/copyright would be better. Otherwise it seems fine from what I can see. Cheers, aj signature.asc Description: Digital signature
Re: Anti-TPM clauses
On Wed, Sep 12, 2007 at 10:13:31PM +0200, Francesco Poli wrote: On Wed, 12 Sep 2007 09:31:04 +0200 Freek Dijkstra wrote: Are they *DFSG-free* or not? So yes, it *is* a GR-vote who decides here. Because the DFSG are only changed or clarified by such a vote. Please note that GR-2006-001 (http://www.debian.org/vote/2006/vote_001) did not change the DFSG: that would have needed a 3:1 supermajority, which the winning option did not require. Of course, whether an option requires a 3:1 supermajority is decided by the secretary based on his (or hypothetically her) best understanding and interpretation of the constitution, the proposed resolution and their implications. These are judgement calls, not facts that can be derived purely from an empirical study of the universe. Cheers, aj signature.asc Description: Digital signature
Re: Anti-TPM clauses
Olive wrote: non DFSG-free. Debian legal is only a mailing list to discuss licenses, by no means it is a tribunal that can take official decision. Only the ftp masters or a vote can decide litigious cases. Uh, litigious cases get decided by a court presumably. Contentious might be the word you're looking for... On Tue, Sep 11, 2007 at 08:56:40PM +0530, Shriramana Sharma wrote: And whom do the ftp-masters themselves answer to? Quis custodiet ipsos custodes? Debian is answerable to the public, you know. No, Debian's answerable to its members, which is the or a vote option above. The only senses in which Debian's answerable to the public is by people using other distros instead, or getting courts/police/whatever to force us to (not) do things. Cheers, aj signature.asc Description: Digital signature
Re: Bacula and OpenSSL
On Wed, Jul 25, 2007 at 03:12:33PM +1000, Anthony Towns wrote: In particular, going by the GPLv3: ] The System Libraries of an executable work [...] So I've done the here's what the license says, let's parse it to see if we can extract any meaning thing, but I haven't done it the other way -- here's what's intended, let's see if that fits the case we're considering, and if that helps understand the wording. (Well, to be fair, I haven't seen a very clear statement of what the FSF intends by the clause -- beyond minimal changes to the GPLv2 to make OpenSolaris okay anyway) I figure the exception is to allow people to write GPL programs on non-GPL operating systems and use the standard OS features and compilers/interpretors without having to worry. _But_ that exception needs to be limited, so that when you add features to a GPLed program that would otherwise have to be freed, you can't avoid freeing them by carefully packaging and making use of some loophole in the exception. Some characteristics of legitimate uses of that exception seem to me to be: (1) they're readily available features that come standard with the system (whether that be operating system, windowing system, programming language, etc) (2) they're not designed specifically for the program being used (3) they're independent of the program being used (4) they're used by standard components of the system, other than your program (5) they're used by other programs than the ones included with the system and that are unrelated to your program (6) they implement standard interfaces, with altnerate implementations that you could rebuild your program against without much bother (7) they implement standard interfaces, with source or docs available, so you could create your own implementation and build your program against that (8) the implementation is widely available and is easily and practicably obtained by anyone, either commercially or freely So writing GPLed apps that use Solaris features like dtrace or similar seem reasonable, in that dtrace hits (1)-(5), and (7) and (8); and GPLed programs that use the Windows API hit (1)-(5) and (8), though probably not (6) or (7), and programs that use non-free .NET or Java APIs probably hit (1)-(8). Having the test be something like: (1) and (2) and (3) and ( (4) or (5) ) and ( (6) or (7) or (8) ) seems to allow the things we want, and restrict the things we don't -- eg, trying to implement an add-on to GCC or emacs would fail (2) and (3), even if specially packaged so they met (1), (4), (5) and (8), eg. The above could be applied to writing GPLed software that used libraries with special proprietary packages like Mathematica or similar too; YMMV. To be a bit more concrete; say you have some GPLv3 code -- an implementation of an interesting peer-to-peer IM protocol, say. Then: - if you're running Vista or OS X, you can integrate it into the environment, add a native GUI and add new features that will be a pain to port back to a free OS because they use libraries that haven't been reimplemented elsewhere yet; then send it to Apple or Microsoft and have it be included as a standard part of the OS. - if you're running Debian, you have openssl as a standard component, but you can't add openssl support to your p2p IM app without making use of the system library exception and can't distribute it in Debian. So if Debian wants to have the same features as the new versions of Vista or OS X do, we can't just use our existing libraries and the GPL app as Microsoft and Apple did, we either have to reimplement the app with an OpenSSL friendly license, or reimplement OpenSSL. That is: it's easier for non-free OSes to incorporate GPLed code than for free OSes. Maybe that is the result of the way the GPLv3's been drafted, and maybe it actually has to be that way for some reason -- but is there really any question that the above's a bad outcome? If we can agree it is a bad outcome, it seems worth exploring other interpretations of the new System Library exception to see if we can avoid them. Cheers, aj signature.asc Description: Digital signature
Re: Bacula and OpenSSL
On Tue, Jul 24, 2007 at 05:10:32PM +0200, Shane M. Coughlan wrote: Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message: === I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, [...] I don't think it's accurate to say that glibc is any more tightly bound to the Linux kernel than OpenSSL is -- you can certainly use different libc implementations to access the kernel, just as you could use different SSL implementations such as gnutls. In particular, going by the GPLv3: ] The System Libraries of an executable work include anything, other than ] the work as a whole, that (a) is included in the normal form of packaging ] a Major Component, but which is not part of that Major Component, and ] (b) serves only to enable use of the work with that Major Component, ] or to implement a Standard Interface for which an implementation is ] available to the public in source code form. then libc can't treat the kernel as its Major Component because it's not included in the normal form of packaging [that] Major Component. That's somewhat fundamental technically, in so far as the kernel provides the hardware abstraction to a fairly static userspace/kernel ABI, and libc provides an implementation of the C (or POSIX or GNU) API based on the kernel's ABI. Up to that point you can just call it enabling use of the kernel (by people who can only speak C and POSIX), but the problem then comes if, say, you choose to implement some C or POSIX API (such as POSIX threads) entirely in userspace rather than using the kernel's features, and to take things a step further, perhaps decide to package that separately. Your cases are then: - libc implements pthreads as a thin layer over the kernel - libc implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a standard component of the operating system - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a optional and rarely installed component of the operating system - libpkthreads implements pthreads as a thin layer over the kernel threads, but is an experimental implementation looking to replace libpthreads, that's optional and (currently) rarely installed To me, the most natural line to draw when considering whether the pthreads implementation is a system library in the above is between the two libpthreads -- in the first three cases, how it's implemented is irrelevant, it's a standard library, implementing a standard API, that doesn't contaminate the GPLed software any more or less in any case, and is available to everyone who's going to use the GPLed software on the operating system in question. For the latter two cases, there's no reason to consider the pthreads implementations particularly important parts of the operating system, so they shouldn't be considered system libraries no matter how thin or heavy-weight they are compared to the kernel. If you're arguing that libc is only relevant in that it provides access to the kernel, I think you end up with the wrong answer in a few levels: - libc doesn't provide access to the kernel; it uses the kernel to provide a C API; printf() isn't a kernel call, eg, it's something native to libc - the clause becomes implementation dependent: if you implement something in the kernel, and provide it via libc it's can be used by GPLv3 programs, but if you implement it in libc, it's only accessible if it's an official standard - it becomes packaging dependent: if you implement an official standard in libc, that's okay, but if you implement it in a package of its own, that's not To take a more direct situation: under that interpretation, if you take glibc, implement a new, non-standard feature along the lines of obstacks, say, in glibc -- perhaps a rewrite of talloc -- and only make your new version of glibc available under the GPLv2. Then, even if that's included as a standard part of all Debian or Hurd or OpenSolaris installs, it's no longer possible to compile GPLv3 apps against that library, because the argument becomes: myglibc (prospective System Library) is included in the normal form of packaging the kernel (a Major Component), but is not part of the kernel, and
Re: Why is firebird in Debian?
On Fri, Jul 20, 2007 at 10:19:03PM -0700, Mike Bird wrote: Anthony Towns, [...] It appears that You are distributing firebird2-common in violation of IPL section 3.6, and therefore in violation of copyright law in many jurisdictions. Okay, so the extent of your complaint is that you don't think there's sufficient notice of how to get the source; and that you're not a user of a version of firebird2 let alone a version of it for which the source actually isn't trivially available, nor a contributor to it upstream, which are the only two cases for which you'd have any basis to actually complain? If so, great, whatever, but I'm not going to spend my time seeing how many ways you can come up with to be daft about legal issues. If you want to contribute to Debian, find something *productive* to do about analysing licenses, rather than trying to find ways to define everything you don't like as non-free or illegal. Cheers, aj signature.asc Description: Digital signature
Re: Why is firebird in Debian?
On Fri, Jul 20, 2007 at 08:03:37PM +0200, Francesco Poli wrote: On Fri, 20 Jul 2007 00:59:16 +0100 (BST) MJ Ray wrote: Francesco Poli [EMAIL PROTECTED] wrote: Could someone explain to me why firebird is in main? Because some ftpmaster hit approve, no-one found a bad enough bug to change it and this plan didn't happen yet: http://lists.debian.org/debian-legal/2006/03/msg00562.html In your opinion, what's the best course of action, at this point? File a serious bug against each firebird source package (firebird1.5 and firebird2.0), so that we can find out *why* [...] Serious bugs are not a tool so you can learn more about Debian. Don't abuse the bug tracking system. Yeesh. Cheers, aj signature.asc Description: Digital signature
Re: Why is firebird in Debian?
On Thu, Jul 19, 2007 at 11:43:17PM -0700, Walter Landry wrote: So where is the source for old versions stored? The alioth CVS is not publicly available. On Fri, Jul 20, 2007 at 08:16:45PM +0200, Francesco Poli wrote: According To Anthony Towns, I Am Always Wrong Because IANADD/IANAL On Fri, Jul 20, 2007 at 10:48:17PM +0200, Josselin Mouette wrote: Under what rationale did the ftpmasters decide it is OK for Debian not to respect the licenses of software we distribute? On Fri, Jul 20, 2007 at 02:22:33PM -0700, Dan Serban wrote: I've refused to work on past projects due to them being licensed under the MPL based on some discussion had on this list a few months/years? ago. I sure hope I wasn't wrong in doing so. Uh, guys, stop being insane. 1) The MPL requires you to make the source code to your modifications available for six-to-twelve months electronically _or_ to make it available on the same media as the executable version. We do the latter. In addition, old sources are available unofficially via snapshot.debian.net, http://snapshot.debian.net/archive/pool/f/firebird2.0/source/Sources.gz 2) That you're not a lawyer or a DD means that you're not trained in interpreting licenses, and that Debian's policies aren't based on your opinion -- in both cases. That means that you're not in a position to speak authoritively about most of the issues that come up on this list, so when what you write is written in a way that people will misinterpret as an authoritative answer, that's a problem, which is only compounded if what you say is also incorrect. Licensing analysis requires an ability to understand subtleties of language, and I wouldn't expect anyone who's competent at that to need the above repeatedly explained. 3) Not understanding the license or how we're complying with it doesn't mean we aren't. 4) That a license is DFSG-free doesn't mean it's good any more than a license not being DFSG-free means it's bad -- there are lots of reasons to not use DFSG-free licenses or software under the licenses, and there are lots of reasons to use and work on software that's under DFSG-non-free licenses. The DFSG is *Debian's* free software guidelines, that're meant to be useful for *Debian* to make decisions. Personally, if I've got a choice, I don't use licenses that are GPL incompatible, eg, which the MPL certainly is. Another complaint with the MPL is that it's designed for Mozilla, rather than general use by random organisations, which has led to a fair bit of unnecessary license proliferation as people make minor changes to the MPL to apply it to their software. But those considerations aren't ones that make a difference for DFSG-freeness. Cheers, aj signature.asc Description: Digital signature
Re: Why is firebird in Debian?
On Wed, Jul 18, 2007 at 11:58:09PM +0200, Francesco Poli wrote: It is my opinion that the MPL license fails to meet the DFSG. This opinion seems to be shared by other debian-legal regulars: The MPL is an accepted license for main. I'm sorry your opinion differs, and that the views of other non-DDs and non-maintainers on the matter have gone uncorrected and left the misleading impression that there's any question as to whether the MPL is suitable for main. Cheers, aj signature.asc Description: Digital signature
Re: Bacula and OpenSSL
On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote: === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. OpenSSL certainly accompanies genuinely fundamental components of the system; it's status in Debian is that it's as fundamental as apt, and significantly more fundamental than any windowing system, which is explicitly listed as an example of a fundamental component in the GPLv3. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), The definition of the required priority is the minimal set of packages that are required for a system to be administered using dpkg. That excludes, for instance, gcc, not to mention window managers and even all our kernel packages. there are only about 350 packages depending on it (as opposed to glibc's 8500), There are apparently 360 packages just on my system which will be removed if I remove openssl, and I only have 1883 installed. On the same system (which is my day to day desktop), removing libx11-6 takes down 610 packages. On a headless server, removing libx11-6 takes down 7 packages, while libssl0.9.8 takes 82 packages with it. and it isn't installed on a base system. The base system is precisely those packages at priority required or important, and includes openssl. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. From what I can see of the GPLv3 text, OpenSSL plainly is a System Library for Debian -- SSL support is a major essential component of the specific operating system, and one that we include on all systems as soon as they're installed before giving users the option of what to install, whether they're building a server, desktop system, embedded target or anything else. It's integrated into the operating system to the level at which basic tools such as curl and wget are configured to rely on it and through those dependencies such as debootstrap (used to install the Debian base system), openoffice.org, gimp, and bzflag; likewise python directly depends on ssl, and hence so do all the python scripts in the archive. It's not essential by the very limited meaning we use for the Essential: yes field in the Packages files, which is to say, if you remove this package, you will not be able to manage your system using dpkg (and indeed that field is used for only a subset of the Priority: required packages, and happens to not be used for glibc), but it's certainly essential by most common usages of the term, and some more general usage of the term is certainly implied by the GPLv3's reference to window managers as essential components. Cheers, aj signature.asc Description: Digital signature
Re: Bug#431883: dcraw license does not give permission to distribute modified versions or source alongside
On Fri, Jul 06, 2007 at 03:45:29AM -0700, Don Armstrong wrote: On Fri, 06 Jul 2007, Steve King wrote: You'll notice that we have no permission to distribute modified versions of dcraw.c as required by the DFSG. I don't agree with you here. It seems to me that we do have permission to distribute modified versions, provided source is included. The license does not explicitely grant the ability to create a derivative work and distribute that work. It merely talks about lawfully redistributing this code. Since it fails to specifically grant that right, we must assume that the default state (All rights reserved) applies. That's not true. It *might* be a good idea to assume it, but given the intention is perfectly clear, it's certainly not a requirement. It would be better if the intention were explicitly written out (ie, You may distribute and modify provided you do such and such) rather than implied (You must do such and such if you redistribute), of course. Cheers, aj signature.asc Description: Digital signature
Re: Final text of GPL v3
On Sun, Jul 01, 2007 at 11:20:25AM -0400, Benj. Mako Hill wrote: quote who=Steve Langasek date=Sat, Jun 30, 2007 at 03:06:45PM -0700 I'm no fan of Affero, but permitting linking with it is certainly not a DFSG issue. The new Affero is *much* better than the old Affero IMHO. Ha, speaking on behalf of your new paymasters already, I see! ;) If you have a problem with what it's trying to do, you won't like it (the goal is unchanged). If you have a problem with how it did it (the position that I, and most commenters on earlier drafts) were in, you will probably be much happier. In any case, a new version of the AGPLv3 draft is due up soon. Please look at the old one and comment on the new one when it's up. Will it have an actual diff against GPLv3? I get the impression it's meant to be GPLv3 with minor changes to achieve that goal, but actually seeing if there are just minor changes or other things as well was hard when the first draft came out. Cheers, aj signature.asc Description: Digital signature
Re: LGPL v3 compatibilty
On Sun, Jul 01, 2007 at 04:38:56PM +0200, Francesco Poli wrote: On Sun, 1 Jul 2007 13:58:08 +0200 Andreas Metzler wrote: LGPLv3 libraries could not be used in GPLv2-only programs. I'm afraid that this incompatibility is still true. AFAIUI, when you redistribute a GPLv2-only program in compiled form, the GPLv2 insists that the libraries the program links with (excluding system libraries...) are available under GPLv2. It excludes system libraries that are shipped with the application though. Since Debian ships everything together in main, we haven't been able to make use of that exception with GPLv2. [0] The GPLv3's system libraries extension is broader, and covers at least libc, which is 95% of the problem. So while there's a problem for us in linking GPLv2 stuff against non-GPLv2 compatible system libraries (like OpenSolaris's libc), there's no problem for us linking GPLv3 stuff against non-GPLv3 compatible system libraries. But for GPLv2 only apps, the same argument that stops us linking them to OpenSolaris/CDDL libc applies to LGPLv3 libc too, which will presumably include GNU libc very soon, if it doesn't already. All this, assuming that the FSF's legal theory of linking is correct: this theory has never been tested in court, AFAIK, hence we do not know if it would hold. However, we have to assume that it's correct, to be on the safe side. We've assumed that for three main reasons, I think: (1) assuming otherwise would seem like disagreeing with the GPL, and even if that's legally supportable, we'd rather support the GPL (2) supporting that interpretation seems legally plausible, and is simpler to deal with than trying to draw a different line between static and dynamic linking (3) the more strongly viral the GPL is treated, the more effective it is as a copyleft license, promoting the freedoms and such that we've stood for By we, I mean Debian, in particular per discussions on debian-legal and other lists that've influenced/decided ftpmaster policy. Eben Moglen's (reportedly) claimed otherwise since at least the start of the GPLv3 drafting [1]: ] During the discussion[1], Eben Moglen took special care to assert ] that he always believed the GPL v2 should be interpreted in the way ] GPL v3 now makes explicit - it was never the intent to prevent ] aggregation of otherwise unrelated code because of the GPL being ] triggered just because a system function or C runtime was invoked. I ] found that clarification especially valuable. which makes sense, and probably does away with the first concern (if the FSF doesn't agree with interpreting the GPLv2 that strongly, there's not a lot of point to us doing so, particularly when GPLv3 can't be interpreted that strongly), and the second as well (it's much less legally plausible if the FSF disavow the interpretation, and the line we'd have to draw is one we need to draw for GPLv3 anyway). The third point might still be an issue, but that's about it. Playing it safe about respecting the wishes of GPLv2 authors is definitely a concern, but I think the three issues above have always decided the matter before that's actually come up. I believe Sam's currently waiting on a response from the FSF licensing folks to get a first hand take on the FSF's position that we've only had third hand via posts paraphrasing Eben up 'til now. Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Cheers, aj [0] Other people who've distributed KDE separately to Debian, otoh, have been able to (IMO) fairly reasonably claim that Qt under the QPL was a system library for Debian systems, and thus make use of the exception to distribute GPLed KDE binaries. [1] http://www.opensolaris.org/jive/thread.jspa?messageID=21134#21134 signature.asc Description: Digital signature
Re: Final text of GPL v3
On Sat, Jun 30, 2007 at 06:56:44PM +0200, Francesco Poli wrote: On Sat, 30 Jun 2007 16:31:29 +0100 Anthony Towns wrote: [...] Francesco is not a lawyer, I *explicitly* wrote this disclaimer in my comment message (The usual disclaimers: IANAL, IANADD.): Uh, no, you didn't: http://lists.debian.org/debian-legal/2007/06/msg00271.html I don't know why people make such a fuss out of someone pointing out a fact that they themselves acknowledge elsewhere. Cheers, aj signature.asc Description: Digital signature
Re: Final text of GPL v3
On Sun, Jul 01, 2007 at 10:50:22AM -0700, Steve Langasek wrote: Um, no. You shouldn't have used GPLv3 doesn't have any legal force to resolve the inconsistency. If I license my work under the GPLv3, I *as the copyright holder* can still modify the terms of my code's license [...] Well, the GPLv3 text itself is licensed under the terms Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed., so if your license is going to include the rest of the GPL, it's going to include the bit that says ignoring restrictions is okay. If I go to the effort of writing This program is Free Software: you can redistribute it and/or modify it under the terms of the GNU General Public License version 3 as published by the Free Software Foundation, with the exception that the prohibition in section 7 of the license on additional restrictions does not apply and the permission in section 13 is not granted. then I have *explicitly addressed* the clause in GPLv3 which purports to prohibit additional restrictions. Which statement is going to take precedence? At best I've created a lawyer bomb because my intentions are not clear; So I'd say that is, in fact, the best you can hope for -- and if you've made the licensing terms fairly deliberately ambiguous, I wouldn't bet on you being able to enforce your can't link with AGPLv3 requirement, even if I wouldn't bet on you not being able to enforce it. I'd be reluctant to accept something that deliberately ambiguous into the archive, even though either outcome was DFSG-free. at worst I've succeeded in licensing my code in a manner that's incompatible with the GPLv3. But that's exactly the same problem that we had with GPLv2, so what was the point of adding this clause? Presumably the idea is to discourage licensing proliferation by making it hard to extend the GPL in incompatible ways -- perhaps not impossible, but definitely harder than it would be without that clause. Cheers, aj signature.asc Description: Digital signature
Re: LGPL v3 compatibilty
On Mon, Jul 02, 2007 at 07:52:03PM +0200, Francesco Poli wrote: On Mon, 2 Jul 2007 12:31:13 -0400 Anthony Towns wrote: [...] Note that _if_ we do stick to the view we've taken up until now, when we have a LGPLv3 only glibc in the archive, we'll no longer be able to distribute GPLv2-only compiled executables. Unless the GPLv2-only work copyright holder(s) add(s) a special exception, similar to the one needed to link with the OpenSSL library, right? Well, that's always an option, but where the gpl v2 app can get an exception added, it can also be relicensed under gpl v3 too. Presumably we have a few gpl v2 apps where thast's not going to be an option. On the other hand, supposing we find a different view that allows GPLv2 apps to make use of the system library exception to link to a hypothetical LGPLv3 glibc. Then we'll have decided there's /a/ way of distributing a library in Debian (anything that is normally distributed with the major components of the operating system) and an executable that links to that library in Debian, without that component [the library] itself accompan[ying] the executable. Some possible ways to draw that line might be: - as long as the executable only uses bog standard functions from the library (eg, ANSI C standard functions, but not GNU extensions) it's okay - as long as the lib is priority: standard or higher, and the executable is optional or extra, it's ok - as long as the lib is in main, and the executable isn't in main, it's ok - as long as the lib and the executable is in different .debs, it's ok - that clause doesn't hold any meaning or validity at all anymore, so it's ok in all circumstances, as long as the library is in main I would expect the first interpretation there isn't actually useful, but all the others that I can come up with would not only allow GPLv2 apps to use an LGPLv3 glibc, it'd also allow them to link to a CDDL'ed libc (OpenSolaris), a GPLv3'ed libgnutls, or OpenSSL... If we can avoid the accompanying the executable clause in some way as Nexenta have done, with the FSF's apparent blessing, and interpret normally distributed with the major components of the operating system to cover everything in main, that means we can use the system library exemption in the GPLv2 to link GPLv2 software to _any_ DFSG-free library. [0] For GPLv3, the same argument is easier, in that the accompanying the executable clause disappears, but also harder because the other text changes a bit. We'd need for the random non-GPLv3 compatible library to be a System Library as defined by: ] The System Libraries of an executable work include anything, other than ] the work as a whole, that (a) is included in the normal form of packaging ] a Major Component, but which is not part of that Major Component, and (b) ] serves only to enable use of the work with that Major Component, or to ] implement a Standard Interface for which an implementation is available ] to the public in source code form. A Major Component, in this context, ] means a major essential component (kernel, window system, and so on) of ] the specific operating system (if any) on which the executable work runs, ] or a compiler used to produce the work, or an object code interpreter ] used to run it. So for libssl to be covered in the System Libraries of a GPLv3ed executable work, it needs to: 1) be other than the work as a whole 2) be included in the nromal form of packaging a Major Component 3) not be that Major Component 4a) serve only to enable use of the work with that Major Component; or 4b) implement a Standard Interface for which there is an open source implementation If we define it as openssl.h, and the Major Component as libssl, then (1), (2), (3), and (4b) seem satisfied to me, with (4a) satisfied as well, unless I'm misunderstanding that subclause. For libssl to be a Major Component, then libssl has to be: 1a) as major and essential a component of Debian as a window system; or 1b) a compiler used to produce the work; or 1c) an object code interpreter used to run the work (1b) and (1c) aren't satisfied, but (1a) is, afaics -- libssl is far more major and essential than X on Debian, afaics. I would expect (1a) to be satisfied for a lot of significant libraries in Debian, such as anything of standard priority or higher, but not all libraries in optional or extra. Cheers, aj [0] That would only work for us because we're making a universal operating system. It would be difficult to make quite the same argument for Ubuntu, because libraries in universe are distributed separately from the major components of the operating system (ie, Ubuntu's main component). signature.asc Description: Digital signature
Re: Final text of GPL v3
On Sat, Jun 30, 2007 at 12:47:59AM +0200, Francesco Poli wrote: GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 1. Source Code. The System Libraries of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The Corresponding Source for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. 6. Conveying Non-Source Forms. A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. Suppose you want to use some other software that you don't have rights to distribute under the GPLv3 in your GPLv3 app. If you distribute your app in binary form, you need to distribute the corresponding source. You can exclude the other component if it's: (a) it's a System Library (b) (1) a general-purpose tool or a generally available free program; (2) used unmodified; (3) not part of the work; (4) not specifically designed to be required by the work, such as by intimate data communication or control flow The System Library exception only allows you to include interface definitions to Major Components, afaics, because the exception is limited to: (a1) stuff that's included with a Major Component, namely (a1x) a major essential component of the operating system (eg kernel, window system); or (a1y) a compiler for the language used in the work; or (a1z) an interpretor for the bytecode used in the work (a2) stuff that's not part of that Major Component (a3x) stuff that serves only to enable use of the work with that Major Component; or (a3y) stuff that implements a Standard Interface for which an open source implementation is publicly available In particular, both (b3) and (a2) rule out static linking afaics, because neither exception allows you to exclude the source code to a module you're actually distributing, and dynamic linking is only allowed if you exclude the interface definition by (a2) and ignore the library itself because there isn't any combined/derived work from the library itself except a transient one created in memory by the end user. It seems to me, that's taking the view that the only legally justifiable way of relating copyright licensing with linking is direct incorporation, either by static linking or inclusion of a header file. That seems a much more defensible view than the one that, aiui, we'd been using for GPLv2, which was, aiui: static linking creates a combined work that's easily understandable by copyright; dynamic linking achieves the same end result, so should be treated the same way legally no matter what the mechanics of the situation are. In particular, if you have ./foo linked to libbar (where foo.c #includes bar.h and bar is a Major Component), then to be able to distribute ./foo, you need to also distribute foo.c (as the Corresponding Source), claim an System Library exception for bar.h, and not need to distribute libbar (or bar.c which you don't even have) because it's _not_ part of the corresponding source, ie, it's not part of the source code needed to generate, install, and (for an executable work) run the object code and to modify the work If we take the view that seems to be embodied in the GPLv3 that only interface definitions count, that in turn means that the only thing you need in order to link GPL software to a GPL-incompatible library is a GPL (compatible) header file (and to avoid having intimate data communication or
Re: Final text of GPL v3
On Mon, Jul 02, 2007 at 06:25:57PM -0400, Anthony Towns wrote: The System Libraries of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A Major Component, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. This was different in draft 2, which said: ] The System Libraries of an executable work include every subunit ] such that (a) the identical subunit is normally included as an adjunct ] in the distribution of either a major essential component (kernel, ] window system, and so on) of the specific operating system (if any) ] on which the object code runs, or a compiler used to produce the object ] code, or an object code interpreter used to run it, and (b) the subunit ] (aside from possible incidental extensions) serves only to enable use ] of the work with that system component or compiler or interpreter, or to ] implement a widely used or standard interface for which an implementation ] is available to the public in source code form. In that, the subunit is: - something joined to a major essential component of the operating system, but not an essential part of it - something that does nothing more than enable use of the work with that component, or implements a widely used or standard interface Draft 1, in turn, said: ] As a special exception, the Complete Corresponding Source Code need not ] include a particular subunit if (a) the identical subunit is normally ] included as an adjunct in the distribution of either a major essential ] component (kernel, window system, and so on) of the operating system on ] which the executable runs or a compiler used to produce the executable or ] an object code interpreter used to run it, and (b) the subunit (aside from ] possible incidental extensions) serves only to enable use of the work with ] that system component or compiler or interpreter, or to implement a widely ] used or standard interface, the implementation of which requires no patent ] license not already generally available for software under this License. which again distinguishes things that get an exception from the actual major essential components of the operating system. The rationale for this for draft 1 was: ] The final paragraph of section 1 revises the exception to the source ] code distribution requirement in GPLv2 that we have sometimes called ] the system library exception. This exception has been read to prohibit ] certain distribution arrangements that we consider reasonable and have ] not sought to prevent, such as distribution of gcc linked with a non-free ] C library that is included as part of a larger non-free system. This ] is not to say that such non-free libraries are legitimate; rather, ] preventing free software from linking with these libraries would hurt ] free software more than it would hurt proprietary software. ] ] As revised, the exception has two parts. Part (a) rewords the ] GPLv2 exception for clarity but also removes the words ``unless that ] component itself accompanies the executable.'' By itself, (a) would be ] too permissive, allowing distributors to evade their responsibilities ] under the GPL. We have therefore added part (b) to specify when a ] system library that is an adjunct of a major essential operating system ] component, compiler, or interpreter does not trigger the requirement to ] distribute source code. The more low-level the functionality provided ] by the library, the more likely it is to be qualified for this exception. -- http://gplv3.fsf.org/gpl-rationale-2006-01-16.html Sadly the sentence beginning We have therefore added part (b) ... doesn't make any more sense to me than the GPLv3 legalese anyway. Cheers, aj signature.asc Description: Digital signature
Re: Final text of GPL v3
On Sat, Jun 30, 2007 at 10:16:07AM +0200, Francesco Poli wrote: On Sat, 30 Jun 2007 02:35:42 +0100 Iain Nicol wrote: Concerning section 5d of the final text of the GPL 3: Francesco Poli worries: It mandates a feature that I *must* implement in *any* interactive interface of my modified work. [...] it seems that when a non-interactive work is modified so that it becomes an interactive work, the modifier is *compelled* to implement these features in *any* newly created interactive interface. Could this requirement be interpreted more liberally? I wish it could, but I am afraid it cannot... :-( Francesco is not a lawyer, that isn't legal advice, it's almost certainly not based on legal advice, and those sorts of questions should be discussed with either the copyright holder of the work you want to modify or a lawyer if you want an answer you can actually use. Personally, I think you'll have plenty of luck avoiding the requirement if you talk to upstream authors about it (with the possible exception of the FSF) who can give you permission in addition to the GPL, and not much luck if you talk to lawyers about reading it more liberally in general. But YMMV and more importantly your lawyer's mileage may vary. Cheers, aj signature.asc Description: Digital signature
Re: DPL's view of debian-legal (was: Debian Trademarks Summary)
On Wed, Jun 27, 2007 at 05:38:20PM +0100, Anthony Towns wrote: On Wed, Jun 27, 2007 at 09:59:50AM +0100, MJ Ray wrote: I think the Anthony Towns DPLship was not a fun time for those trying to fix legal bugs and it should have been ended sooner. You know, beyond the initial offensiveness, this is actually a pretty remarkable statement. In 2006, we had: - a resolution on the DFSG-free status of the GFDL - a resolution of the licensing problems preventing us from distributing Java at all, including, eventually, legal advice via SPI to that effect - DFSG-free updates to creative commons licenses - new draft of the GFDL resolving Debian's other concerns - a resolution on how we approach sourceless firmware - Java licensed under the GPL - a recommendation to SPI on a free copyright license and more free trademark handling for our logos that's since been acted on, and is now just pending an announcement by the DPL All of those have been causing problems for Debian users for years; if you don't find getting actual solutions to those sorts of legal issues fun, maybe you're in the wrong business. Cheers, aj signature.asc Description: Digital signature
Re: DPL's view of debian-legal (was: Debian Trademarks Summary)
On Wed, Jun 27, 2007 at 09:59:50AM +0100, MJ Ray wrote: Anthony Towns [EMAIL PROTECTED] wrote: [...] but when either group purports to be stating official Debian policy, or starts attacking the people who do make such policy, that becomes actively harmful to the purpose of this list and the goals of the project. But, despite writing that lists can't be assigned blame, here we go again! The *group* attacks the policy-makers, does it? I'm sorry, it would have been more correct to have written members of either group purport to be stating official Debian policy, or start attacking the people who do make such policy, and treating their membership in the group as sufficient qualification to be issuing authoritative statements on behalf of the project, it becomes actively harmful to the purposes of this list and the goals of the project. I think the Anthony Towns DPLship was not a fun time for those trying to fix legal bugs and it should have been ended sooner. I think MJ Ray's contributions to -legal and SPI actively discourage other people from contributing, and that effect is probably more harmful to the goals of the project than his contributions are beneficial. Gosh, what fun it is to trade pointless insults on a mailing list. The most significant progress seemed to be the delegation of trademark and copyright instruction to Branden Robinson (which I linked in the summary), but then those things seemed to return to DPL control again somehow. Unfortunately Branden didn't do anything following the initial draft of the wiki page, so I continued the work from there, as is recorded in the video of the lca miniconf and mails to the -project list. This was, of course, more than you ever did to help define a trademark policy, which consisted of complaining that nobody was doing anything, then not providing any support when anyone was doing anything. Cheers, aj signature.asc Description: Digital signature
Re: DPL's view of debian-legal (was: Debian Trademarks Summary)
On Sun, Jun 24, 2007 at 09:47:34AM +1000, Ben Finney wrote: Anthony Towns [EMAIL PROTECTED] writes: It's likewise nice to see we're back to -legal not being a mailing list, but an unconstituted advisory body that manages to be a responsible body, somehow. Yeesh. The distinction above is clearly being made for sarcastic purpose. I still don't understand it, though. Can you please, as DPL, explain what point is being made here? Outside the context of this discussion about trademarks. What do *you*, as DPL, think debian-legal should be, and how is it currently different to that ideal? I'm not DPL any more, but fortunately I've responded to that in the past, including while DPL: ] [...] debian-legal is a useful source of advice, not a ] decision making body. That's precisely as it should be, since there ] is absolutely no accountability for anyone on debian-legal -- anyone, ] developer or not, who agrees with the social contract or not, can reply ] to queries raised on this list with their own opinion. If people have ] weighed the costs and benefits of contacting -legal and decided not to, ] that's entirely their choice. -- http://lists.debian.org/debian-devel/2006/06/msg00286.html -legal is a mailing list; it doesn't have opinions or any authority, and hasn't any form of formal delegation or membership, and as a consequence has no accountability. It can't be assigned blame for anything, because it's not an entity with any responsibility or accountability. What it does have is a bunch of intelligent involved people who're willing to spend their time offering useful advice. Which is great -- but advice isn't the same as answers or decisions, and in the context of -legal it's often mistaken for that. The SPI trademarks committee has similar issues, in that it's membership is defined as whoever's subscribed to the mailing list [0] and a lack of any ability to do anything more than propose new policy for other people to review. Again, in so far as both groups are only offering advice and suggestions, that's fine -- but when either group purports to be stating official Debian policy, or starts attacking the people who do make such policy, that becomes actively harmful to the purpose of this list and the goals of the project. Cheers, aj [0] http://www.spi-inc.org/secretary/committees.html signature.asc Description: Digital signature
Re: Debian Trademarks Summary
On Sat, Jun 23, 2007 at 12:48:26AM +0100, MJ Ray wrote: http://people.debian.org/~mjr/legal/trademarks.html ] Just to be clear, the two debian logos are currently under the restrictive ] copyright licences described on http://www.debian.org/logos/ (set by ] votes in 1999) and not currently suitable for inclusion in the debian ] operating system, but the project is currently in the process of changing ] this. I expect an announcement from SPI soon. That's no longer the case; both logos are now available under the MIT license, however a public announcement hasn't been made pending some details. ] Personally, I'm not surprised that there was not much progress on ] our trademark during 2006-2007, with a Debian Project Leader who writes ] utter rubbish like The DFSG [...] doesn't cover patents or trademarks ] but maybe we can get moving again now, and make debian more fun by ] fixing this mess at long last, instead of it being thrown up over our ] shoes each time we complain about someone else using trademarks to ] obstruct free software. Yes, clearly no progress was made, and certainly all the progress that wasn't made was in spite of anything I might have done. http://lists.debian.org/debian-project/2007/02/msg00019.html * there's a draft trademark license that we've been waiting for the project to do something with it for many months (mentioned on-list Sep 2005 and on planet May 2006 AFAICT), so please don't blame -legal or SPI for our delays. It's likewise nice to see we're back to -legal not being a mailing list, but an unconstituted advisory body that manages to be a responsible body, somehow. Yeesh. Cheers, aj signature.asc Description: Digital signature
Re: License discussions in Debian (was: discussion with the FSF: GPLv3, GFDL, Nexenta)
On Mon, Jun 04, 2007 at 11:08:39PM +0200, Frank K?ster wrote: Anthony Towns [EMAIL PROTECTED] wrote: See, given that as an ftpmaster I'm one of the folks who actually implements the policy on what's accepted into main or not, it's not my loss at all. I think that Debian would very much benefit if there was a place (call it [EMAIL PROTECTED] or whatever) where our policy with regard to individual software's licenes could be discussed with the input of those who actually set this policy: the ftpmasters. Yes, that's the main reason for my involvement in this thread. Though it's not just ftpmasters, it's Debian developers in general; so that we don't end up with a consensus on debian-legal (or in ftpmaster) that doesn't match the views of Debian as a whole. AFAICS, that means welcoming developers who don't know the difference between subpoena and summons, not using it as a reason to ignore them completely. If debian-legal isn't the place for you (and AFAIK none of the other ftpmasters is a regular), maybe we need a new start and a different format. I used to be a regular on -legal, and I'm still subscribed. My views (such as people who aren't speaking on behalf of the project shouldn't make it sound like they are...) don't seem particularly welcome though, so I tend not to bother. I don't see any particular reason to think a new start or format would help much, but I'm open to suggestions. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Tue, Jun 05, 2007 at 02:09:06AM -0700, Steve Langasek wrote: Why doesn't it matter? If I've been sued because of something I've actually done that infringed the license, then surely the DFSG and Debian shouldn't be concerned with that (other than the question of whether what I've done is something that the DFSG requires of copyright holders); but if I'm being sued over something I *didn't* do, [...] If you're going to be sued for something you didn't do, and lose because in your absence you're assumed to have done it, why not go the whole hog and just have them assert you've used/distributed a program you've never actually used/distributed? AFAICS this is an issue only when there's a not completely trivial possibility that you have actually violated the license. - If I don't have the resources to fight the case in a court overseas, I risk summary judgement; the cost to me is the liberty to travel unmolested to Australia at some future date when I might have resources for travel. Speaking of which, the linux.conf.au 2008 CFP is open: http://linux.conf.au/presentations I suspect that anyone who can get their paper accepted will be able to get their travel costs covered by one of LCA, Debian or the Linux Foundation. (Kickass segues 'r' us) * If I get sued in Oregon, I have a wide range of local resources at my disposal to help me find appropriate legal representation; if I get sued in Australia, I'm stretching my connections pretty thin to find and evaluate legal counsel, and this process is going to cost more time and money on my part (and may leave me with inferior legal counsel anyway in the end due to logistical issues) For Australia, assuming you were being sued over free software stuff that you'd be doing in good faith, I think we could do a fairly good job helping you out. * Effective realtime communication with the lawyer is more expensive (transoceanic phone calls), and more inconvenient due to timezone differences (fine, fine, not for *me*, but you know what I mean) Yes, Australian lawyers seem to be in a very inconvenient timezone for me... ;) As an analogy, suppose that a license included the following clause: By distributing the covered work, you agree that the copyright holder can compel you at any time to play in an on-line black jack tournament at his website, geekblackjackstars.net, with an initial ante of $100. Should Debian consider this to be a free license because the clause won't necessarily be invoked and because some people win at blackjack? Clearly not. BTW, that site doesn't seem to exist. The difference between blackjack and choice of venue is that in one case you're being compelled to do something, and in the other you're pre-determining an argument. AFAICS that breaks that analogy. Two different analogous licenses might be: By distributing the covered work, you agree that the copyright holder can sue you for violations of the license. If you distribute the covered work, the licensor agrees not to sue you in any jurisdiction other than Berlin, Germany. I'd consider both those to be clearly free. Choice of venue goes beyond either of them, certainly. But I'm still not seeing a way in which it goes so far beyond them as to become non-free. Heck, is choice of venue actually different to the combination of those clauses? Simon Phipps' argument, presented at debconf last year, is (aiui) that the clause only comes into play when both parties are organisations that cross multiple jurisdictions anyway -- in which case they're both presumed to have a presence in the given jurisdiction anyway, and could reasonably be expected to be following its rules, afaics. Has this opinion been confirmed by a lawyer on *SPI's* payroll, not just by one on *Sun's* payroll? :) TTBOMK, no. ITYM acting on behalf of SPI rather than on SPI's payroll btw. :) [...] The current clause, though, puts the copyright holder in the dealer's seat, and the house always wins. Well, that's only true over the long term, and I don't think it's necessarily true even over the long term for court cases. Cheers, aj signature.asc Description: Digital signature
Re: License discussions in Debian
On Tue, Jun 05, 2007 at 09:08:31AM +0200, Frank K?ster wrote: That's true, as an ideal. In reality, you can't expect every DD or even maintainer to subscribe to -legal except when they've got a particular problem to discuss. Sure, but you don't need or want that. All you need is an unbiassed sampling of developers to participate, which is to say the list needs to be just as open to extremist opinions from people who think the GFDL is completely free as people who think the GPL is actually non-free. AFAICS the only way that's going to happen is by taking the view that Debian's definition of free as per the DFSG-free is just one view you can take, and that people who take alternative views -- whether stricter or more liberal, whether focussed on legal details or ignorant of them in favour of just doing stuff -- are still worth listening to, even though their views on what's free or not may well be fundamentally different to Debian's. If the only question is is this free or not? then you're going to get turf wars because there's just no middle ground, and whoever gets to make that decision controls the debate. Even just having analyses take the form of these are the consequences, personally I'd avoid them, though Debian doesn't think the problem's a big enough deal to worry about; Don agrees with me, but Francesco doesn't seems like it'd be most of the way there. But as it stands, -legal's analysis seems to me more to fit the mold of this is conceivably bad in some circumstances, not the same as anything in any good licenses, therefore it's non-free, and that's all there is to it. I'm not sure, however, that this is the general attitude on -legal: I've never encountered it. Take Don and Jordi G. H.'s exchange this month: ] If you disagree with the determination of the Developers, you can ] easily install the work from non-free, or cease supporting Debian in ] its entirety. The choice is yours, really. ] ] Our way or the highway isn't a nice thought either. Do you really ] think that the DDs that voted against putting the GFDL in non-free ] should fork off too? Debian is the best distro out there, and I'm very ] loyal to it, but I'malso very unhappy with its treatement of the ] GFDL, and I think this horrible mess should be fixed. And no, to be fair, skimming the archives does indicate it's not the general attitude at all, and I'm also pleased to have stumbled across an example of Michael Poole noting he's not a lawyer or DD while giving his thoughts/advice. Equally, if -legal were working 100% how I wanted it to, that'd just mean I'd be happy to trust it implicitly and wouldn't pay any attention to it at all; which probably means that the times I do pay attention now are the times it's going (imo) severely wrong, which is going to produce a pretty biassed view on my behalf. Comparing Ted Tso's and Thomas Bushnell's views, as cited on LWN some time ago [0] is probably a good reference point too. Having disagreements like the current one over choice of venue be escalated into claims that are one set of DDs are trying to prov[e] they are Holier Than Stallman, or another are sell[ing] out [freedom] isn't very helpful if we want the DFSG to be useful at helping upstreams and users. In *my* opinion, and ymmv etc, analysing licenses so that we can say: * These are almost certainly the effects, which barely anyone disagrees with (GPL is viral, CDDL is viral and GPL incompatible, QPL requires modifications to be made as patches) * These are things that might not happen, but that you might be concerned at (GFDL stuff can't be encrypted, or even have Unix permission bits set? CDDL leaves you vulnerable to nuisance suits in foreign countries) * These are ways you can avoid some of the drawbacks (use MIT instead of the old BSD license, explicitly limit when choice of venue comes into play) * Different people and organisations may reasonably have different views on the acceptability of various effects -- the FSF view the Affero GPL and GFDL as free, OSI views the APSL as free; and you may want to make a different choice to any or all of those organisations. Debian's choices are focussed on ensuring we can develop and distribute a high quality operating system that works for our users. This may mean we'll accept some licenses that aren't as free as we'd like them to be, in some cases (such as licenses with patch clauses, or obnoxious advertising clauses, etc). From what I've seen, debian-legal isn't very good at accepting anything less free than it'd like. Which is pretty understandable, but not really helpful either in advocating Debian's views (which are more accepting), or in working with other groups (upstream or down) who don't have the patience for endless nitpicking. It could also be a lot better
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 07:55:18PM +0200, Francesco Poli wrote: On Mon, 4 Jun 2007 19:30:36 +1000 Anthony Towns wrote: And I mean, I know what a GR is for, why are you telling me? It's still not a *good solution* for deciding these things; it's a last resort, and the only other options we currently have a ftpmaster decides and it's obvious to pretty much everybody. I'm rather surprised to hear you saying that, since you seem to have been the proposer of GR-2006-001... Sometimes you have to choose the best of a lot of bad options. When that happens, it's often good to spend some time trying to get better options for the future. [...] The official position of Debian is what we allow in main. That is to say? Bugs never happen?!? Nothing can possibly enter main by mistake or overlook?!? Of course it can -- official positions can be wrong, can be made by mistake or without due care, and can be changed. [...] Unfortunately, since -legal in general becomes an amorphous set of individuals who reserve the right to hold whatever opinions they like whenever questioned, there's little hope of -legal ever learning from its mistakes. Are you going to call the orwellian thought police, since I hold my *own* opinions?!? You don't need to call the thought police, you only have to think of them and they'll know to come! Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
The debian-legal checklist: On Sun, Jun 03, 2007 at 11:28:22AM -0400, Michael Poole wrote: Posted by a non-DD, non-maintainer and non-applicant: Check. Anthony Towns writes: [...] And as far as the actual effects go, I'm not sure you're going to be any better off without that clause in your license: if you set foot in Australia, with an Australian judgement against you, there's a good chance of it being enforced; and if you don't, there seems to be a practical possibility of your extradition anyway, based on [0]. Extradition is for criminal cases, not civil cases. I cannot imagine how a choice of venue clause would significantly either help or hurt a criminal defendant. Confident assertion of legal facts, with little basis, no references, and without an IANAL disclaimer, or I am a lawyer and this is legal advice, or a I am a lawyer but this does not constitute legal advice: Check Since copyright is increasingly covered by criminal penalties (in at least Australia and the US) as well as civil ones, I don't think that dismissal is even particularly useful. As has been previously discussed on -legal -- several times, I might add -- there are a variety of reasons that the rest your argument is flawed. Condescending dismissal of arguments: Check. To summarize: Most of the expense of non-local defense litigation is in advance of any court judgment on the merits. The cost to dismiss a lawsuit for lack of personal jurisdiction is an order of magnitude (or more) less than litigating it through trial. It is harder to set aside a default judgment than to dismiss a complaint for improper venue. Confident assertion of legal facts, [...]: Check. In the example Don presented, of the Debian star maintainer removing some output from the Debian star package, that the star upstream claims constitutes a copyright notice, then there are the following options: 1. avoid the conflict by removing star from Debian 2. avoid the conflict by replacing the output at upstream's request 3. dispute the claim that they're copyright notices and keep acting At this point upstream likewise has some choices -- ignore the (perceived) license violation, sue in the court that's most convenient for them, or sue in the court that's most likely to act against you. If they ignore the violation, then that's where it ends. If they sue in the court that's convenient for them, then: 4. they need to demonstrate jurisdiction (which should be relatively easy even without a choice of venue clause, because Debian operates globally anyway: in the Berlin case ffis would be a potential target, I'd imagine) 5. they'd need to subpoena the respondent (ffis, pavel, SPI, whoever) following usual procedures 6. they'd need to convince the judge that the case is worth hearing and that they're correct At step (3) we've already decided upon a response to the claims, which we could file either with representation or by post at point (6). If those comments are dismissed by the judge and we're ruled against, we have another choice: 7. we can accept the ruling that we're violating the author's copyright, and remove the program or comply with upstream's request 8. we can continue doing things the way we think's appropriate, but not in places where we've been ruled against And if upstream doesn't like that, which they presumably wouldn't, 9. upstream can start asking other jurisdictions to enforce the penalties already indicated And as it happens, all of that applies without a choice of venue clause too, the only option you lose is the chance of dismissing the case on jurisdictional technicalities at point (6). Even if the license provides for recovery of costs and attorneys' fees It does provide for recovery of costs and attorneys' fees. No need to be hypothetical. Those are the costs of a choice-of-venue clause. The (apparently one and only) benefit is that it is cheaper for the licensor to sue people and/or the results of lawsuits are more predictable. The benefit is that it's clearer as to how the license will be enforced. Is it a big benefit? No, probably not. Supposedly Sun have it on their TODO list to remove it, though presumably it's safe to say they've been more focussed on getting Java under GPLv2 and seeing what happens with GPLv3 over the past little while. Is that truly acceptable in a free software license? Is it acceptable that a free software license makes it cheaper for the licensor to sue people, or that the results of lawsuits are more predictable? Of course it is. Is it acceptable that a free software license has drawbacks associated with it for potential licensees? Well that's a no-brainer too: all licenses (with the possible exception of public domain equivalents) have drawbacks of some kind. Cheers, aj signature.asc
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 12:25:41AM -0700, Walter Landry wrote: Non-developer, non-maintainer, non-applicant: Check. Anthony Towns [EMAIL PROTECTED] wrote: For a choice of venue clause though, it only stops some people from being willing to participate; just as potentially giving up patent rights stops Microsoft from being willing to distribute Linux. The requirement to pet a cat, even if it is only required if convenient, also only stops some people from being willing to participate. It has also been considered non-free since the beginning of Debian. Condescending dismissal of arguments: Check. Is it really not obvious why -legal isn't taken very seriously sometimes? I don't consider the venue for deciding conflicts is chosen in advance as remotely equivalent to you must pet a cat. An analogy I would accept is something of the form you don't get to exercise your right/ability to where is an action, not the lack of an action. enforce your patents against other users of this software would be one example, distribute compiled code without source code would be another. If you're claiming you don't get to exercise your right to argue about jurisdiction is equivalent to you must pet a cat, then, IMO, you need to argue the same thing about you don't get to exercise your patent rights. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, Jun 03, 2007 at 11:14:16AM -0700, Don Armstrong wrote: But even so, when you say things like I'm personally more concerned about licensing than the average developer and I [...] expect people who disagree with my analysis to actually engage the analysis with counter arguments, come to a complete understanding of the problem, and then make a determination you are saying your understanding is more important than other people's. No, I'm saying that people who disagree should engage my analysis instead of remaining silent or discarding them with offhand comments. Holding people who agree with you to that standard might be a way to start? If I had time to do so, I'd consider it. Since I don't, I content myself with trying to make sure my messages approach this standard, setting an example instead. Well, when you hold people to different standards based on whether they agree with you or not, you can pretty safely expect that you'll end up with a pretty biassed group. In any event, the important thing (afaics) isn't to have a forum where regulars can post their understanding of issues, it's to help the people you're communicating with have a better appreciation for the complexities involved in their issue and how they might choose to approach them. That can mean pointing out possible drawbacks in existing licenses, explaining tradeoffs between licenses, or suggesting alternative ways of drafting licenses that avoid having to make some tradeoffs, but it doesn't mean making the tradeoffs for other people. Almost all this happens on -legal, actually. That's not my experience. From what I've seen, -legal mostly consists of people who aren't particularly experienced in free software development or professionally trained in any sort of legal analysis making unconditional claims about whether particular clauses are good or bad (mostly the latter) and how they'll be enforced. Obviously (I hope), I don't consider you to be inexperienced in free software development, but just in this thread you've made a reasonable number of unconditional statements, including ones that're simply wrong. I hope you can see why that can be frustrating, and why it can be more annoying when it's done by people whose only contribution to free software seems to be participating on -legal. I've personally been involved in trying to resolve the GFDL issue, making sure that the GPLv3 is DFSG free, and have been working along with Simon and a few others to try to fix the RFC issue. [In the case of the CDDL, it's interesting to note that this very issue was supposedly going to be fixed or at least looked at in an upcomming revision of the CDDL.] Well, the GFDL issues have been going to be fixed for some years now too; which, afaics, means that leaving Debian's interests up to folks on -legal (including yourself in this case) isn't very effective. Maybe it's not possible to be more effective on this score -- I'm not involved enough to say -- but I do know -legal could be a lot more effective in other respect, if it wasn't so insular: ie, less unconditional about what's free and less likely to inflate things that are regarded in the rest of the free software community as a non-issue (or a feature!) into a disaster wrt DFSG-freeness. No, punting to a GR is not a good solution -- it's slow to come to a resolution, it annoys developers who have to inform themselves about something they'd rather not worry about, and it ends up with -legal folks complaining that the resolution doesn't make sense. If it's the case that a signficant proportion of contributors to -legal and Debian Developers feel that an improper decision has been made, there's little else that can be done besides bringing it to a GR. What contributors to -legal feel is irrelevant to the above -- things go to a GR if, and only if, Debian Developers care sufficiently about it. And I mean, I know what a GR is for, why are you telling me? It's still not a *good solution* for deciding these things; it's a last resort, and the only other options we currently have a ftpmaster decides and it's obvious to pretty much everybody. What would make it more welcoming? A large part of the problem is the need to continuously point out counter arguments, [...] What makes it unwelcoming is the appearance of a consensus that doesn't brook argument, even when that consensus differs significantly from that of other sections of the free software (or open source) community. The problem is that it's very difficult to know if the consensus differens from the silent majority because the silent majority is nearly silent. When you're saying a license from the Free Software Foundation is non-free, it's *very easy* to tell you're going against another section of the free software community. We've done that with the Affero General Public License, the GNU Free Documentation License, and there's been the occassional attempt to
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 01:13:44AM -0700, Steve Langasek wrote: It is a freedom that I have by default; if I accept the CDDL I no longer have that freedom[1]. [...] [1] Technically, not the right to choose a venue, but the right to not be sued in a venue where I have no legal presence. Err, that's not a violation of your rights, it's a waste of the court's time... If the court doesn't see it as a waste of its time, and issues you with a summons anyway, you're involved. Cf [0]. You might as well say you've got the right not to be flamed on a list you're not subscribed to. Cheers, aj [0] http://www.time.com/time/nation/article/0,8599,1557842,00.html signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 02:42:24AM -0700, Steve Langasek wrote: On Mon, Jun 04, 2007 at 06:49:54PM +1000, Anthony Towns wrote: If you're claiming you don't get to exercise your right to argue about jurisdiction is equivalent to you must pet a cat, then, IMO, you need to argue the same thing about you don't get to exercise your patent rights. You're aware that most of the people arguing that choice of venue clauses are non-free also hold the opinion that patent non-enforcement as a condition of the copyright license is also non-free? No, not at all. It's been years since I've followed -legal, and I certainly don't keep track of who thinks what. I fundamentally don't think it *matters* what individual subscribers to -legal think. What I care about is having a reasonable, widely understood definition of free software that meshes with the rest of the free software and open source community, that Debian can use to work out what software we'll distribute in main. I don't think it's remotely obvious that the DFSG rules out all patent non-enforcement clauses, I'm pretty sure it's not remotely obvious that the DFSG rules out choice of venue clauses, and so far I haven't seen any real reason why Debian needs to rule out those clauses. I can _certainly_ see why those sort of things might be more of a drawback than a benefit and we might want to discourage their use, but we can say bad in ways other than non-free. Cheers, aj, who suspects he's against patent non-enforcement clauses in the past signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 07:30:36PM +1000, Anthony Towns wrote: Obviously (I hope), I don't consider you to be inexperienced in free software development, [...] To expand on that a bit more: IMHO, Debian is fundamentally about what its contributors want -- we're focussed on doing right by our users and the free software community, but ultimately, as far as Debian's concerned, the first and foremost representatives of both those groups are the users and free software community members who actually make Debian work. The opinions that matters are the ones belonging to people who're actually building Debian; and ultimately legal expertise is kind-of irrelevant to that. Microsoft might have some of the world's best experts on understanding IP law and the effects of the GPL, but as far as Debian's concerned, the newest of new-maintainers and the least contributors to Debian should have infinitely more say in what's sufficiently free for Debian. The point where legal expertise comes in is in understanding the consequences of legal texts -- this clause will prevent development in such-n-such a circumstance, or that clause will prevent distribution under some other conditions; not in deciding whether those circumstances or conditions are enough of a concern to actually make something non-free. Confident statements from non-developers on what is and isn't free enough isn't incredibly good at the best of times, and is actively harmful when it's got a history of not matching the way Debian actually works. And when analysis of licenses tends to amount to not much more than we've discussed this issue already, it's not free there's not much point to the debate at all, afaics. But if no one on -legal sees what I'm trying to get at by now, I guess there's not much point to this debate either. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 04:07:30AM -0700, Steve Langasek wrote: What I care about is having a reasonable, widely understood definition of free software that meshes with the rest of the free software and open source community, that Debian can use to work out what software we'll distribute in main. That's a good goal; but Heh. Now there's a compressible phrase. :) (meshes does not mean matches or includes. When I joined we were more permissive than both the BSD and GNU camps (GNU complained about the BSD license, BSD complained about the GPL, we didn't mind either), but we've never done that blindly, as the KDE, Affero or GFDL stuff should attest. I don't see why you'd expect us to start now) Debian has disagreed with other folks in the past because we believed their interpretations were irrational and contrary to the long-term interests of Free Software, [...] I don't think you'd have to look very hard to find people who consider debian-legal's intepretations of various things to be irrational and contrary to the long-term interests of Free Software. Unfortunately trying to have a discussion between those viewpoints to resolve (or at least clarify) the differences isn't often successful. I've already listed some of the ways I think -legal regulars could change that situation, if they're interested. But I guess ultimately, along with James, Ryan, Joerg and Jeroen, I'm one of fairly few people who really don't have much cause for concern whether -legal becomes a really useful discussion area or not. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, Jun 04, 2007 at 08:27:13AM -0400, Michael Poole wrote: The troll checklist: Heh. Free advice: the best way to deal with trolls is to ignore them. Anthony Towns writes: The debian-legal checklist: On Sun, Jun 03, 2007 at 11:28:22AM -0400, Michael Poole wrote: Posted by a non-DD, non-maintainer and non-applicant: Check. Ad hominem attack: Check. I'm sorry, but I don't get why anyone considers that an ad hominem attack. Confident assertion of legal facts, with little basis, no references, and without an IANAL disclaimer, or I am a lawyer and this is legal advice, or a I am a lawyer but this does not constitute legal advice: Check Blatant and proud ignorance of the field: Check, check and check. (I am not a lawyer. Under US law, [...]) Uh, dude, IANAL is a way of indicating that you may not actually have a clue what you're talking about because it's all just amateur opinions. Once upon a time -legal used to be littered with it; now days the concept that regular posters to -legal might be mistaken seems to be rather alien. As has been previously discussed on -legal -- several times, I might add -- there are a variety of reasons that the rest your argument is flawed. Condescending dismissal of arguments: Check. I was -- and am -- in no mood to repeat the full reasons for these positions for the fourth or fifth time. If you cannot bother to read the archives, that is your loss. See, given that as an ftpmaster I'm one of the folks who actually implements the policy on what's accepted into main or not, it's not my loss at all. 4. they need to demonstrate jurisdiction (which should be relatively easy even without a choice of venue clause, because Debian operates globally anyway: in the Berlin case ffis would be a potential target, I'd imagine) Debian's global activities do not in general affect jurisidiction over individuals, so (4) primarily applies to Debian rather than its developers or end users. The CDDL primarily applies to Debian rather than end-users anyway, being about distribution and development (at least in so far as we distribute CDDL software anyway)... In any event, the example Don raised specifically talked about Debian being the respondent. Nitpick: The plaintiff would need to issue a summons to the defendant. A subpoena is for testimony or other fact discovery[1]. A defendant does not become a respondent until he responds to a particular filing[1]; the plaintiff would usually also be a respondent to certain motions[1]. [1]- Ask Wikipedia, Google, or whatever floats your boat. These are not obscure legal facts or specific instances, they are basic terms. Would you take someone seriously who had strong programming opinions but thought CC was the name of a C compiler or claimed to know the Pearl _scripting_ language? It's interesting that you started the mail offended about the ad hominem attack of noting you're not a developer; yet somehow you think a computer expert who tries to avoid paying attention to legal arguments getting subpoena and summons confused is an ignoramus who shouldn't be taken seriously. And that is exactly an ad hominem fallacy -- attacking the person in order to discredit their arguments, even though the flaws the person may have don't actually affect their argument. The argument which, I'll note that you didn't actually address at all. How many free software licenses have been enforced thanks to choice of venue? It doesn't matter, simplicity isn't a requirement for freeness. Not all drawbacks are shifted costs. The effect of choice of venue is to shift a significant potential cost from the software licensor to the software's users. Disclaimers of warranty and liability do that too. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, Jun 03, 2007 at 04:51:40AM -0700, Steve Langasek wrote: On Sun, Jun 03, 2007 at 12:25:14PM +0200, Wouter Verhelst wrote: Additionally, personally I don't think it's unreasonable for people to say if you use my software in a way that I didn't want you to, I'll sue you in a court that works by a set of rules that I'm actually comfortable with. You know, it makes fighting those who do not follow your license the way you intended them to quite a bit easier. That's a strawman. The objection raised to choice-of-venue clauses is not what they specify to happen when the licensee has *infringed* the license, it's what they specify to happen when the licensee *hasn't* infringed the license but the copyright holder files a lawsuit against them anyway out of malice. I don't think that's meaningful; if I sue you in a court in Australia for not complying with debootstrap's license, and they find that you've infringed the license, it doesn't really matter if I'm doing that out of maliciousness or a genuine. And as far as the actual effects go, I'm not sure you're going to be any better off without that clause in your license: if you set foot in Australia, with an Australian judgement against you, there's a good chance of it being enforced; and if you don't, there seems to be a practical possibility of your extradition anyway, based on [0]. Simon Phipps' argument, presented at debconf last year, is (aiui) that the clause only comes into play when both parties are organisations that cross multiple jurisdictions anyway -- in which case they're both presumed to have a presence in the given jurisdiction anyway, and could reasonably be expected to be following its rules, afaics. [0] http://www.theage.com.au/articles/2007/05/06/1178390140855.html Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sun, Jun 03, 2007 at 12:28:04AM -0700, Don Armstrong wrote: If the author of Star decides that the Debian maintainer has incorrectly removed a copyright notice,[1] he could terminate the license under 6.1, He could claim the license is terminated under 6.1, but presumably the Debian maintainer would dispute such a claim. and bring action in Berlin for copyright infringement; the maintainer and any other parties to the action (people to whom the work was distributed after notification of breech) would then have to defend themselves in Berlin instead of notifying the court that the venue was improper (or whatever the German equivalent is.) The court in Berlin would have to not throw the case out on their own accord (in spite of the difficulty in having your side of the case presented, and in spite of the jurisdictional issues, the questionability of the claim in the first place, and the difficulty in showing harm), rule against you in absentia (agreeing with the arguments presented), and could then only take action in so far you already operate in its sphere of influence, or in so far as it can convince your government to extradite you or enforce its rulings for them. Should someone be willing to do that, and a court is willing to go through all those steps with a choice of venue clause, what makes you think they'd not do so in the absence of one? On Sun, 03 Jun 2007, Anthony Towns wrote: Since this is giving up a right normally enjoyed in exchange for the ability to use or modify a work, it appears be a fee, and as such fails DFSG 1. You're not giving up any rights, you're gaining the right to modify and distribute the software under certain conditions, just as you are under the GPL. We don't give up rights under the GPL that we otherwise enjoy though; Some people do. Microsoft considers the right to enforce its properly obtained patents worth going to the trouble of distributing coupons instead of SuSE itself, eg. we only gain ones in specific circumstances. In the case of the CDDL, we lose rights even in the case where we're only using the work. What makes you think the latter is true? I don't endorse the claim that copyright licenses can take away usage rights if you're not making use of the ability to modify or distribute that they offer you. In some cases it may be enough to provide a simple notice like that to bind a user, but that's dependent on your jurisdiction as a user more than a choice of venue clause, and I can't see any reason to think it applies to the CDDL even so. You're required to give up something you might value and otherwise demand compensation for, certainly, but there needs to be something more than that to violate the DFSG. giving up something that you might value [or] otherwise demand compensation for applies equally well to cash money as it does to any other intangible which has value. A requirement to send an email to the licensor if you possibly can isn't cash money either, but it sure seems to be a fee to me. It's not a fee in the normal sense of the word, but it is a restriction in the sense that if you're not able to do it (and you may well not be able to), you're not able to make use of the priveleges you're offered in return. That's where the analogy to a fee comes in -- it stops some people from being able to participate. For a choice of venue clause though, it only stops some people from being willing to participate; just as potentially giving up patent rights stops Microsoft from being willing to distribute Linux. It's *possible* that it's still obnoxious enough that it's too much to ask, but so far I can't see any significant cost to choice of venue that makes it any worse than all the other weird and wacky things people put in free software licenses. The DFSG are a set of *guidelines*, if you can't explain violations in simple, understandable terms, they're not violations. This is my understanding as well; I'm only explaining the application to DFSG 1 to attempt to appease strict constructionists. The OSI lists are that way: :) I'm personally using feel as shorthand for my understanding of the legal situtation regarding this clause and its relation to the DFSG That's great, but *your understanding* isn't any more important than anyone else's. I'm not claiming that it is; my point is that my understanding is not *less* important than anyone else's. I've done what everyone should do to come to an understanding. I'm glad to see you write that; though I was referring more to Francesco's post and similar than yours. But even so, when you say things like I'm personally more concerned about licensing than the average developer and I [...] expect people who disagree with my analysis to actually engage the analysis with counter arguments, come to a complete understanding of the problem, and then make a determination you are saying your understanding is more important than other people's
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Thu, May 24, 2007 at 10:54:36AM -0700, Don Armstrong wrote: and to the best of my knowledge, works licensed solely under the CDDL have never been accepted in main.[1] star | 1.5a57-1 | oldstable | source, alpha, arm, [...] star | 1.5a67-1 | stable | source, alpha, amd64, [...] http://packages.debian.org/changelogs/pool/main/s/star/star_1.5a57-1/star.copyright http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624 HTH. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
debian-devel re-added. On Sat, Jun 02, 2007 at 03:40:36PM +0200, Francesco Poli wrote: On Sat, 2 Jun 2007 21:50:15 +1000 Anthony Towns wrote: On Thu, May 24, 2007 at 10:54:36AM -0700, Don Armstrong wrote: and to the best of my knowledge, works licensed solely under the CDDL have never been accepted in main.[1] star | 1.5a57-1 | oldstable | source, alpha, arm, [...] star | 1.5a67-1 | stable | source, alpha, amd64, [...] http://packages.debian.org/changelogs/pool/main/s/star/star_1.5a57-1/star.copyright http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624 Quoting from the bug log, Anthony Towns wrote: | The CDDL mightn't be the best license in the world, and isn't GPL | compatible, but it's still DFSG-free. Closing this bug with this | message. I do *not* agree that the CDDL meets the DFSG, especially when a choice of venue is in place. That a poster to debian-legal doesn't think a license meets the DFSG isn't particularly useful information, and is even less so when that poster isn't a DD, a maintainer or someone in the n-m queue. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Sat, Jun 02, 2007 at 11:10:19AM -0400, Michael Poole wrote: Anthony Towns writes: On Sat, Jun 02, 2007 at 03:40:36PM +0200, Francesco Poli wrote: I do *not* agree that the CDDL meets the DFSG, especially when a choice of venue is in place. That a poster to debian-legal doesn't think a license meets the DFSG isn't particularly useful information, and is even less so when that poster isn't a DD, a maintainer or someone in the n-m queue. A blatant appeal to authority in place of facts or analysis isn't particularly useful information, and is even less so when arguments for the contrary position have been made but not answered. On Sat, Jun 02, 2007 at 10:13:56AM -0700, Don Armstrong wrote: It's not like there aren't DDs who feel that it isn't DFSG free; Steve Langasek and myself have consistently argued against it, and I doubt we're the only two. That said, can the ftpmaster who approved the inclusion of star in main speak up and give their rationale? On Sat, Jun 02, 2007 at 08:30:56PM +0200, Bernhard R. Link wrote: Count me in. I don't feel comfortable with choose-of-venue at all. This attitude is exactly why there's a disconnect between regular posters and subscribers to debian-legal and other members of the project. How you feel about a license isn't any more important than the other people's feelings that happen to be opposite to you. The above isn't analysis, it's grandstanding. And if you really want to have licenses determined by how people feel rather than analysing the effects of the license in real world situations as compared to what's actually written in the DFSG, I expect you'll find we just end up with more GRs like the the GFDL GR that doesn't match commonly held opinions on debian-legal at all. If you're a non-DD, non-maintainer, or whatever, and you have new insight to add to license/DFSG analysis, that's great! That's exactly what the list is for. If you just want to post about your opinion on whether we should consider something DFSG-free or not, do it in a way that respects the fact that there are plenty of other contributors to Debian who might happen to hold opinions different to yours. And also realise that the only place your opinion is actually going to have some effect is in packages you maintain, or if we hold a poll or a vote, and posting to -legal isn't participating in either of those. Cheers, aj signature.asc Description: Digital signature
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
as unwelcome by people who hold those views -- I don't see any way of improving things. In particular, whoever ends up responsible for Debian's official policy will need to spend their time educating users on what the official policy actually *is*, not their opinion on what the official policy should have been. To take a particular example: if you want to retain the privelege to call the GFDL vote result wrong, you're excluding yourself from being in a position to define Debian's interpretation of free software. (And it doesn't matter what the outcome of that vote had been -- including if it had been the GFDL is a free license even with invariant section) For reference, ftpmaster's votes on the GFDL resolution were: Option 1-: GFDL-licensed works are unsuitable for main in all cases / Option 2: GFDL-licensed works without unmodifiable sections are free |/ Option 3---: GFDL-licensed works are compatible with the DFSG [needs 3:1] ||/ Option 4--: Further discussion |||/ V: 1--2 troup James Troup V: 1144 ajt Anthony Towns V: -1-2 rmurray Ryan Murray V: 12-3 rdonald Randall Donald V: 1342 joerg Joerg Jaspert V: 1141 jeroen Jeroen van Wolffelaar which would've resulted in Option 1 winning if ftpmaster were the only consideration (AB (3:1), AC (5:0), AD (4:1), BC (5:0), BD (3:2), DC (5:0)). Personally, I think comparing the reactions to getting overruled by GR of ftpmaster members to various subscribers of -legal is probably instructive. YMMV, of course. Cheers, aj signature.asc Description: Digital signature
Re: Debian logos and trademarks
On Wed, Feb 07, 2007 at 11:57:13PM -0800, Don Armstrong wrote: On Thu, 08 Feb 2007, Anthony Towns wrote: The DFSG refers to copyright licensing, it doesn't cover patents or trademarks. It actually doesn't refer to any of them specifically. It does talk about licensing, but it doesn't clarify whether it's refering to copyright licensing or trademark licensing. It talks about modification and distribution, which are copyright issues. In any event, this entire line of argument isn't particularly important, so long as no one puts the official logo into main or contrib. That's a completely new line of argument to the best of my knowledge, and not one which Debian should support, in my opinion. Having a free copyright license, and a reasonably permissive trademark license is sufficient for a name or logo to be in main, cf the terms Gnome, apache, java, or Debian for example. If you want to do an in depth legal/dfsg analysis in response to this, please limit it to -legal; if you want that response to be taken into account, please make it persuasive to people who don't already agree with you -- consider people who hold each of the opinions represented by the GFDL ballot from last year, eg. Please note that historically we've protected both logos (the swirl and the bottle) using a non-free copyright license, and as unregistered trademarks. Cheers, aj signature.asc Description: Digital signature
Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
On Tue, Oct 17, 2006 at 03:49:25PM -0400, Nathanael Nerode wrote: The answer to the question in the subject is simple: NO. Thankyou for your opinion. I note you seemed to neglect to mention that you're not a lawyer. Cheers, aj signature.asc Description: Digital signature
Use of the BTS for freeness/redistributability bugs
Hey all, Scanning through the RC bug list and there seem to be a lot of bugs of the form foo is unsuitable for main because xyzzy license is non-free and foo cannot be redistributed because of barbazquux. I'm inclined to think there should be a regular tag for these bugs, perhaps licensing. It might also be worth thinking about having some usertags under debian-legal@lists.debian.org that have a finer granularity. Thoughts? Cheers, aj signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Thu, Aug 31, 2006 at 12:15:20AM -0400, Nathanael Nerode wrote: I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. FWIW, there's a few things I'd love to see legal opinions on too, including the Java/non-free questions John Goerzen raised some time ago. They're still pending on SPI's todo list. If any qualified lawyers with experience in the US are reading this and would like to volunteer some of their time on a pro-bono basis to benefit Debian and other free software organisations such as FreeDesktop.org and PostgreSQL, sending mail to [EMAIL PROTECTED] to that effect might be worthwhile. Cheers, aj signature.asc Description: Digital signature
Re: Non-DD's in debian-legal
On Tue, Jun 13, 2006 at 03:11:42PM -0700, Adam McKenna wrote: If people who aren't members are raising valid concerns that need to be addressed before development can proceed, we shouldn't reject that input on the basis of membership and call it blocking development. Right. But it's also possible to raise a variety of invalid concerns in ways that require responses -- eg by saying Debian's policy in this matter is _ when it's not; in that case not responding can mislead people who aren't intimately familiar with Debian's actual policy on the matter, which is harmful. Both DD's and non-DD's troll, create flamewars, and otherwise cause issues that block development. Putting it in terms of DD's versus non-DD's is just prejudice and elitism at its worst. It's Debian developers that are expected to collectively determine what issues are valid, what our policies actually are, and what development is harmful enough that it should be blocked. Non-developers are welcome to comment on that, but their comments are only influential in so far as they persuade developers. Cheers, aj signature.asc Description: Digital signature
Re: Who can make binding legal agreements
On Thu, Jun 08, 2006 at 02:47:24PM +1000, Anthony Towns wrote: On Wed, Jun 07, 2006 at 09:07:07AM -0500, John Goerzen wrote: So what am I trying to do? Most importantly, make sure that SPI and Debian aren't exposed to serious legal risks. Then why don't you contact Greg and the SPI board yourself? (Subsequent to the message I was replying to, John's done this) Cheers, aj signature.asc Description: Digital signature
Re: Who can make binding legal agreements
On Wed, Jun 07, 2006 at 02:04:18PM +1000, Anthony Towns wrote: On Tue, Jun 06, 2006 at 09:35:41PM -0500, John Goerzen wrote: On Wed, Jun 07, 2006 at 12:02:16PM +1000, Anthony Towns wrote: The ability to enter into a legal contract to indemnify a third party should be, and arguably IS, reserved solely for the SPI Board of Directors. If SPI wish to withdraw from their relationship with Debian, then that's entirely possible to arrange. I don't think it's at all proper that you Nobody was suggesting that, and I fail to understand why it is in anyone's interests for you to ratchet up the heat on this issue another notch by making remarks like that. I don't understand why, as SPI President, you'd bring up concerns regarding SPI's legal position in the middle of a thread on -devel and -legal, without having discussed it on spi-board, having consulted SPI's attorney as to the validity of your concerns, or having contacted me as DPL or the archive administrators privately first, either. And hi to everyone from /.! http://linux.slashdot.org/linux/06/06/07/047204.shtml for those playing along at home. Cheers, aj signature.asc Description: Digital signature
Re: Non-DD's in debian-legal
On Wed, Jun 07, 2006 at 12:18:04PM +0100, Ian Jackson wrote: Jeremy Hankins writes (Non-DD's in debian-legal): I'm not sure I understand this part, though. Do you think that folks like myself, who are not DD's, should not participate in the discussions on d-l? Actually, I think they should not participate, in general. (I'll presume people can read Ian's post for his reasoning, so that I don't have to quote it) Personally, I think non-DDs participating is great; the only problem comes when that starts becoming a way for people who aren't members of the project to block development; which can happen either by people spending time arguing with non-DDs unnecessarily or by people thinking that people speak for the project when disagreeing, though they don't. Avoiding that is a challenge, but an easy first step is just to say something when people might mistakenly think someone who's not a DD is speaking for the project. Cheers, aj signature.asc Description: Digital signature
Re: Who can make binding legal agreements
On Wed, Jun 07, 2006 at 09:07:07AM -0500, John Goerzen wrote: So what am I trying to do? Most importantly, make sure that SPI and Debian aren't exposed to serious legal risks. Then why don't you contact Greg and the SPI board yourself? As I've said already, I don't want SPI to be involved in day-to-day license discussions in Debian. When there's a more deep question -- You're the one that has that question, however; ftpmaster don't believe there is any valid concern. That's a good reason for you to talk to Greg and get some professional legal advice, and, depending on what that is, talk to ftpmaster and Sun about whether the standards need to be changed, or talk to the DPL and the developer body about whether SPI and Debian's relationship should be changed in order to reduce the risks. As it happens, I've been thinking about the latter quite a bit, particularly in the context of keeping Debian's funds outside the US sorted out, and preventing Debian's identification with SPI from meaning that as an Australian helping out a Mexican, I'm bound by US laws simply by my association with Debian, or for that matter, US folks face potential liability for my actions even though they're not involved at all. I've already had to say no to one request to [EMAIL PROTECTED] for help on working with Debian in US embargoed countries (Iran, etc) for that reason, and that's something I'd like to avoid having to do again. (That was done with the support of SPI's attorney, Greg Pomerantz, as it happens) I'd hope that the Debian ftpmasters would feel free to shoot a message over to the SPI board and say, hey guys, could you run this by the attorney and let us know his thoughs? Certainly. I've already done this a couple of times on things where I thought it was important; but since, afaik, Greg is donating his time pro bono, I'm disinclined to do that unless I think there's an issue. Cheers, aj signature.asc Description: Digital signature
Re: Who can make binding legal agreements
On Wed, Jun 07, 2006 at 12:15:12PM -0500, Bill Allombert wrote: On Wed, Jun 07, 2006 at 09:46:57PM +1000, Anthony Towns wrote: And hi to everyone from /.! http://linux.slashdot.org/linux/06/06/07/047204.shtml for those playing along at home. If you wanted to avoid publicity, not announcing the inclusion of 'Sun Java' on debian-devel-announce would have been a better start. Publicity's always worthwhile -- whether it's positive or negative, it helps other people know what's going on, and indicates people care about what you're working on. It's also never wise to choose what you do in order to avoid publicity, that just allows people to threaten you with the prospect of an anonymous post to a web forum. But like people who might be misled into thinking someone on -legal is speaking for Debian when they're not, it's also worth making sure people realise that the thread they're posting to has hit slashdot so their words are being viewed by more than just the -legal or -devel regulars. I'm somewhat disappointed that whoever sent the link to /. didn't post a note to the thread themselves. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, Jun 04, 2006 at 03:59:03PM +0200, Dalibor Topic wrote: On Sun, 2006-06-04 at 09:57 +1000, Anthony Towns wrote: I would furthermore strongly encourage people to work *with* Sun towards improving the current license There have been numerous issues with the current text pointed out here already, I guess people are currently just waiting for the fixes from Sun's legal. Mmm. The impression I got was that people were waiting for the packages to be removed from Debian and no one was really all that interested in responses from Sun, cf: http://lists.debian.org/debian-legal/2006/06/msg00025.html http://lists.debian.org/debian-legal/2006/06/msg00031.html http://lists.debian.org/debian-legal/2006/06/msg00051.html http://lists.debian.org/debian-legal/2006/06/msg00058.html http://lists.debian.org/debian-legal/2006/06/msg00098.html And people are welcome to hold that opinion and speak about it all they like, but the way Debian makes the actual call on whether a license is suitable for distribution in non-free isn't based on who shouts the loudest on a mailing list, it's on the views of the archive maintainers. But that isn't the only issue at stake here, and it's not even the most important one; the other is communicating with Sun and other upstream authors the values that Debian thinks are important, and working with them to find common ground so that the licenses they choose reflect some of the goals and insights we've developed. Sun have made it very clear that they're trying to work with us on this for something that benefits our users, so that just leaves it to us to decide what's more important: taking a principled stand that we'll read every license literally and pedantically; or take advantage of other means by which we can be confident in distributing the software, and in so doing build a relationship with Sun that can be used later, and improve the experience of using Debian for people who need Sun Java? Certainly there are benefits to having a license that can be read literally and pedantically without causing problems -- and they're not small or neglible benefits either, as has been shown by pine, Qt, or ncftp in the past. But when standing up for that principle doesn't actually protect our users, and taking a flexible approach to it helps them, well, we have a social contract to make sure we do bend at this sort of time. Some kind of more structured process would be nice, the DPL could play a useful role there. The process for improving a license is pretty easy: someone suggests improvements to the author, they consider them and ask around for advice, there's some more discussion to make sure the suggestion is a good idea, and eventually a new license is issued. In this case, Sun have already gone to the effort of looking through Debian's procedures and started participating on the -legal list; -legal meanwhile have been obstructive in trying to tell Sun what their license means, even when that contradicts what Sun understands their license to mean as documented in their FAQ, and verified by their lawyers. and developing sufficient confidence in the Debian and free software community to release Java under an entirely free license. In my opinion, that's conflating two separate issues. Afaict, noone working on the DLJ (from Sun's or Debian's side) knew anything about Sun's recently voiced intention to 'release Java under an entirely free license'. I think interpreting that as an intention would be overstating it. Open sourcing Java has been on the cards for quite a while, and equally there have been objections to doing so for quite a while. One of the simplest objections is that the free software community just aren't an interesting market for Java people -- we don't want Java, so why spend effort giving it to us? We have an opportunity, if we choose to take advantage of it, get rid of that objection right now -- by putting in the effort to get Java packaged up in non-free and made useful for our users, both we and Sun can demonstrate that Java on Linux is actually a good idea. Or we could reinforce that objection, by making sure that no step Sun might take will achieve anything, and saying things like We've got Perl and Python and Ruby, why would we want Java? Personally, I'm not a Java programmer anymore than I'm a C++ or a Fortran programmer. But I know Java's a language, and I know Sun have written some runtime software for it, so I think that should first of all be cleanly packaged for Debian, and second of all be free software, and I just don't need a third thought on the issue. Sun already *is* part of the free software community, and has been for years. Sun is a big company; some parts are comfortable working with free software, others aren't. Historically, the Java section hasn't been -- and that's continues to be reflected in how well Java works on Linux. That's something we should change. Debian ships lots of free software with Sun's
Re: Who can make binding legal agreements
On Tue, Jun 06, 2006 at 11:47:03AM -0500, John Goerzen wrote: I am becoming increasingly concerned at the unilateral method in which you and/or the archive maintainers have taken this decision. The ability to enter into a legal contract to indemnify a third party should be, and arguably IS, reserved solely for the SPI Board of Directors. If SPI wish to withdraw from their relationship with Debian, then that's entirely possible to arrange. I don't think it's at all proper that you try to obtain veto power of Debian's activities as conducted by the duly authorised members of that organisation. SPI projects shouldn't be taking advice from Sun's attorneys. Debian's relationship with SPI is as a helpful legal entity that allows us to act in ways we would not be able to do so without it, not as Debian's governing body. And I know you would like me to just go away and shut up about this, but this project is too important, and this action has too many unknowns at this stage, to just put blind faith in Sun's lawyers doing the right thing by Debian. That would be a fair comment if it was actually what had happened. It's not. Cheers, aj signature.asc Description: Digital signature
Re: Who can make binding legal agreements
On Tue, Jun 06, 2006 at 09:35:41PM -0500, John Goerzen wrote: On Wed, Jun 07, 2006 at 12:02:16PM +1000, Anthony Towns wrote: The ability to enter into a legal contract to indemnify a third party should be, and arguably IS, reserved solely for the SPI Board of Directors. If SPI wish to withdraw from their relationship with Debian, then that's entirely possible to arrange. I don't think it's at all proper that you Nobody was suggesting that, and I fail to understand why it is in anyone's interests for you to ratchet up the heat on this issue another notch by making remarks like that. I don't understand why, as SPI President, you'd bring up concerns regarding SPI's legal position in the middle of a thread on -devel and -legal, without having discussed it on spi-board, having consulted SPI's attorney as to the validity of your concerns, or having contacted me as DPL or the archive administrators privately first, either. try to obtain veto power of Debian's activities as conducted by the duly authorised members of that organisation. First, I don't believe that SPI has ever granted anyone the ability to enter into legally-binding agreements to indemnify (which means to use our resources to defend) third parties. From the xorg-x11 copyright file: ] 11. Indemnity. Recipient shall be solely responsible for damages arising, ] directly or indirectly, out of its utilization of rights under this License. ] Recipient will defend, indemnify and hold harmless Silicon Graphics, Inc. ] from and against any loss, liability, damages, costs or expenses (including ] the payment of reasonable attorneys fees) arising out of Recipient's use, ] modification, reproduction and distribution of the Subject Software or out of ] any representation or warranty made by Recipient. From the openoffice.org copyright file: ] Therefore, if ] a Contributor includes the Program in a commercial product offering, such ] Contributor (Commercial Contributor) hereby agrees to defend and indemnify ] every other Contributor (Indemnified Contributor) against any losses, damages ] and costs (collectively Losses) arising from claims, lawsuits and other legal ] actions brought by a third party against the Indemnified Contributor to the ] extent caused by the acts or omissions of such Commercial Contributor in ] connection with its distribution of the Program in a commercial product ] offering. Secondly, I am saying that you should have contacted SPI *first*, so we could get advice from our attorney, and enter into agreements properly. I realise that's what you're saying; but if SPI are not willing to endorse the standard methods by which Debian operates -- having the archive administrators review licenses of new packages -- and the standard methods by which Debian reviews decisions -- public discussion with the original decision makers empowered to change their minds, and overview by the technical committee and the developers as a whole by general resolution, then we need to change Debian's relationship with SPI so that is not an issue. So I ask again: where do you derive your authority to enter into a legal obligation to indemnify Sun in this situation, and what legal entity do you believe is bound to honor that obligation? The authority of the DPL and archive administrators is derived from the Debian constitution. For reference, it says: ] 9. Software in the Public Interest ] ]SPI and Debian are separate organisations who share some goals. Debian ]is grateful for the legal support framework offered by SPI. [...] ] ] 9.1. Authority ] ] 1. SPI has no authority regarding Debian's technical or nontechnical ]decisions, except that no decision by Debian with respect to any ]property held by SPI shall require SPI to act outside its legal ]authority, and that Debian's constitution may occasionally use SPI ]as a decision body of last resort. ] 2. [...] Cheers, aj -- Anthony Towns -- Debian Project Leader signature.asc Description: Digital signature
Re: Sun Java available from non-free
(-devel dropped) On Mon, May 22, 2006 at 11:25:13AM +0200, Martijn van Oosterhout wrote: A few possible problems are: - The promise was made without consideration (no symbolic one cent payment) That's not true; they received assistance from Debian developers including myself on reviewing the license's suitability, packaging assistance, and in preparing their press release, all of which was provided after Sun had indicated they were trying to prepare a license that would allow Debian to distribute Java in non-free, and with the aim of making that possible. - The promise was not formally notarised. A press notice may not count. There are plenty of mail logs that can be provided as evidence as well, should we need it. If there's a particular statement that people think would be helpful, we could probably arrange to get that notarised (though obviously We hereby license Java under the GPL will take more than a little time). - It wouldn't damage Debian or anybody much to revoke the statement. If that's the case, there's no problem -- if Sun decide they'd like us to remove Java from non-free, they don't have to do anything beyond ask, and if they want it removed from non-free for stable, wait a month or two until the next point release is due. Thie simplest solution in this case would be if Sun simply attached the FAQ as an addendum to the licence rather than stating it's not legally binding. (Obviously, they've now done something like this as well) Cheers, aj signature.asc Description: Digital signature
Re: Sun responds to questions on the DLJ
On Sun, Jun 04, 2006 at 12:58:45PM +0200, Josselin Mouette wrote: Le mercredi 31 mai 2006 ? 15:01 +1000, Anthony Towns a ?crit : Please note that Walter does not speak for the Debian project, and is not a developer, maintainer, or new-maintainer applicant, just a participant on this mailing list. Do you really need to be so contemptuous against users who make mailing lists live? I don't believe that saying someone isn't a developer is contemptuous. It's very easy to fall under the misapprehension that the views of some participants on debian-legal represent the views of the Debian project as a whole, however, and particularly when that applies to individuals who aren't members of the Debian project, that does a serious disservice to people who are. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, Jun 04, 2006 at 06:13:27AM -0500, Bill Allombert wrote: As for the relevance of Sun position on Debian developers, there simply is none. The issue at question is whether Sun has given adequate permission for Debian to include java in non-free -- Sun's position on that isn't just relevant, it's the entire question. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, Jun 04, 2006 at 12:13:16PM +0200, Michael Meskes wrote: On Sun, Jun 04, 2006 at 09:57:40AM +1000, Anthony Towns wrote: position. Debian's position, as consistently expressed by ftpmaster, on this list, and in the press, is that the license is acceptable for non-free, and that is also Sun's position. Just for clarification, a position expressed by a person that has a special position but is not elected is to be considered an official statement by the project? To a degree, yes. In this particular case, ftpmaster are the maintainers of the archive, and their statements on what's suitable for the archive are authoritative by definition -- that's precisely what their area of authority is. The same thing applies when the dpkg maintainer speaks about dpkg -- every maintainer is an authority on their own package. Beyond that, the DPL is authorised to make statements of support for points of view or for other members of the project, when asked or otherwise (5.1.2), which I've done above, and that is an elected position, if you feel that makes a difference. Those aren't the final word; technical statements by maintainers can be overruled by the technical committee, and pretty much anything can be overruled by a general resolution of some sort or another, but, just for clarification, yes that really is the way things work in Debian. Cheers, aj -- Anthony Towns -- Debian Project Leader signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, Jun 04, 2006 at 12:18:39AM -0700, Mike Bird wrote: Too many excuses. All inadequate. It is past time that the covert actions of the small cabal were openly reviewed. The license (for convenience), any relevant written promises from Sun (if any), and any relevant written legal opinions from counsel (if any) should forthwith be posted to debian-legal. For those playing along at home, Mike isn't a Debian developer, doesn't maintain any packages, and isn't a new-maintainer applicant. He doesn't even seem to be a regular participant on the debian-legal list. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sat, Jun 03, 2006 at 07:37:21PM +0200, Toni Mueller wrote: Unfortunately many many people out there are not very interested in dissecting licenses and in telling real and fake free software apart. Even less in examining potential issues with non-free packages. Debian would become (viewed as, at least, as) one more project to not take care about what Free Software is, despite the strong emphasis issued in most public statements... Neither Sun nor Debian have at any point said that Sun Java is free software -- it's been uploaded to non-free for precisely that reason. If anyone does think that, it's pretty easy to clarify for them -- Debian's stance is that free software is important, but that doesn't mean that we can ignore non-free software that our users want. OTOH, I'd say pull it *now* while distribution is low, then fix the problems, and only *then* get it back in... seems to be the least damaging route to go for, imho. You can say that if you like, but please be aware that it's not Debian's position. Debian's position, as consistently expressed by ftpmaster, on this list, and in the press, is that the license is acceptable for non-free, and that is also Sun's position. I would furthermore strongly encourage people to work *with* Sun towards improving the current license and developing sufficient confidence in the Debian and free software community to release Java under an entirely free license. The end goal isn't to turn this into a PR stunt to make sure Debian's viewed the right way, it's both to help our users get software they need, free or not, and to encourage more people to make their software free. Cheers, aj -- Anthony Towns -- Debian Project Leader signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Sun, May 21, 2006 at 06:14:51PM +0200, Michael Meskes wrote: On Sat, May 20, 2006 at 04:18:44PM -0500, Anthony Towns wrote: Anyway, the background is that James Troup, Jeroen van Wolffelaar and myself examined the license before accepting it into non-free (which is three times the usual examination, and was done given the inability to examine the license in public), and both James and Jeroen had extensive contact with Sun to ensure that the tricky clauses were actually okay. You won't expect Sun to say they are not, would you? :-) The questions asked weren't Is this okay for non-free? it's Did you mean or when you wrote ?. The answers to those latter questions are, ttbomk, all included in the FAQ, which is why ignoring it just wastes everyone's time. most important, is that should any of these problems actually happen, we can fairly simply just drop Sun Java from non-free if we can't come to a better conclusion. Do you mean we can drop it if problems arise? Or do you mean we can drop it if we cannot conlcude it's okay to distribute it? I doubt you mean the first case, as it would be too late then. No, that's not the case -- if we are informed that there is a problem with what we're distributing, we can drop it 90 days after we're so informed, and not have any problems. Right, but again, why bringing the package with a bad license into the archive first? Because non-free is for bad licenses in the sense that they don't meet the DFSG, and because the Sun license is not bad in the sense that it causes any problems that we cannot deal with. DPL, I wonder Why the Sun-Java package is not handled the same as any other package. What makes it so special that it deserves special treatment? Java is one of the most important packages for which we don't have an effective non-free replacement at present. The only one that I can think of that would be more important would be flash. Cheers, aj signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Fri, May 19, 2006 at 01:12:19PM +0200, Martin Zobel-Helas wrote: On Friday, 19 May 2006, you wrote: As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. I take it you were too busy to elaborate on this when you wrote this email. So you will probably give us the name of this person later on, right? Or even better this person may stand up now and speak for himself and share his reasoning. i hope it is just due to the lag of bandwidth, so AJ is just trying to use as little bandwidth as possible, to leave the rest for us, watching the videostream from outside. ;) Lack of temporal bandwidth is an issue too, as you can probably guess by the length of time it's taken to actually reply to this. I was actually surprised to see that I'd posted that mail; I'd thought I'd left it in my queue to think about for a bit before sending... Oh well. Anyway, the background is that James Troup, Jeroen van Wolffelaar and myself examined the license before accepting it into non-free (which is three times the usual examination, and was done given the inability to examine the license in public), and both James and Jeroen had extensive contact with Sun to ensure that the tricky clauses were actually okay. There are three factors that are particularly relevant: the first is Sun's intentions and ability and interest to work with us as a proxy for the broader free software community -- this is an important issue because it ensures that we can resolve any problems with the license, and reduces the concern that Sun will try to screw us over, as it would become a PR problem rather than just a quiet argument on the lists; the second is that both the legal principle of estoppel and the general common sense principle of not going back on your word if you want people to work with you prevents Sun from realistically saying the FAQ is completely wrong and should be ignored; and the third aspect, which is probably most important, is that should any of these problems actually happen, we can fairly simply just drop Sun Java from non-free if we can't come to a better conclusion. That's not to say the license issues aren't problems, they are, and I hope debian-legal will be able to work with Sun both on helping them improve their non-free license, and in the future, helping them work through their concerns in applying a free license to Java. Obviously the Sun and Java guys have different priorities to -legal, but that doesn't mean it's not worth working together to solve what problems can be. In particular, saying sure, you spent all that time writing a FAQ, but we're going to pretend you didn't isn't a good way to start a productive relationship -- some of these issues from the FAQ remain ambiguous in the license, perhaps you would consider clarifying it in the license in a future version by saying ___ or this issue isn't clarified in either the FAQ or the license, and is important because _. Unfortunately the possibility of Sun Java being relicensed suitably for non-free wasn't mentioned to us in enough time to build up a relationship with -legal folks that wouldn't primarily involve telling the Sun guys how this wasn't going to work. Fortunately James and Jeroen have been able to build a reasonably effective relationship with the Sun folks involved in the time provided; hopefully now that it's public, -legal in general will have the time and opportunity to do likewise, in a more thorough and transparent way. Tom Marble has begun responding to concerns raised on -legal [0] and I would strongly encourage folks to work with him and other Sun folks in a positive and constructive manner so that we can further encourage Sun's current forays into the free software world, hopefully resulting in them immersing themselves completely, eventually. Cheers, aj [0] Message-id: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Sun Java available from non-free
On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote: First off, I'm going to completely ignore the FAQ as the FAQ and the license both specifies that the FAQ does not have any legal validity. Repeating frequently asked questions that have already been answered isn't terribly useful. As a final note, did anyone from Debian who usually examines licences actually examine this one? Yes. Cheers, aj signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
On Mon, Mar 13, 2006 at 11:32:12AM -0800, Walter Landry wrote: I think the sentiment that produced this voting pattern was a desire not to see any more emails about the GFDL. For example, Anthony Towns wrote [1]: I think Anton's amendment has received more than enough discussion that it ought to be voted above Further Discussion Essentially, voter fatigue has beaten out Further Discussion. I would consider that a flaw in the voting method, though not all may agree. The free in all cases option was beaten by free in no cases by 226:117 (2 out of 3 voters), and by free in the absence of invariant sections by 266:76 (7 out of 9 voters). That's not evidence of voter fatigue, it's evidence that the issues have been thought through enough for us to make a clear decision. Which we did. That you disagree with that decision is fine -- the only way to ensure no one ever comes to a decision you disagree with is to be absolute dictator for life. But there's no need to cast aspersions on the people who disagree with you, that they only did so due to fatigue or ignorance. Cheers, aj signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
On Thu, Mar 16, 2006 at 03:39:46PM +0100, Henning Makholm wrote: Scripsit Anthony Towns aj@azure.humbug.org.au The Project did not tell us why. You could ask, you know. You still can do that, you know, if you actually want the answer. If we just ask, we're probably not going to get an answer. If you don't ask, you certainly won't get an answer. There's a huge list of people who seconded dato's amendment, if you want to know, ask them what the amendment was based on. I think that this very thread is an attempt to construct some reasonably self-consistent interpretations that we can ask the developers to decide between. The developers have already decided. Surely you can see there's a major problem with debian-legal if it doesn't actually know what Debian's position on a major licensing matter is, even directly after a GR... Cheers, aj signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
On Wed, Mar 15, 2006 at 09:54:15PM -0500, Anthony DeRobertis wrote: Anthony Towns wrote: So, debian-legal is us, leaving the rest of the project to be them? When I'm sending a message to debian-legal, yes, I often use us to mean the participants on debian-legal. I intend only to save a little typing, nothing more. I realise you didn't intend anything by it, but look at it again: The Project essentially told us our conclusion the GFDL is not free is wrong in the case where there are no invariant sections. debian-legal is only useful in so far as it's somewhere for Debian to talk about licenses. If the participants on debian-legal have different conclusions to the Debian project as a whole, that's a major problem in that people going to get Debian's opinion are instead getting something quite different. You didn't quote: The Project did not tell us why. You could ask, you know. You still can do that, you know, if you actually want the answer. Cheers, aj signature.asc Description: Digital signature
Re: Results for Debian's Position on the GFDL
On Sun, Mar 12, 2006 at 11:17:37PM -0500, Anthony DeRobertis wrote: The Project essentially told us our conclusion ??? the GFDL is not free ??? is wrong in the case where there are no invariant sections. So, debian-legal is us, leaving the rest of the project to be them? The Project did not tell us why. You could ask, you know. Cheers, aj signature.asc Description: Digital signature
Re: Affero General Public License
On Wed, Feb 08, 2006 at 05:02:22PM -0500, Glenn Maynard wrote: A real example (from my own field) where this would cause serious practical problems is arcade machines. It's clearly public performance, and players in arcades really are using (and interacting with) the software directly. We include sources to GPL stuff on the machine's drive itself (though nobody cares, since none of it is modified except for the kernel, and that particular code is available on our webpage too). That's for the arcade operator (the owner of the machine). I have no idea how one might satisfy a requirement that the *users* be given GPL-like access to the source. One way would be to supply a compactflash card slot that will burn the sources to a 1GB compactflash card. That seems a lot less outrageous today than it did three years ago, to my mind. On the other hand, it still seems unreasonable to expect people to ensure that source is accessible from every machine that lets someone login remotely and run ls. And given you can probably setup filters without violating the copyright restrictions -- ie adding a proxy that prevents you from getting to the download-source url, or putting a metal plate over the card-writer slot -- I'm not really sure how useful these requirements are going to be in practice anyway. But in so far as our aim's to let people use as much software as they can, and do as much with it as they can, I'm not convinced that requiring some scripts to have a cat $0 option is that big a deal either. Cheers, aj signature.asc Description: Digital signature
Re: GPL v3 Draft
On Tue, Jan 17, 2006 at 02:49:24AM -0500, Glenn Maynard wrote: On Tue, Jan 17, 2006 at 05:05:26PM +1000, Anthony Towns wrote: HTTP and FTP sound pretty equivalent to me. I don't think you'd have any problems finding an expert witness to testify to that. HTTP and rsync might not be, though. I'm not sure a court would have much difficulty in allowing equivalent to allow for well, the source archive is /more/ capable, we figured that woudl be fine, though. What about binaries via BitTorrent, source via HTTP? BT would be more capable than HTTP for many projects' binaries, and HTTP more capable for source, where a lot of people download binaries and few download source. I can't see a reason why you wouldn't make the source available by bittorrent too. They're clearly not equivalent, but it seems like a perfectly reasonable distribution scheme. I don't know; they're not that non-equivalent: they both distribute verbatim files at you. If the http server had insufficient bandwidth, or wasn't as available as the bt network, there could be an issue, but I wouldn't say they're non-equivalent in all circumstances. d) They may require that the work contain functioning facilities that It's interesting that the word they've chosen is contain, not retain. Well, retain would imply I can't change it, which would be even worse. No, retain would just mean you couldn't remove it -- it's also what the Affero GPL requires. Contain is stronger -- it means if it's not already there, you have to add it. OTOH, at its absolute worst, it doesn't make GPLv3 stuff that doesn't make use of that option non-free. I think you're the third person to say something along those lines: be thankful, it could be a lot worse. I think you're underestimating just how bad some of us expected the GPLv3 draft to be. :) It's still endorsing an extremely onerous class of restriction, implying that it's acceptable, helpful, and that the classes of application screwed over by it is unimportant. It's discouraging that people are thankful that's all it is ... The Affero license came out in 2002, at which point flash cards cost ~$1/MB; they now seem to cost around 6c/MB. Hard drives, bandwidth, etc seem to be similarly better. How hard is it really to satisfy these requirements? (The Affero licenses clause is: d) If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work. There was also an RPSL clause for similar purposes that was more problematic) Cheers, aj signature.asc Description: Digital signature
Re: GPL v3 Draft
On Mon, Jan 16, 2006 at 02:15:09PM -0500, Glenn Maynard wrote: No covered work constitutes part of an effective technological protection measure: that is to say, distribution of a covered work as part of a system to generate or access certain data constitutes general permission at least for development, distribution and use, under this License, of other software capable of accessing the same data. It sounds like this means if your GPL application accesses data, you grant a GPL license to every other application that accesses the data. Not quite -- it says you give general permission for other applications to be distributed under the GPL. Which means that when someone does reverse engineer your stuff, and puts it in a GPLed app, you can't then say You don't have permission to do that because you're violationg my patents|the DMCA -- because you've already given them the permission you claim they don't have. d) Distribute the Object Code by offering access to copy it from a designated place, and offer equivalent access to copy the Corresponding Source in the same way through the same place. You need not require recipients to copy the Corresponding Source along with the Object Code. [If the place to copy the Object Code is a network server, the Corresponding Source may be on a different server that supports equivalent copying facilities, provided you have explicitly arranged with the operator of that server to keep the Corresponding Source available for as long as needed to satisfy these requirements, and provided you maintain clear directions next to the Object Code saying where to find the Corresponding Source.] This seems to imply that I can't put the object code on an http server, and the source code on an ftp server, because their copying facilities are not equivalent. HTTP and FTP sound pretty equivalent to me. I don't think you'd have any problems finding an expert witness to testify to that. HTTP and rsync might not be, though. I'm not sure a court would have much difficulty in allowing equivalent to allow for well, the source archive is /more/ capable, we figured that woudl be fine, though. I may want to use a special-purpose download server for object files, for automatic downloading and installation of binaries; that server may have carefully limited facilities, as fewer unused features in a server means less to break, which means less downtime. In that case, I'm likely to want to put the source on a more traditional http server. This clause seems to unintentionally prohibit this class of distribution. That could be, though I'm not sure that wouldn't turn into an argument for allowing lines like sure we have our binaries on akamai, and our sources on a secondhand m68k behind a modem, but hey, they're both on the net! d) They may require that the work contain functioning facilities that It's interesting that the word they've chosen is contain, not retain. allow users to immediately obtain copies of its Complete Corresponding Source Code. Such terms make code reuse with non-networked applications extremely inconvenient, and prohibit reuse in embedded environments (eg. a device with 32k of memory, no network facilities, and limited or no visual output). I'd find it disturbing for the FSF to even call such terms free; they're going much further, and condoning it by making it GPL-compatible. (This is, by a wide margin, my biggest objection.) OTOH, at its absolute worst, it doesn't make GPLv3 stuff that doesn't make use of that option non-free. On Mon, Jan 16, 2006 at 11:02:09PM +0100, Bas Zoetekouw wrote: IMO, this is a clear violation of DFSG 6. If we allow terrorists to use our code, and allow it to be used in biological weapons research, clearly also black hat hackers must be allowed to use it to produce spyware. I don't think it's right to demand that authors give explicit permission to do illegal things; and I don't think we should start treating a lack of permission and explicitly not giving permission as different. I read that clause as banning distribution of (a certain class of) contraband, which is banned already anyway -- probably even to create or possess, let alone distribute. As such, I'm not actually sure it covers anything in practice. If that's not correct, and it is banning things that aren't already illegal, there might be a problem. Cheers, aj signature.asc Description: Digital signature
GR Proposal: GFDL statement
Bcc'ed to -project, -legal and -private; followups to -vote please. It's been six months since the social contract changes that forbid non-free documentation went into effect [0], and we're still distributing GFDLed stuff in unstable [1]. I think we should get serious about fixing that, and as part of that that we should release the following statement (or one like it) on the GFDL: --- Why the GNU Free Documentation License is not suitable for Debian main ~~ (0) Summary Within the Debian community there has been a significant amount of concern about the GNU Free Documentation License (GFDL), and whether it is, in fact, a free license. This document attempts to explain why Debian's answer is no. It should be noted that this does not imply any hostility towards the Free Software Foundation, and does not mean that GFDL documentation should not be considered free enough by others, and Debian itself will continue distributing GFDL documentation in its non-free section. (1) What is the GFDL? The GFDL is a license written by the Free Software Foundation, who use it as a license for their own documentation, and promote it to others. It is also used as Wikipedia's license. To quote the GFDL's Preamble: The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. (2) How does it fail to meet Debian's standards for Free Software? The GFDL conflicts with traditional requirements for free software in a variety of ways, some of which are expanded upon below. As a copyleft license, one of the consequences of this is that it is not possible to include content from a documention directly into free software under the GFDL. The major conflicts are: (2.1) Invariant Sections The most troublesome conflict concerns the class of invariant sections that, once included, may not be modified or removed from the documentation in future. Modifiability is, however, a fundamental requirement of the DFSG, which states: 3. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software. Invariant sections create particular problems in reusing small portions of the work (since any invariant sections must be included also, however large), and in making sure the documentation remains accurate and relevant. (2.2) Transparent Copies The second conflict is related to the GFDL's requirements for transparent copies of documentation (that is, a copy of the documentation in a form suitable for editing). In particular, Section 3 of the GFDL requires that a transparent copy of the documentation be included with every opaque copy distributed, or that a transparent copy is made available for a year after the opaque copies are no longer being distributed. For free software works, Debian expects that simply providing the source (or transparent copy) alongside derivative works will be sufficient, but this does not satisfy either clause of the GFDL's requirements. (2.3) Digital Rights Management The third conflict with the GFDL arises from the measures in Section 2 that attempt to overcome Digital Rights Management (DRM) technologies. In particular, the GFDL states that You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. This inhibits freedom in three ways: it limits use of the documentation as well as distribution, by covering all copies made, as well as copies distributed; it rules out distributing copies on DRM-protected media, even if done in such a way as to give users full access to a transparent copy of the work; and, as written, it also potentially disallows encrypting the documentation, or even storing it on a filesystem that supports permissions. (3) Why does documentation need to be Free Software? There are a number of obvious differences between programs and documentation that often inspire people to ask why not simply have different standards for the two? For example, books are often written by individuals, while programs are written by teams, so proper credit for a book might be more important than proper credit for a program. On the other hand, free software is often written by a single person, and free software
Re: Licenses for DebConf6
On Sun, Nov 13, 2005 at 04:56:37PM +0100, Francesco Poli wrote: On Sun, 13 Nov 2005 11:28:41 +1000 Anthony Towns wrote: On Sat, Nov 12, 2005 at 07:26:55PM +0100, Francesco Poli wrote: I disagree with your calling licensing in a DFSG-free manner as giving up rights: this seems to imply that releasing DFSG-free works is something wrong or inappropriate. Uh, licensing in a DFSG-free manner *is* giving up rights. Of course it is. Maybe I didn't explain myself clearly enough, my apologies. What I meant is that using that description is suitable if you want to depict licening in a DFSG-free manner as something wrong that people should *avoid*. If the description is accurate, it's suitable at any time. It resembles describing charity as investment with no return. Perhaps; though there are differences. Charity does have returns: both emotionally/psychologically, and in helping people get up on their feet so they can trade with you / work for you / employ you in future. Charitable donations might have different tax considerations too. By contrast, BSD-like licenses do nothing but give up your rights. Copyleft licenses do something in between -- giving up your rights in the hope that others will give up there's in return. Well, it's not an inaccurate description (I think), but you would use such a definition only if you think that charity is a stupid thing to do... So, if I'm parsing you right, you're saying that a person (such as myself) would only describe free software as giving up rights (such as I did) only if that person (me) thought that free software was a stupid thing to do? If that's not what you're trying to say, would you kindly look back over your argument, and retract the error? Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Sun, Nov 13, 2005 at 06:59:41AM -0800, Thomas Bushnell BSG wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Nov 13, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: I think the best reason to ask or require contributors to licenses their papers in a DFSG form is so that Debian can distribute the papers as part of Debian. I think this is an awful reason, considering that Debian already contains too many non-software packages. I'm sorry, I was under the impression that every package in Debian was software. Are you confusing software and computer programs? In case you hadn't noticed, for the Debian project's purposes software is a synonym for computer programs; if it weren't the reversion of the social contract would have had no effect on the non-free documentation in main question. Indeed, the secretary refused to allow a GR proposal to revert that policy without limiting the social contract to talking about free software. HTH, HAND! Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Mon, Nov 14, 2005 at 05:38:10PM +, Colin Watson wrote: On Mon, Nov 14, 2005 at 11:17:06PM +1000, Anthony Towns wrote: On Sun, Nov 13, 2005 at 04:56:37PM +0100, Francesco Poli wrote: It resembles describing charity as investment with no return. Perhaps; though there are differences. Charity does have returns: both emotionally/psychologically, and in helping people get up on their feet so they can trade with you / work for you / employ you in future. Charitable donations might have different tax considerations too. By contrast, BSD-like licenses do nothing but give up your rights. Copyleft licenses do something in between -- giving up your rights in the hope that others will give up there's in return. People get emotional/psychological benefits from giving away their free software work under BSD/copyleft licences too; Sure, but that doesn't stop it from being a give away of your rights. It only (potentially) stops it from being an investment with no return. I can't say that I understand your by contrast here. There are certainly differences, but, with the exception of tax considerations, most of the things you list don't really seem to be among them. I never claimed writing free software was an investment with no return. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 10:21:08PM -0600, Manoj Srivastava wrote: Because sometimes one feels the need to fight for what is right? Even if people feel far more comfortable with just sweeping stuff under the carpet, and not brought out in the open? You know, I was going to say something like fighting, fighting, fighting; why isn't coding good enough, but to be honest, I don't really believe that anyway, or I wouldn't be subscribed to this list. But instead, what I'm led to wonder is if this is really standing up for our beliefs and fighting the good fight, or actually just trying to avoid those issues. Because insisting non-free stuff not appear at debconf seems like trying to avoid acknowledging its existence in the same manner as sweeping stuff under the carpet, rather than having the non-free stuff appear and trying to convince possibly disagreeable folks that the DFSG's terms really are worth following no matter what your goals. The world at large has lots of non-free licenses for content -- if we wanted to run away from that fact and avoid it, wouldn't we create a little enclave of our own with guards at the gate telling everyone who doesn't meet our standards to go back home, in the same way debconf is? (Hrm, I'm actually not sure why I chose the CC license now; I thought I remembered the dc5 CFP said papers had to be GPLed or CCed, and that tweaking all the mindless DFSG bigots by licensing my paper in a way that's adequately free, yet not DFSG-free would be fun. But the dc5 CC stuff was actually just for the recordings, afaics, so maybe that wasn't it, or maybe I was just confused. Oh well) My blog's licensed under the CC No-derivs/non-commerical license for much the same reasons as most of RMS's writings aren't DFSG-free; but that's fine -- I'm not trying to get them to become the basis of a developer community or similar, and that's why I'm not bothered by not having comments on my blog, either. And, thankfully, they do not come with the imprimatur of the Debian project, as Debconf seems to. My blog's aggregated on planet.debian.org; these lists posts (that aren't explicitly licensed at all, let alone DFSG-freely) are archived on lists.debian.org, and bug related conversations (which likewise are generally only implicitly licensed) are archived on bugs.debian.org. Of these, debconf probably is the one that makes least use of the imprimatur of the Debian project, being hosted at debconf.org. If Debian lends it names to a compilation of papers distributed by it, such as it may be construed as the compilation product of the Debian project, or in any way part of Debian, we are constrained to have that compilation be free. In the same way that non-free, which is distributed by DEbian, can be construed as the product of the Debian project or in any way part of Debian, then we're constrained to have non-free be free? That's a deeply erroneous argument, both at a factual level, and as advocacy. It's far more effective to advocate for something by demonstrating you're not prejudiced against the alternatives, and simply in favour of the best thing winning, and that you, personally, think the best thing is free software. You not only get your point across, but you also get to establish that you're not in denial about the strengths of your opposition and that your judgement and arguments can be listened to without having to filter out too much self-serving bias. If, of course, Debconf is a independent entity, not related to Debian, then I have no opinion, [...] Which strikes me as odd; personally, I think everyone should be doing DFSG-free software and free content, whether they're related to Debian or not. So I wonder if that attitude isn't part of giving up on the fight. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Sat, Nov 12, 2005 at 07:26:55PM +0100, Francesco Poli wrote: Scripsit Don Armstrong [EMAIL PROTECTED] On Sat, 12 Nov 2005, Anthony Towns wrote: The conferences I usually publish at always demand an all-out copyright _transfer_. However, in practice they will usually accept a non-exclusive license to print and distribute unmodified copies. I think it would be sad if Debconf required more than that. Several distros include non-free software, as long as it's distributable. Debian's one of them -- we just clearly separate out the non-free stuff from the free stuff. And heck, you could pretty easily come up with a definition of free that's either more strict than Debian (excluding the advertising clause or dropping the changes as patches dispensation, eg), or more liberal (that would include the Affero license or the GFDL, perhaps). Neither of those would be inherently unjustifiable, they'd just be different tradeoffs to what Debian's made. But calling them non-free in some absolute sense just isn't terribly meaningful. Debian distributes lots of things that aren't DFSG-free -- not only stuff in non-free, but also stuff on lists.debian.org (like this thread), stuff on bugs.debian.org, and stuff on planet.debian.org. Those examples are primarily a case of not being able to do better and still function; here I believe we can do better, and therefore should. I'm not sure anyone thinks we couldn't /function/ without non-free, but a majority of us decided it would be /better/ to keep it. I fully disagree, also with your implied assertion that wanting the author to give up more rights than necessary is better for the purpose of a conference. I disagree with your calling licensing in a DFSG-free manner as giving up rights: this seems to imply that releasing DFSG-free works is something wrong or inappropriate. Uh, licensing in a DFSG-free manner *is* giving up rights. You might as well disagree with entropy or conservation of energy. It's giving up the exclusive rights to control distribution of the work you created -- in the case of the BSD license, asking nothing but acknowledgement in return, in the case of copyleft licenses, asking only that others who contribute to the work do the same. We shouldn't forget what an enormous act of generosity that is. I would like to see more authors licensing in a DFSG-free manner because Even if for no other reason, promoting generosity is a wonderful thing. On the other hand, requiring it isn't -- that becomes an act of selfishness on our own behalf. Papers are (most often) documentation: No, they're not. Papers are radically different to documentation -- when you write a manpage you don't have to worry about standing up in front of a hundred people as well. I think that, recently, we lack DFSG-free documentation more than DFSG-free programs. That's not solved by bundling a paper in with the program; most particularly because papers are /hard/ to write, and that makes them hard to update, which in turn makes them obsolescent. Papers are to help people understand the talk; sometimes they might do more than that and perhaps even warrant inclusion in the distro, other times that goal alone is hard enough. Hence I want to promote DFSG-free licensing for documentation (and other non-program works). Promoting that's great; promoting it by telling other people to do it for you and not brooking objections is less so. Since the Debian project (luckily) rejects non-free works from its main archive, a DEBian CONFerence (isn't that the meaning of DebConf?) seems to be the ideal event where to promote DFSG-compliance... If demanding DFSG-free licenses for papers were a good thing, doing it at debconf would be an ideal place. I don't think the latter's been established; and given the organisers don't even fully understand what good licenses are for recordings of the conference, claiming we already have all the answers on what makes good licenses for conferences seems unjustifiable. If a paper/presentation/handout is interesting enough (I hope every author thinks his/her is, otherwise he/she would not give a talk at DebConf!), someone could modify it (in order to update it, improve it, translate it into another spoken language, ...) and reuse it (to give a talk in another conference, or to build a useful HOWTO, or whatever...). This mechanism would enable further spreading of good documentation on the subjects we care of. Sure -- and all those things are possible with certain classes of non-DFSG-free licenses too. You might as well have said If a paper is interesting enough, someone might want to include it in Debian -- in which case I'd have to demur; I don't think my debbugs paper should be included in Debian, because as interesting as it is, it's stuck in a particular time, that, four months after the fact, is already obsolete. As far as good documentation goes, updating the inline documentation in the code
Re: Licenses for DebConf6
On Sat, Nov 12, 2005 at 11:24:04PM -0600, Manoj Srivastava wrote: Several distros include non-free software, as long as it's distributable. Debian's one of them -- we just clearly separate out the non-free stuff from the free stuff. I am coming to the conclusion thst we do not clearly enough mark the distinction. *shrug* The only lack of clarity comes when people indulge in sweeping rhetoric claiming that everything Debian related is 100% free, which is not true now and never has been. I am changing my mind about the non-free GR -- this time, I would vote differently; since even you seem to imply that Debian includes non-free software, or close enough as to make no difference. No, I specifically cited the difference from some other distributions -- that we separate it out quite clearly. Personally, the conclusion I'm coming to is that Debian's spent a little too much time trying to have it both ways on issues like this, rather than fighting for what we actually believe even when that doesn't fit into a simple slogan. I am also now convinced I was mistaken in assuming that we label non-free software clearly. So, I, for one, am reexamining my previous support for keeping non-free on Debian machines. Perhaps it is coming to the time where the question should again be open for discussion. Maybe we should just have it on a set date annually, no matter who won last time. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 08:00:55AM -0500, Glenn Maynard wrote: On Fri, Nov 11, 2005 at 03:26:58PM +1000, Anthony Towns wrote: Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? Even within Debian, it's become clear to me that, if we want DFSG-free things, it has to be mandatory and enforced, Of course, within Debian DFSG-freeness isn't mandatory or enforced: you can upload to non-free instead of main just by tweaking your control file. And that lack of compulsion, coupled with a fairly strong endorsement of DFSG-free content has resulted in DFSG-free software making up 98% of unstable. My point was that this isn't a big fight: these are papers, typically written by one person, who is probably in all cases immediately, easily contactable; not software with dozens of copyright holders, or written by companies feeling their commercial interests threatened. Compared to the battles underlying a lot of attempts to get free licenses, this is easy. The hard part isn't finding the people, it's convincing them that a DFSG-free license is best. That's why pine and qmail remain in non-free even though we know exactly who their authors are. Or, for that matter, most of RMS's writings are still licensed in a non-DFSG-free manner. BTW, a question: if you say you must make your stuff DFSG-free, aren't you inspiring debate from people who don't want to, or who aren't comfortable with that, on why the DFSG isn't appropriate? If you made it optional or encouraged instead of compulsory, wouldn't that encourage debate on why the DFSG is good in the specific instances where people choose not to use free licenses? Wouldn't that be better? All it's doing is shifting who has to start the debate: No, it's not. In this case, I'd much rather be in a position where I can argue for making things DFSG-free when I can see enough specifics to think of good reasons why that woul dbe okay, and remain silent in the cases where I don't think that's a win. I don't think remaining silent when people are being pressured to do things that don't seem right is a good option though, so instead I find myself arguing against the DFSG. in the optional case, the people who think all of the papers should be free will debate the cases that weren't; I don't believe I've seen anyone debate my use of the (aiui) non-DFSG-free CC ShareAlike/Attrib clause on my debbugs paper this year. There's no actual requirement for debate there either, the people who want to license their paper in non-DFSG-free way can happily leave the last word to the DFSG advocates because they don't have to debate to get their way; and the advocacy and arguments about the DFSG are more likely to have a long term effect than the license on any paper presented at a conference. and in the compulsory case, the people who think papers shouldn't have to be free will debate theirs. Which, to my mind, means it's a real, substantive win to not give people any reason to make this argument. At the very least, I'm getting really tired of having to have my desire for tolerance of other people's choices and individual freedoms trump my desire to argue for the DFSG freedoms everywhere. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Fri, Nov 11, 2005 at 12:49:21AM -0800, Don Armstrong wrote: It's not all that unusual for conferences to require that the material submitted for the conference be licensed in a specific manner; OTOH, conferences usually ask for the minimal permission they actually need to do their job. if you plan on presenting, some DFSG free license of the material you present should be expected so portions of the work can be utilized in main or otherwise distributed by Debian if desired. Debian distributes lots of things that aren't DFSG-free -- not only stuff in non-free, but also stuff on lists.debian.org (like this thread), stuff on bugs.debian.org, and stuff on planet.debian.org. [If this poses a problem,[1] you always have the option of not presenting, or presenting your work in an informal session.] *sigh* Does this really have to devolve to if you don't like it, go away already? How about showing your potential speakers enough courtesy to at least consider their concerns, and enough respect to believe that they're scrupulous enough that they'll do the right thing even without being forced? Or, for that matter, having the flexibility to accept that sometimes the right thing changes depending on the situation? On Fri, 11 Nov 2005, Anthony Towns wrote: Of course, DFSG-free isn't all the dc6 organisers are insisting on, but the right to MIT/X11 recordings of presentations too -- not even giving presenters the option to copyleft the recording of their presentation for some reason. This is primarily pragmatic, since there's no clear consensus on what the prefered form for modification for a video is, or even what it means to copyleft a video. Huh? Copyleft == you can't restrict other people from redistributing and making further modifications. As an example: someone downloads the debconf presentations, culls various tidbits from them and puts them together in a dos and don'ts of technical presentations, then sells the new video for $5 a pop online, and refuses to allow people who purchase it to modify or redistribute it. Example copyleft licenses for videos include the CC ShareAlike licenses, the GFDL, the OPL, and the GPL. TTBOMK, of those, only the GPL talks about preferred form for modification. Cheers, aj signature.asc Description: Digital signature
Re: Licenses for DebConf6
On Thu, Nov 10, 2005 at 07:49:36PM -0500, Glenn Maynard wrote: FYI, a possible response might be: we care about freeness, but we pick our battle, and our battle is Debian main. I care about starving children, but I don't donate the majority of every check to feed them: there are lots of good causes, and the fact that everybody has to pick and choose their causes doesn't mean people don't care enough. (That said, I don't agree with that response: it should be no big deal for people to freely license their papers, so they can be packaged later in Debian. This isn't a big, difficult fight.) Why fight at all? If having a free license is so obviously correct, why force people to do it? If some people are uncomfortable with it, why fight that? My blog's licensed under the CC No-derivs/non-commerical license for much the same reasons as most of RMS's writings aren't DFSG-free; but that's fine -- I'm not trying to get them to become the basis of a developer community or similar, and that's why I'm not bothered by not having comments on my blog, either. Likewise my list posts (like this one) don't have any explicit license, just the implied license that evolves from knowingly posting to public mailing lists -- which gives people the right to quote and archive them, and the occassional fair use right, but certainly not enough to qualify for main in the strictest sense. My debbugs paper was licensed under the CC Attrib/ShareAlike license, which is relatively free, but also not DFSG-free apparently. OTOH, it's also already out of date. Of course, DFSG-free isn't all the dc6 organisers are insisting on, but the right to MIT/X11 recordings of presentations too -- not even giving presenters the option to copyleft the recording of their presentation for some reason. BTW, a question: if you say you must make your stuff DFSG-free, aren't you inspiring debate from people who don't want to, or who aren't comfortable with that, on why the DFSG isn't appropriate? If you made it optional or encouraged instead of compulsory, wouldn't that encourage debate on why the DFSG is good in the specific instances where people choose not to use free licenses? Wouldn't that be better? I'd prefer something like this: During and after the conference various materials will be made available to attendees and the general public; submission of a paper thus indicates permission to: * distribute verbatim copies and translations of the paper, slides and other materials provided by the presenter * distribute audio and video recordings of the presentation Presenters are encouraged to provide a specific license (preferably DFSG-free) under which the materials and presentation can be redistributed. Having the video/slide license appear as the first slide at each talk while the introduction's happening might be amusing. But not if it's just the BSD license each time :) Cheers, aj signature.asc Description: Digital signature
Re: please release sarge instead of removing binary firmware
[-devel dropped] On Fri, Apr 16, 2004 at 11:00:08AM +0200, Andreas Barth wrote: * Anthony Towns (aj@azure.humbug.org.au) [040416 10:25]: Because when you have a compile-time dependency you create a derived work -- vmlinuz -- of both the GPLed work and the firmware. Creating derived works is an act covered by copyright, and can only be done with the permission of the rights holder; and if the only permission you have comes in the form of the GPL, then you're required to make available the complete source to the entire derived work. It is not necessarily a derived work, but could also be just a collection of works. (And I consider this to be the case here.) Collections of works are derived works; the GPL has a specific exemption for collections made up of a derived work that's merely aggregated with other works. I don't think it's reasonable to claim that you're merely aggregating the works, when you encode the firmware in hex, and stick it into an array in the source code -- that is, I don't just think that's a questionable enough claim that it shouldn't be relied on, but I think the opposite claim is strong enough that it could be. As far as I can see, the argument that says firmware inserted into a GPLed program isn't affected by the GPL because it's mere aggregation would also have to apply to someone inserting GFDL'ed documentation into a program too, or a non-modifiable image for an icon, or a host of similar things. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ Don't assume I speak for anyone but myself. GPG signed mail preferred. Protect Open Source in Australia from over-reaching changes to IP law http://www.petitiononline.com/auftaip/ http://www.linux.org.au/fta/ signature.asc Description: Digital signature
Re: Request for someone to talk to copyright holders
On Fri, Jan 09, 2004 at 04:52:40PM -0500, Nathanael Nerode wrote: FYI, the copyright holder in this case seems to be SGI. While I generally feel up to contacting individual copyright holders, or even educational institutions, contacting corporate copyright holders is another matter. Even finding the right person to talk to can be a pain in the neck. :-( A good start would presumably be http://www.oss.sgi.com/cgi-bin/mailto . At the very least, whoever's running that ought to know a manager who can get into contact with the appropriate legal staff. I'm pretty sure that the big organisations that're trying to support open source are going to be eager to address our concerns -- and demonstrate their involvement in the community -- although I'm also pretty sure it's going to take a while and some effort to work out a way for them to actually do that. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Request for someone to talk to copyright holders
Hi guys, Bug#211765, xfree86: material under non-free licenses in XFree86 appears to have been languishing for a few months now, without anyone trying to talk to the copyright holders to see if this stuff can be relicensed in a DFSG-free fashion. Is there someone on this list who's interested in talking to upstream copyright holders and trying to work through possible DFSG conflicts like these? That usually means either presenting a convincing argument that what they want is actually more harmful than it seems in practical terms, or that there's some better way of achieving the same goal, without running afoul of the DFSG. That's not particularly easy, and can often be not particularly fruitful, but promoting free software principles to people who're inclined to write non-free licenses is one of the things we're meant to be doing. So, is there anyone here with the time and energy to look into this issue, and ideally others? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: DFSG-freeness issues and sarge-ignore
On Thu, Oct 30, 2003 at 12:41:07AM +1100, Martin Michlmayr - Debian Project Leader wrote: * Branden Robinson [EMAIL PROTECTED] [2003-10-25 18:37]: Can you explain what the policy is for which non-freeness issues *will* be regarded as sarge-ignore? ... It is difficult, from these data, to discern what exactly the policy for sarge-ignore and licensing issues is. I'm afraid I cannot give you an answer to this. As you should know from http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200308/msg00010.html or #97671, sarge-ignore is used and defined by the Release Manager. Or, more canonically: ] Further to this, certain issues may be exempted from being considered ] release critical for sarge by the release manager. This is expressed ] by tagging the report sarge-ignore; this should not be done without ] explicit authorisation from the release manager. ] 1. DFSG-freeness ] ] Code in main and contrib must meet the DFSG, both in .debs and ] in the source (including the .orig.tar.gz) ] ] Documentation in main and contrib must be freely distributable, ] and wherever possible should be under a DFSG-free license. This ] will likely become a requirement post-sarge. -- http://people.debian.org/~ajt/sarge_rc_policy.txt Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda pgp7uOWsAdKAM.pgp Description: PGP signature
Re: Documentation and Sarge's Release Critical Policy
On Fri, Sep 05, 2003 at 06:40:53PM -0400, Walter Landry wrote: Given that you were misinformed about the FSF's intentions [1] [...] [1] http://lists.debian.org/debian-legal/2003/debian-legal-200308/msg01323.html I try to be very careful about what I write. The intentions weren't the FSF's, and they certainly weren't Stallman's; they were that of some members of the FSF. I realise -legal has entered into Let's rant and rave and be as uncooperative as possible mode, which might make the above somewhat pointless, but hey, it's a free country, right? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpwnROh0e6nV.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Thu, Sep 04, 2003 at 02:48:29PM -0500, Branden Robinson wrote: Ah, so in general, when people find a flagrant DFSG violation in main, the best thing they can do is just leave it alone. Otherwise, it's a change, and past inclusion is always sufficient present for future retention. No, the best thing to do is to *contact the upstream copyright holder*. That's true whether it's flagrant or not, and given neither myself nor the glibc maintainers are convinced, it's hardly clear that it is. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Re: Bug#181493: SUN RPC code is DFSG-free
On Tue, Aug 26, 2003 at 03:15:05PM -0500, Branden Robinson wrote: You ground your argument on second hand reports of clarifications in the first quoted paragraph, but then expect debian-legal to furnish first-hand clarifications? Yes. If you're too lazy to be bothered doing that, don't expect anyone else -- either the release manager nor the glibc maintainers -- to care about your ravings. The burden of proof is on those who claim it's been clarified to come up with evidence of such. No, the burden of proof is on those who advocate a change, and it's not been met. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpYCtmvciPsp.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
On Tue, Aug 26, 2003 at 09:36:13PM +0100, Andrew Suffield wrote: You're invited to demonstrate an instance of someone coming up with the exact same expression of the exact same copyrightable idea being sued for copyright infringement and winning on the grounds of independent reinvention. For bonus points make it an instance where they had access to the original work. I'll have to pass on this one, as I've never heard of anybody being sued for this at all, but I counter-invite you to come up with an example of anybody coming up with the same expression of the same copyrightable idea being sued for copyright infringement and *losing*. Every copyright case that's lost by the defendents is an example. That's the point: if you come up with the exact same expression, then either you've copied, or there's a lack of originality in the work to start with. I don't think any case law exists (or ever will exist) on the subject, so we'll have to work with the statutes - which, at least in the US and EU, are fairly clear that independant innovation is a valid way to avoid copyright issues. No, independent innovation is a valid way of *gaining* copyright on a work. The way you demonstrate it's independent from other works, is by demonstrating it's *different* to other works. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp62NKCclbZ3.pgp Description: PGP signature
Re: Bug#181493: SUN RPC code is DFSG-free
On Mon, Aug 25, 2003 at 01:26:22AM -0700, Don Armstrong wrote: On Mon, 25 Aug 2003, Andreas Barth wrote: So, this license is specific to be used only as part of a product or programm. You're missing the key phrase on which Branden's argument (and mine) is based on: 'developed by the user' This phrase read conservatively ...is not the author's intention, as indicated by second hand reports of clarifications (BSD, but can't use the original literally) by the copyright holder, and the copyright holder's (lack of) response to copious reuse and redistribution. As far as L/GPL incompatibility is concerned, you'll note that Sun, the copyright holders, specifically offer Linux systems that include glibc with GPLed applications, and an LGPLed libc, to their customers. See http://wwws.sun.com/software/linux/index.html . If anyone on -legal believes clarifications are necessary or would be helpful, please feel free to get them from Sun. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp0LDoL0Tf8r.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
On Mon, Aug 25, 2003 at 11:51:49AM +0100, Andrew Suffield wrote: On Mon, Aug 25, 2003 at 04:03:20PM +1000, Anthony Towns wrote: Nor is Not being able to change it to look exactly like `solitaire.exe', but you can't do that, either. And yet we can still distribute lots of things that you can change to look exactly like `solitaire.exe' under the terms of the GPL. This is essentially false, as Branden has already commented. (Unless you happen to live in one of those freaky countries where copyright behaves like patents, but I think we'll have to ignore them) You're wrong, and we'll ignore anywhere where you may be right. Nice to see we're working towards consensus. You're invited to demonstrate an instance of someone coming up with the exact same expression of the exact same copyrightable idea being sued for copyright infringement and winning on the grounds of independent reinvention. For bonus points make it an instance where they had access to the original work. Personally, I consider the possibility of anyone being able to get away with a defense of that form exceedinly unlikely. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpNIzMNiSjRM.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
On Sun, Aug 24, 2003 at 07:33:41PM +0100, Andrew Suffield wrote: Now, translating this back to the sunrpc case: But that means you can't distribute the end product under the terms of the GPL, which include (in part 2) the ability to make modifications only taking into account a few random things. Not being able to remove everything but the sunrpc code isn't one of them. Nor is Not being able to change it to look exactly like `solitaire.exe', but you can't do that, either. And yet we can still distribute lots of things that you can change to look exactly like `solitaire.exe' under the terms of the GPL. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpFzJqyDaI8N.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
On Sat, Aug 23, 2003 at 06:27:08PM +0100, Andrew Suffield wrote: And their intentions are: MIT/X11, except you may not distribute this product alone. I'm not particularly convinced it's not compatible with the GPL, either. If you're trying to distribute the product alone, then the GPL has absolutely no relevance. If you're distributing it with something, GPLed or not, then it's apparently the same as MIT/X11, which is GPL compatible. [If this were valid, then the GPL wouldn't be incompatible with the Artistic license either]. No, that's not the case, since the Artistic license isn't MIT/X11, except you may not distribute this product alone. An abbreviated form of the so-called viral part of the GPL says that everything you include in a GPLed work must be distributable under the GPL. This isn't quite accurate: it says that it must be distributable under the terms of the GPL. That is, if you follow the requirements of the GPL, then you're also obeying the requirements of whatever the actual license is. Therefore, in order to link a GPLed application with glibc, I need to be able to distribute the source code to glibc under the GPL as well. Again, under _the terms of_ the GPL. From this I can conclude that I need to be able to distribute any given component of the glibc source code under the GPL. Which isn't correct. You need to be able to distribute the end product under the terms of the GPL, which you can; the original parts don't matter, since if you're distributing those, you're not bound by the GPL at all. Consider, as another example, the following program: #!/bin/sh # Capital-AJ version 1.0 # Copyright (c) 2003 Anthony Towns [EMAIL PROTECTED] # All rights reserved find /foo -type f | grep 'aj' | while read a; do x=`echo $a | sed 's/aj/AJ/g'` mv $a $x done and the following derivative: #!/bin/sh # Capital-AJ version 1.1 # Copyright (c) 2003 Anthony Towns [EMAIL PROTECTED] # May be freely used/copied/etc under the terms of the GNU GPL v2. export LANG=C word=$1 if [ $word = ]; then word=aj fi worduc=`echo $word | tr a-z A-Z` find /foo -type f | grep $word | while read a; do x=`echo $a | sed s/$word/$worduc/g` mv $a $x done Version 1.1 and third party derivatives are clearly under the GPL, but that doesn't mean you can use it to make a copy of version 1.0 that's under the GPL, any more than you can start with a blank page and convert that to a copy of version 1.0 without violating copyright. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpFKYpVp3q7o.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
a GPLed program, and a set of modifications which you were not permitted to make - by implementing them and licensing them differently. Except that they're not allowed to do that, because you can't change a GPLed program and license it differently. For BSD programs, Microsoft have already done such a thing: it's called Windows, and includes a number of modifications to certain BSD code that can't be made by anyone else. Fortunately copyright law is mostly about expression, rather than ideas, and it's usually easy to express the same idea differently, making this a non-issue. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpKsRMxSGU8F.pgp Description: PGP signature
SUN RPC code is DFSG-free
Hello, This explanation is unsatisfactory. I think that the Sun RPC code is non-free, and I want an opinion from debian-legal. The Sun RPC code is DFSG-free, and has been for eons. This bug is, again, closed with this message. Addressing particular concerns raised: that this legend is included on all tape media and as a part of the software ^^ That seems worse than the advertising clause. If it were referring to all tape media everywhere, perhaps it would be. That's not a reasonable interpretation, however. If it limited it to being written on the casing of the tape media, rather than encoded on the media itself, perhaps it would be too, but it doesn't. Isn't this whole thing incompatible with the (L)GPL anyway? The code in question has been highly modified and integrated into the glibc source tree, presumably with the modifications under the LGPL, It's not appropriate to presume so as to make things illegal. If there's a valid interpretation that makes things legal, then that should be the default. Only if there are no such valid interpretations, or if the copyright holder states their interpretation, is it appropriate to worry about this. I'm personally concerned about this particular phrase, as it seems to preclude Debian from distributing software with Sun RPC in it unless Debian itself is developing the product or program using Sun RPC. Which we are, viz The Debian Distribution. A distributes a program developed by A based on Sun RPC to B. B cannot turn around distribute the program to C unless they repackage it as a product or program developed by B. This isn't the case: A may license or distribute it to anyone [..] as part of a product or program developed by [A], and thus may provide a license to all comers, including C. Sun has repeatedly clarified elsewhere that the intent of this is essentially MIT/X11, except you may not distribute this product alone. Not being able to distribute the original Sun RPC code alone is not a problem, so long as we're able to distribute any variants of it that we may actually want. If you're really concerned about other possible caveats, please feel free to contact Sun to work on getting a clarified license. However as it stands, the license passes the DFSG at least as well as, eg, the Artistic license does. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpl9VlSAKDyq.pgp Description: PGP signature
Re: SUN RPC code is DFSG-free
On Sat, Aug 23, 2003 at 11:49:47AM +0100, Andrew Suffield wrote: On Sat, Aug 23, 2003 at 06:50:19PM +1000, Anthony Towns wrote: Isn't this whole thing incompatible with the (L)GPL anyway? The code in question has been highly modified and integrated into the glibc source tree, presumably with the modifications under the LGPL, It's not appropriate to presume so as to make things illegal. Sun has repeatedly clarified elsewhere that the intent of this is essentially MIT/X11, except you may not distribute this product alone. The copyright holder has, apparently, stated their intentions. That's not the copyright holder whom you're presuming for. And their intentions are: MIT/X11, except you may not distribute this product alone. Are you seriously suggesting that this is *not* an additional restriction over those made by the (L)GPL? I'm not particularly convinced it's not compatible with the GPL, either. If you're trying to distribute the product alone, then the GPL has absolutely no relevance. If you're distributing it with something, GPLed or not, then it's apparently the same as MIT/X11, which is GPL compatible. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpY2vq5L1gOf.pgp Description: PGP signature
Re: Documentation and Sarge's Release Critical Policy
On Wed, Aug 20, 2003 at 02:38:36PM +1200, Adam Warner wrote: I believe this comment is a mischaracterisation of the consensus that has developed on this list. Recently explained by Nathanael Nerode on the glibc mailing list: http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00160.html My next post to -devel-announce will discuss some of these finer details. In short, some members of the FSF have asked for us to give them some more time to come up with a GFDL that's DFSG-free before we go all gung-ho about putting it in non-free and having bigger controversies. Martin (wearing his DPL hat) talked to me about this at debcamp. Given there's more ambiguity in whether to apply the DFSG to documentation than there is in whether the GFDL passes the DFSG, it seemed most sensible just to exempt documentation from the DFSG for sarge; so that's the policy. I in no way support any claims that clear majority agreement has not been reached. So in this respect sarge_rc_policy.txt should at least read: This will become a requirement post-sarge. It'll presumably change after sarge -- which is why I've been leaving the bugs marked serious and just adding sarge-ignore tags -- but there's no point making that decision before we have to. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpTG4CAruekC.pgp Description: PGP signature
Re: Knoppix and GPL
On Thu, May 08, 2003 at 05:25:02PM -0700, Thomas Bushnell, BSG wrote: 3) Would anyone be willing to help with souch a complaint? Send it to the FSF's gpl enforcement team. I'm lost. Why are we arguing and going to enforcement teams instead of just offering to host the Knoppix source on some debian.org machines? Given most of it is already part of our archive, that no one seems to have a problem with the source being available, and that, whatever else it may be aside, Knoppix seems to be good advertising for Debian it seems like a polite, friendly, logical, win-win, sort of thing to do... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpVZ2M7ac6Nx.pgp Description: PGP signature
