Re: Is public domain software DFSG-compliant?
Is public domain software DFSG-compliant? Sorry if this is a FAQ; Actually it sort of is, albeit in an unofficial one. http://people.debian.org/~bap/dfsg-faq.html#public_domain Googling DFSG public domain FAQ snags it. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.nuim.ie/~barak/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPL or any greater version (was: NEW ocaml licence
http://people.debian.org/~bap/dfsg-faq.html Yuck. If I might reinterpret your comments a tad more abstractly, I take it you're saying that the document exceeded the mandate of its title, since it discusses free software license issues in general; and that it has insufficient global structure. Is that right? These both seem like reasonable points. It does seem reasonable to try to address common Debian-relevant license-related questions in one document, including both questions about the DFSG itself and about the penumbra of license-related issues. So I changed the title to try to make it a bit broader! Lack of global structure is a problem, and I'd very welcome someone else making a serious editing pass---especially one that tried to impose a coherent global structure on beast. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: GPL or any greater version (was: NEW ocaml licence proposal)
In reaction to this thread I have added an item to address this question to http://people.debian.org/~bap/dfsg-faq.html which I believe summarizes the consensus here, as well as the expressed opinion and intent of the FSF regarding the or later clause. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: oaklisp: contains 500kB binary in source
Marco Franzen writes: ... Bootstrapping [using an Oaklisp interpreter written in Scheme] might fail because an Oaklisp-specific feature of the target system is subtly implemented by the same feature in the host system ... Right, then you would have to do this thing called debugging, in order to identify and repair any innocent incompatibilities in your interpreter. Stepping back a bit, maybe the question is, which side has the burden of proof? Absolutely. You are worried that there might be a self-reproducing monster hiding inside an apparently innocuous and seemingly easily regenerated file. Therefore the burden of proof is on you. After all, it is impossible to prove a negative. I have suggested various technical measures you might wish to take to help flush any such scary invisible monsters out of hiding. Go for it! -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: oaklisp: contains 500kB binary in source
If glibc binaries really had virus that were not it its source, and if that could have been avoided by more painful bootstrapping, would that mean clean oaklisp bootstrapping should not be required? Right. And if my grandmother had wheels and a gas tank she would be an automobile. All new languages need a bootstrap path. People often write a compiler for language L in L itself, for a variety of good reasons, not least of which is eating ones own dog food. Oaklisp is typical in this regard: the Oaklisp byte code compiler and run time system are written in Oaklisp. Therefore you need to have an Oaklisp system available in order to rebuild the system from scratch. As a convenience, someone ran the bootstrap process half-way and included the results in the Oaklisp source package, to make porting easier. But you are free to regenerate the system completely from scratch if you so desire. You can examine the source for trojans, you can examine the pre-built binaries, you can regenerate the pre-built binaries, you can instrument the bytecode interpreter and check that nothing unsafe is being done, you can verify the system to your heart's content. You can write your own Oaklisp interpreter and use it to run the Oaklisp compiler from source on itself and check if the generated bytecode matches the pre-compiled bytecode included in the source package; the source includes a interpreter and it would be a relatively small matter to translate it from Oaklisp into RnRS Scheme. All source is available: if you have any doubts at all you are ideally situated to verify the system's integrity. You might also want to check gcc and clisp and cmucl and various other self-hosted language implementations and for trojans or other integrity violations. This would make a nice technical report: Practical Experience with Integrity-Checking of Self-Hosted Language Implementations by Marco Franzen. This is all, however, quite irrelevant to debian-legal. Many Debian source balls contain derived files to ease building, such as Makefile.dep or config.sub files. The situation here is no different. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
FAQ Improvements (was: license change for POSIX manpages)
... for the manpages to be Free, you should be able to use them for totally non-POSIX purposes, and with the clause as written, it seems that you can't. ... be a recurring blind spot in people who think they're writing free licenses; they only consider the most common reason for making derivative works of their work, and accidentally prohibit or put ridiculous restrictions on making other derivative works. Perhaps it deserves a FAQ? Good idea. Please feel free to modify in place ~bap/public_html/dfsg-faq.html on people.debian.org and I will examine and CVS commit. Or, send me a patch. This also goes for other improvements to the document. --Barak. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: oaklisp: contains 500kB binary in source
This is a technical issue related to ease of bootstrapping on a new architecture, and not a legal issue. As a technical measure, the circular dependency could be broken and the alternative prebuild-world-in-source kludge eliminated by writing an Oaklisp interpreter in another language (say, RnRS Scheme, or Haskell) for invocation when an already-built Oaklisp is not available on the build platform. I'm absolutely positive the upstream maintainer would welcome any such patch. But, this has nothing to do with the legal status of the package. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: Which license for a documentation?
This is not the first time that this has come up. Perhaps there could be a FAQ at www.debian.org/legal? Great idea. Perhaps the draft FAQ I started could be moved? http://people.debian.org/~bap/dfsg-faq.html (Just added this question to it.) It is in pretty good shape, with contributions from many people, and I think represents a rough consensus view with no glaring flaws. I'd welcome its being taken over by the Debian www team, or whatever. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: Legal question about a [EEG head] model
Dear Dr. Rutschmann, You recently mentioned on debian-legal, concerning a package for EEG data processing, The software is totally under GPL but ships with a graphical head-model that is confined to the use with tempo itself. (And this model is needed) May I ask what kind of a head model this is, exactly, and what requirements a replacement would have to meet? I'm involved with EEG/MEG/FMRI, and it is possible we could round up a suitable dataset and massage as appropriate. (Eg: MRI-based anatomy converted to 1 triangle finite element model with co-registered EEG electrodes in standard 10-20 positions along with the most common fiduciary points.) Suggestion: in the meantime, how about just shipping it with a simple three-layer spherical head model? Even if you add a fancier model later, it is nice to have a spherical head model available for making standard-looking figures, for comparison, and for replication. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: [Fwd: Re: Since you designed the Debian 'swirl' logo...]
Given the intransigence at the other end, and the clarity of the situation, shouldn't this issue be bumped over to SPI? It seems like it is part of SPI's mandate to arrange for lawyers to send threatening letters and to follow up on them as appropriate. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: procedural issues [OT]
Um, I wasn't disagreeing, just clarifying. I don't think this particular discussion is at the point. I do think that the issues are mostly on the table. Not 100% though. Also a lot of fun invective, which doesn't bother me (especially when posted by well-known donkey fellatiors) but may inhibit the participation of others, especially if they don't have any substantially new lines of reasoning to suggest. Discussions on debian-legal sometimes peter out when they're not grounded in some particular decision that has to be made, as is the case here due to the release manager's GFDL proclamation.
Re: Official Logo is not DFSG Free (with patch)
On Fri, 03 Oct 2003, Jaldhar H. Vyas wrote: I'm reopening this bug because the official logo is non-free. [It fails multiple parts of the DFSG, including #1, #3, #6, #8... the list goes on.] The list is irrelevant as the applicability of the Debian Free _Software_ guidelines to graphical images is even more dubious than its applicability to documentation. Please don't confuse a really minor and rather technical debate with basic Debian policy. There is no question that the DFSG applies to software including documentation, and hence any images that appear in said materials. If an official use only corporate logo were released under a license that required the addition of a based on or unofficial across it when used on a modified version of something, we might allow it by analogy with the must rename licenses which we grudgingly accept. But that's not the situation with the official Debian logo. You might also feel that Debian is being inconsistent in that we distribute things on our web site that we won't distribute on CD images. True enough. RMS seems to thinks it's pretty weird.
Re: snippets
Cameron Patrick [EMAIL PROTECTED] writes: ... intentionally not upholding the social contract by knowingly distributing non-free snippets ... Let me see if I have this straight. Are you actually claiming that a particular paragraph of text in a removable README file would be a violation of the social contract, while that EXACT SAME PARAGRAPH in a COPYING file would not be?
Re: snippets
Joel Baker [EMAIL PROTECTED] writes: (frankly, I'd be fine with it being unmodifiable *but removeable*, and distributing it thus, since anyone who cares *can* remove it, still). Um, isn't that precisely what we're talking about?
Re: snippets
Joe Wreschnig [EMAIL PROTECTED] writes: One of the reasons I like Debian is because the maintainers care about stuff like this. I'm assured that free means *totally* free, all of it, even when upstream ships non-free software (including dingleberries). I didn't agree to the SC only when convenient for me as a packager - I agreed that Debian Will Remain 100% Free Software, regardless of the work it takes me. Well of course. No one involved in this discussion disagrees with that! No one (except RMS) is proposing to allow non-free software, including documentation, into Debian. That is completely outside the scope of this discussion. Beyond the pale, as it were.
Re: snippets
Joel Baker [EMAIL PROTECTED] wrote: (frankly, I'd be fine with it being unmodifiable *but removeable*, and distributing it thus, since anyone who cares *can* remove it, still). Um, isn't that precisely what we're talking about? After all, to tie threads... all Invariant Sections in a GDFL work are secondary, by definition (and, frankly, usually by practice) - if the FSF doesn't want to allow their removal, much less modification, why should we assume that Joe Random Author who explicitly puts a protective license on it is actually fine with it being removed, but not modified? I don't think there is any debate about whether non-removable material of any sort is okay: it is not. We give it a pass when it is license-related, like patent-grant letters containing anti-GPL flames, but at some point I imagine we'd draw the line even there. Also unmodifiable software including interfaces or documentation: not okay, obviously. The whole idea of snippets was that by definition they are removable. Basically, I was trying to express a bit formally the kinds of material which we've never worried about or had problems with in the past. The kinds of materials which I *think* you meant when you wrote I'd be fine with ...?
Re: snippets
I wrote: ... we won't go on a snippet witch hunt, but we also won't encourage snippets or even really talk about them. That would be my preference. Branden Robinson [EMAIL PROTECTED] replied: I fail to see how this [argument] substantially differs from the one I already made: Well this is good. So we'd agree that, as a practical matter, we should not file bugs about snippets, not worry about them, not talk about them, and just leave snippet-related issues to the discretion of individual package maintainers. This is how I'd describe what we've done in the past, so if you think that is a continuation of current and historic Debian practice then we agree about that as well. If that is a fair summary, I think we can declare this thread closed! Truly a happy day in debian-legal.
Re: snippets
I'm sorry, I really didn't mean to put words in your mouth. I thought that was what you were saying. You seem to be proposing that we deliberately close our eyes to DFSG problems we may encounter, as long as the problem encountered is small. That is not my position! As I hope you would know. I would never close my eyes to a DFSG problem. All our software must be free: modifiable etc. That is a given. The items under discussion are not software in the usual sense of the term. They're little bits of history and such, like the imaginary sister-cancer-email README file or /usr/share/emacs/21.2/etc/WHY-FREE. Unlike a Changelog they are not helpful for understanding the source code itself, ie not documentary. However we do allow grow-only Changelogs (even though I don't much approve of the idea, as I doubt many of us do), so you might find some similarity there. You might think of snippets a little like that. Those grow-only Changelogs are generally removable, although I'm not sure if we actually require that. But the snippets under discussion here are always removable.
Re: snippets
The difference that I see boils down to this: while it might be morally upstanding and forthright to investigate every file in every package for the licensing terms and make sure that they are, in fact, 100% Free Oats, this is a task of such size and scope as to be impractical to accomplish in the short term. I think people are underestimating a couple things: - the lack of benefit of removing snippets (so far no convincing practical advantage of removing them has been forthcoming. The best argument made was translations but as others have pointed out that's a pretty weak argument.) - the enormous number of snippets. I would be surprised if fewer than 10% of our source tarballs contain snippets. Maybe a lot more. - the difficulty of finding them. enormous task. - the difficulty of removing them when found. + removing them in a patch file, or not putting them in the binary, is not enough! since they are not part of the software, whatever property they have that makes us unwilling to distribute them applies equally to distributing them inside source tarballs. Currently we to my knowledge have one (1) package containing dingleberries, which I will define as materials that we feel must be removed for license reasons from the upstream tarball in order to make the debian .orig.tarball. This is the linux kernel, which contains binary firmware sans source which must be removed. As the kernel packagers will I'm sure confirm, that is a pain in the tush. Now imagine that 10% of debian source packages had dingleberries in their upstream tarballs. And not just one dingleberry, but often a couple. Changing with time. This would be a logistic nightmare. For one thing, our mechanisms are not set up to support dingleberry removal. So new mechanisms would be needed all over the place: .../debian/clip-from-upstream files listing them, probably the list would need to go into the .dsc files in order for cvs-upgrade to work properly, etc. All kinds of confusion would ensue, as people wonder why so many of our pristine source tarballs differ from the actual upstream source tarballs. We don't update the .orig.tar for a debian version rev, so fixing one of these bugs would require mechanism changes too, so the .orig.tar could be fixed (dingleberry removal) without reving the upstream version number. Or some other way of achieving the same ends. Any way you slice it, we're talking major disruption just in infrastructure and procedural changes. + lots of bickering would start to happen, as people complain about missing snippets. upstream authors would get pissed off: why did you take out the heartfelt email from my dead sister? i want it in to help inspire other to join me in this great endeavor to fight cancer! Urkle. response: well put it back with the stipulation that anyone can edit it a little to make their own heart-rending email. Then i will put it back and not change it but other people might. Yeah right. It's his dead sister dude! + many patch files would be incompatible, and we'd have to deal with these manually all the time. - the problems with double standards + if we remove snippets (ie consider them dingleberries) whenever we find them, then some will be removed and others won't. This will engender a sense in people that we hold different upstream sources to different standards. Since this is proposed as an anyone who notices kind of thing, rather than a maintainer's discretion kind of thing, having politically astute maintainers with good upstream relations, who try not to subject their own packages to scrutiny beyond the level other packages enjoy, won't help. + we allow political commentary and such as part of licenses, and in license-related files like letters from sleazy corporate lawyers grudgingly allowing use of their software patents. people will figure this out, and start bloating out their licenses with the materials they used to put in snippets. (Then they'll be unremovable, so they won't be snippets anymore.) So we'll be applying a double standard in which if someone is nice, and includes their dead-sister-cancer email in a removable REAME we go ahead and remove it, but if they bloat out their COPYING file with it (ugh!) we leave it in. how very clever of us, to sacrifice our current ability to remove the snippets when we don't like them, while leaving a mechanism by which they can be included without our ability to remove them. certainly that would be a major victory. + license bloat proliferation: due to the above double standard wrt political text in licenses, pretty soon
Re: begging the question
Andrew Suffield [EMAIL PROTECTED] writes: Your thesis contains two contradictory points. Branden has responded to one of them, citing the other, and pointed out the contradiction. That is the entire point of his question. The two points that are in conflict are: 1) These works were intentially included in Debian as a result of conscious choice on the part of developers 2) Identifying these works in order to remove them would be prohibitively expensive in its use of time. These are not in the least contradictory. Let me make an analogy. Let's say we have a barrel of oats with some chocolate sprinkles mixed in. Sifting through and removing all the chocolate sprinkles would be a lot of work. But knowing that there are some chocolate sprinkles in there (that no one ever worried about or had any problems with) is not a lot of work. This is especially true when the barrel of oats was created by pouring together hundreds of bags of oats created by others and many of those upstream bags contained chocolate sprinkles.
snippets [was Re: begging the question]
Dagfinn Ilmari Mannsaker [EMAIL PROTECTED] writes: The problem is that Debian has made an explicit promise that it will remain 100% Pure Oats ... We're getting into semantics here, to some extent. The DFSG talks about software. It is referring to software as the term is usually understood in our field, as in phrases like software engineer, software tools, and software company, ie computer programs and their penumbra of support files, documentation, examples, etc. A whole bunch of these, combined and integrated to form a coherent operating system, is what Debian produces. No one has shown any evidence that the interpretation you're drawing (in which Debian should laboriously find and purge itself of things like a README.why file in which an author quotes heart-rending email from his sister who dies of cancer and explains how this motivated him to study molecular biology) is widely held within Debian, sensible, or practical. Debian has, since day one, included such snippets. Many upstream tarballs contain them. The phrasing of almost all license boilerplate (eg the GPL boilerplate) allows them. They have never caused the least bit of trouble or controversy. They are causing controversy now, it seems to me, only because people got so riled up about the GFDL that they've confused the consensus non-removable XXXs are not allowed with the much stronger no XXXs are allowed. The former is the reason we all agree that the GFDL's invariant section clauses are quite unacceptable. The latter, in contrast, would involve a *change* to the status quo. I'm advocating calming down, not worrying about it, and certainly not filing a zillion bug reports about every quoted email or revealingly personal readme in the whole distribution. And I'm advocation not pretending that there is some kind of consensus that snippets are not allowed, when no such consensus exists. ... Should we ignore the needs of users who have chosen Debian based on this promies (sic) because they are allergic to chocolate? The chocolate sprinkles metaphor is showing its limitations here. These are properties that snippets cannot have. Including the README described above does not ignore the needs of our users. Or at least, if it does you need to show how. (I'm including this to try and keep the discussion on-topic, so fewer people will go off on strange irrelevant rants about xroach and such.) *** BY MY DEFINITION: *** *** A snippet is a file in a source tarball which: *** *** - MERELY ACCOMPANIES and is not an integral part of the source *** - is REMOVABLE *** - is NON-FUNCTIONAL (not code, not documentation, not needed for build) *** - is NON-TECHNICAL in nature *** - is usually of historic, humorous, or prurient interest *** - is usually NOT itself MODIFIABLE, eg may redistribute verbatim *** - is very SMALL compared to the technical material it accompanies *** *** (examples of such snippets are historic or humorous emails and *** usenet posts and the like.)
Re: snippets
Branden Robinson [EMAIL PROTECTED] writes: Unless you can find some evidence in the -private archives that the GNU Manifesto was specifically mentioned and a conclusion reached, I I do agree that history, and precedent, and the practices of others, are a weak guide. But we should not ignore them entirely. In any case, you're trying to put the burden of proof on the snippets are okay view. But you would agree, I hope, that we do have lots of snippets, and that no one has ever had a problem with or objection to them before. Since not purging them is current practice, the burden of proof really is on you to show a compelling reason for purging them, instead of just retaining the relaxed attitude about them that we've had to date. If it makes you feel any better, we could call it don't ask don't tell, in that we won't go on a snippet witch hunt, but we also won't encourage snippets or even really talk about them. That would be my preference.
Re: snippets [was Re: begging the question]
Nathanael Nerode wrote: Barak Pearlmutter wrote: The phrasing of almost all license boilerplate (eg the GPL boilerplate) allows them. Nothing licensed under the GPL can be non-modifiable. So I'm not sure what you mean by this Okay, it's a rather technical point. If you look at the GPL's boilerplate, ie the stuff in the instructions at the bottom of /usr/share/common-licenses/GPL-2 that you're supposed to paste into your own program when you release it under the GPL This ***PROGRAM** is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by or have your employer sign if they hold the copyright Yoyodyne, Inc., hereby disclaims all copyright interest in the ***PROGRAM*** `Gnomovision' (which makes passes at compilers) written by James Hacker. (emphasis mine, of course) you'll notice it refers to the program. So these do not imply that snippets in the tarball are under the GPL, because they aren't in fact part of the program. In other words, it is not a contradiction to put my canonical README.sister.cancer.molbio in the tarball with a biosequence alignment program which is GPLed with all the usual boilerplate, because the boilerplate only applies to the program itself (broadly construed of course) and not a snippet like README.sister.molbio. (I'm including this to try and keep the discussion on-topic, so fewer people will go off on strange irrelevant rants about xroach and such.) *** BY MY DEFINITION: *** *** A snippet is a file in a source tarball which: *** *** - MERELY ACCOMPANIES and is not an integral part of the source *** - is REMOVABLE *** - is NON-FUNCTIONAL (not code, not documentation, not needed for build) *** - is NON-TECHNICAL in nature *** - is usually of historic, humorous, or prurient interest *** - is usually NOT itself MODIFIABLE, eg may redistribute verbatim *** - is very SMALL compared to the technical material it accompanies *** *** (examples of such snippets are historic or humorous emails and *** usenet posts and the like.)
Software in common discourse in 2003
The word software as used in general discourse is quite specific.
Examples: software engineer, database software, software
development tools, Free Software Foundation, software market,
proprietary software, real-time software, software productivity
metrics, software testing, etc. To whit: computer programs,
usually including their penumbra of support files and documentation.
This is what dictionaries say:
$ dict software
From WordNet (r) 2.0 (August 2003) [wn]:
software
n : (computer science) written programs or procedures or rules
and associated documentation pertaining to the operation
of a computer system and that are stored in read/write
memory; the market for software is expected to expand
[syn: {software system}, {software package}, {package}]
[ant: {hardware}]
From The Free On-line Dictionary of Computing (17 May 2003) [foldoc]:
software
programming (Or computer program, program, code) The
instructions executed by a computer, as opposed to the
physical device on which they run (the {hardware}).
wikipedia:
Computer software
(Redirected from Software)
*Software* is a generic term for organized collections of computer
data and instructions, often broken into two major categories:
system software that provides the basic non-task-specific
functions of the computer, and application software which is used
by users to accomplish specific tasks.
In some technical circumstances software can be used in the much
broader sense of essentially all information. But that is a rare and
technical definition. If used in general discourse it results in
silliness like movie directors being considered software engineers
because after all they're producing bits.
Slipping between two definitions can be used to perform a rhetorical
trick: first get agreement that All X's are Y's under the common
definition of X, then change the definition of X and carry over the
earlier agreement using the new definition. For instance criminals
should be put in jail. Now expand the definition of criminals...
In order to avoid such falacious reasoning, we should be particularly
careful about slipping between the common vs the all-expansive senses
of the word software.
begging the question
Branden Robinson [EMAIL PROTECTED] wrote: On Sun, Sep 28, 2003 at 12:22:31PM -0600, Barak Pearlmutter wrote: Scanning all our packages for such snippets would be a truly gargantuan task. And yet at the same time you claim that the inclusion of any particular such snippet was a fully conscious decision made at the time the Social Contract and Debian Free Software Guidelines were adopted. Have you any evidence that this truly gargantuan task was undertaken back then? You undermine your own argument. When we find non-DFSG-free materials in main, we should remove them, or request their relicensing. Why was this begging the question? First (as a comment on a completely tangential portion of the train of logic you're responding to) you say that somehow not doing something now is a lot of work because it was more work to not do it in the past. If we'd known we were doing it, so we must not have known. Which would be a lot of work. Or something like that. Then you state your conclusion. Or premise, it's hard to tell. But you seem to find the conclusion you advocate so patently obvious---as obvious as the fact that the people who edit movies are software engineers because movies are digital now and hence software following our brave newspeak general-purpose all-encompassing definition of software---that it requires no support, mere restatement.
begging the question
PS I should add that your begging the question message was quite uncharacteristic, in that --- right or wrong --- your logic is generally apparent and your exposition cogent and lucid.
Re: Respect for Upstream Authors and Snippets of Interest
Jan Schumacher [EMAIL PROTECTED] writes: Fair enough. However, all of these statements are removable, and their modification is probably not prohibited by the license. The flow of the argument was: one example of Debian's respect for upstream authors is not removing these requests and offers. If they were unremovable, this would have made a poor example. If they are also modifiable, then they are most likely also DFSG-free by the strictest interpretation. I don't think anyone has argued to remove such texts. You seem to be having trouble following this. Again, I was referring to unmodifiable but removable snippets. Like a copy of the heart-rending email from his cancer-stricken sister that inspired an upstream author to study molecular biology, work on colon-cancer oncogenes, and write a biosequence-processing program, which is being packaged for Debian. Stuff like that. Stuff that is not modifiable, of interest, reasonable to include, not code, not documentation, not technical in nature, not part of the program but merely accompanying it, and small compared to the technical thing it accompanies. Stuff whose removal would often impoverish our understanding of the circumstances of a work's creation. De-facto, we allow such snippets in Debian. It would be reasonable to discuss whether this informal but longstanding policy should be changed. But that would be new separate topic, which (if we choose to discuss it) should be divorced from attempts to resolve the GFDL question. It would also be a highly controversial proposal, and its consequences would be far-reaching. No upstream source eschews such snippets, and no other free software organization has any problem with them. Scanning all our packages for such snippets would be a truly gargantuan task.
snippets [was Re: Respect for Upstream Authors and Snippets of Interest]
Most non-DFSG-free materials that we find in main are there because
they were overlooked. I see no reason to suspect the GNU Manifesto
of being any different.
I think you're wrong about that. Most Debian developers have, I
suspect, read the GNU Manifesto. Its unmodifiable status is not
hidden. Most Debian developers (excepting those unfortunate vi
knuckle-dragger in our midst) know that it can be found down in the
gizzards of the emacs support files. But Debian is full of snippets,
and no one has ever raised them as an issue before. The burden of
proof is really on you here, to show that this was all just some big
inadvertent mistake.
Anyway, I'd like to re-frame this slightly, in order to keep the
discussion focussed.
Okay, I know you understand this, but in order to be clear to others:
*** BY MY DEFINITION:
***
*** A snippet is a file in a source tarball which:
***
*** - MERELY ACCOMPANIES and is not an integral part of the source
*** - is REMOVABLE
*** - is NON-FUNCTIONAL (not code, not documentation, not needed for build)
*** - is NON-TECHNICAL in nature
*** - is usually of historic, humorous, or prurient interest
*** - is usually NOT itself MODIFIABLE, eg may redistribute verbatim
*** - is very SMALL compared to the technical material it accompanies
***
*** (Good examples of such snippets are historic or humorous emails
*** and usenet posts, political essays, jokes, and the like.)
First, let's divorce this discussion from the GFDL. Separate
question, separate topic.
The GNU Manifesto is such a snippet, in all the {GNU ,x}emacs
packages. But I'd rather use a pretend example in order to clarify
that we're not talking about the GFDL anymore, or RMS or the FSF. So
let's use a copy of the heart-rending email from his cancer-stricken
and now deceased sister that inspired an upstream author to study
molecular biology, work on colon-cancer oncogenes, and write a
biosequence-processing program which is packaged for Debian. It is
typical to find such snippets in upstream tarballs, and to include
them in /usr/share/doc/whatever/. I'm talking about stuff like that.
Stuff that is not modifiable, of interest, reasonable to include, not
code, not documentation, not technical in nature, not part of the
program but merely accompanying it, and small compared to the
technical thing it accompanies. Stuff whose removal would often
impoverish our understanding of the circumstances of a work's
creation, and of the work's author.
If we decide to go on a crusade against them, it would be a really big
deal for a couple reasons:
- Debian is absolutely *rife* with such snippets.
- This is because upstream tarballs are absolutely rife with them.
- It would be a major change in practice.
- Scanning our sources for them would be a gargantuan undertaking.
- No other free software organization eschews such snippets.
- They'd keep sneaking back in.
Furthermore, snippets have not caused any *problem*. We have free
software because non-free software sucks for various reasons. Think
of the RMS printer driver story. We have the DFSG because violations
of them cause actual problems and hassles to actual people, and make
software less useful or modifiable or free. Unremovable invariant
sections could screw up our manuals, and impede various uses and
recycling of material, so we're firmly against them. But snippets in
our packages, in contrast, have not caused anyone any trouble
whatsoever, and by nature cannot! Removing them would be a lot of
work, with no gain. Once we were done there would be nothing we could
point at and say you can now fix/do/run/help the XXX
program/documentation which you couldn't before. It would not, in
actual fact, increase the utility or freedom of the Debian GNU/Linux
Operating System.
Given all this, it seems highly unlikely to me that we could reach
consensus to change practice and set out to exterminate the snippets.
(On the other hand, this isn't license to sprinkle non-technical crap
all our our beloved distribution. We do have the freedom to remove
the snippets. Like chocolate sprinkles, they should not be overused.
Also like chocolate sprinkles, you don't have to write a formal rule
for when there are too many---it's easy to tell.)
snippets [was Re: Respect for Upstream Authors and Snippets of Interest]
A while ago, you gave a nice explanation of the correct meaning of the term begging the question as used in the study of logic and discourse. I'd like to thank you for helping to make sure everyone understands the concept by giving us such a clear example.
Re: Respect for Upstream Authors and Snippets of Interest
In my very first message on this subject I stated (in their
definition) that snippets were usually unmodifiable. I gave
specific examples whose modifiability is easy enough to determine:
$ head -7 /usr/share/emacs/21.2/etc/GNU
Copyright (C) 1985, 1993 Free Software Foundation, Inc.
Permission is granted to anyone to make or distribute verbatim copies
of this document, in any medium, provided that the copyright notice and
permission notice are preserved, and that the distributor grants the
recipient permission for further redistribution as permitted by this
notice.
$ tail -4 /usr/share/emacs/21.2/etc/LINUX-GNU
Copyright 1996 Richard Stallman
Verbatim copying and redistribution is permitted
without royalty as long as this notice is preserved.
On the length-scale of GNU Emacs, these certainly satisfy the small
snippet requirement! Without including any ancillary emacs packages,
or counting GCC and friends, or counting all of Debian since after all
without these documents none of Debian would exist, we have ...
$ apt-cache show emacs21| egrep '^Size:'
Size: 12888244
$ stat --format=Size: %s /usr/share/emacs/21.2/etc/{,LINUX-}GNU
Size: 26334
Size: 5870
(26334+5870)/12888244 = 0.0025
Actually I do think they are misplaced, and would be better housed in
/usr/share/doc/emacs21/.
About the README offer you allude to, do you really think an
upstream author's statement:
Copyright blah blah blah ...
Distributed under the GNU GPL v2 ...
Source licenses for inclusion of this code in proprietary programs
are available from the author for $10,000 plus 2% of gross sales.
is modifiable? Removable sure. Maybe appendable. But modifiable?
How can it be changed? Do you think Debian could just change the 2%
to a 0.5%? Maybe give a discount to non-profits? When we talk about
code being modifiable, that's what we mean: the ability to change it
in arbitrary ways. Here, no changes are in fact possible, however you
read the license and such.
Re: Respect for Upstream Authors and Snippets of Interest
But you're allowed to paraphrase anything, so what's your point? You can even paraphrase non-modifiable essays. In an essay RMS explained that he used to work at ... and then Symbolics ... and he felt that ... and so he climbed to the mountain top and hacked for forty days and forty nights without food or water or sleep or wrist braces, and brought forth to the masses below ...
Re: snippets [was Re: Respect for Upstream Authors and Snippets of Interest]
- Debian is absolutely *rife* with such snippets. - This is because upstream tarballs are absolutely rife with them. - Scanning our sources for them would be a gargantuan undertaking. - They'd keep sneaking back in. All of these apply to ordinary bugs much better than to snippets. Upstream authors generally integrate debianogenic bug fixes, and do their best to not have bugs, so that's not really true. Besides which Debian does not attempt to guarantee that all packages have no bugs, but you are proposed that we endeavor to ensure that all packages have no snippets. In other words, the cases are completely different. - It would be a major change in practice. - No other free software organization eschews such snippets. I disagree with the premises of those two, as well. For instance: no other free software organization edits out the non-free fonts from XFree86 or the non-free firmware from the linux kernel; and this seems like a relatively minor change, as changes in Debian go. I'm not sure I follow your reasoning there. Your email address implies that you are associated with a math department, so let me phrase this in mathematical jargon: a proof of this form A - B A - C Therefore: B and C are the same is not valid. The difference between B and C here is that firmware without source denies to users their fundamental right to understand and modify the software that controls their computer. Similarly, the non-free xfonts-scalable-nonfree do not allow distribution of modified versions. This denies to a user who has modified such a font in order to improve the function of his computer the right to help his friends improve their displays as well. No such problems occur with snippets. (I'm including this to keep things from drifting off-topic) *** BY MY DEFINITION: *** *** A snippet is a file in a source tarball which: *** *** - MERELY ACCOMPANIES and is not an integral part of the source *** - is REMOVABLE *** - is NON-FUNCTIONAL (not code, not documentation, not needed for build) *** - is NON-TECHNICAL in nature *** - is usually of historic, humorous, or prurient interest *** - is usually NOT itself MODIFIABLE, eg may redistribute verbatim *** - is very SMALL compared to the technical material it accompanies *** *** (examples of such snippets are historic or humorous emails and *** usenet posts, political essays, jokes, and the like.)
snippets
Dylan Thurston [EMAIL PROTECTED] writes: I'm much more interested in the arguments why it's a good idea in the first place to include the snippets than in these arguments about how much work it would be to remove the unmodifiable snippets. Fair enough. (1) Allowing snippets to be included is the current Debian practice, so the burden of proof is on those who would propose to remove them to show a compelling reason for doing so. (2) No practical problems have arisen from allowing snippets to be included. No one has proposed any gedanken practical problem. Generally we decide that something is bad (a violation of the DFSG or social contract) because we come up with a gedanken problem with it. This has served as an excellent acid test, and has kept debian-legal grounded and effective despite its chaotic nature. (3) Snippets can help people understand the circumstances surrounding the creation of some software, understand the author, and in general be edifying educational and entertaining. The GNU Manifesto is a good example. But as my canonical example I'm going to use a copy of the heart-rending email from his cancer-stricken and now deceased sister that inspired an upstream author to study molecular biology, work on colon-cancer oncogenes, and write a biosequence-processing program which is packaged for Debian. Removing such snippets would serve no purpose but to separate us from our roots and impoverish our culture. To sum up: snippets can be good, no one has given any grounded argument for why snippets are bad, and removing them would be an enormous and divisive pain in the ass. We should keep the status quo. (I'm including this to try and keep the discussion on-topic.) *** BY MY DEFINITION: *** *** A snippet is a file in a source tarball which: *** *** - MERELY ACCOMPANIES and is not an integral part of the source *** - is REMOVABLE *** - is NON-FUNCTIONAL (not code, not documentation, not needed for build) *** - is NON-TECHNICAL in nature *** - is usually of historic, humorous, or prurient interest *** - is usually NOT itself MODIFIABLE, eg may redistribute verbatim *** - is very SMALL compared to the technical material it accompanies *** *** (examples of such snippets are historic or humorous emails and *** usenet posts, political essays, jokes, and the like.)
Respect for Upstream Authors and Snippets of Interest
First of all, I would like to publicly thank RMS for engaging in a sustained and illuminating conversation on this list. He has been confronted with an outrageously low signal-to-noise ratio. The thoughtful and well-reasoned messages have been buried in a mass of counterproductive picayune harping on terminology and word choice, ad-homenim arguments, insultingly-phrased demands, and even outright insults. Reading such a mass of text is quite a burden; more so when it is mostly crap; and particularly burdensome when the crap attacks the reader personally and unfairly. Despite this, some sensible dialog and useful exchange of views has occurred. In a recent message to this list, RMS mentioned that people had stated that Debian would remove all non-modifiable but removable text from Debian packages: According to Don Armstrong, a non-modifiable text cannot under any circumstances be considered DFSG-free, so it would have to be removed from the manual. Others have (it appears) said the same thing. Having seen a lot of rigid dogmatism here recently, I can hardly expect Debian not to be rigidly dogmatic on this issue too. Based on long-standing Debian tradition and practice, this is decidedly and demonstrably not the case! Don and others were perhaps writing in haste. Debian has a longstanding practice of respect for upstream authors. For instance, if the author of a GPLed program includes a statement in a README please if you like this program I'd very much appreciate it if you sent me $10, we do not remove such a statement. We even include offers by the author to sell the right to include the code in a proprietary program. To my knowledge, in all the many thousands of packages in Debian, such statements have never been removed! Even though Debian might find such an offer repulsive, we respect our upstream authors enough to include them. Another example of this sort of respect is our treatment of code obtained under a dual license. Debian has, to my knowledge, never redistributed code that was given to us under a dual license under just one of those licenses. This is the case even when we consider the other license quite abhorrent! Nor have we relicensed weakly licensed code (eg programs from the Free BSDs) under the GPL. Nor have we released LGPLed code under the GPL. Debian could do these things, but out of respect for our upstream authors we don't. As a last example, many source tarballs include snippets, defined as follows. *** BY MY DEFINITION: *** *** A snippet is a file in a source tarball which: *** *** - merely accompanies and is not an integral part of the source *** - is non-functional (not code, not documentation, not needed for build) *** - is usually of historic, humorous, or prurient interest *** - is removable *** - is usually not itself modifiable, eg may redistribute verbatim *** *** (Good examples of such snippets are historic or humorous emails *** and usenet posts, political essays, jokes, and the like.) To my knowledge Debian has not only never removed a snippet from the source we distribute, but includes such snippets in the binaries, typically in ...-doc.deb. One example of this is GNU Emacs, which includes a bunch of such snippets, all of which are included---right now---in /usr/share/emacs/21.2/etc/. All of them are removable: sex.6 (which is of questionable taste), GNU, CENSORSHIP (which is dated into such irrelevance that its inclusion is arguably embarrassing), LINUX-GNU (whose first sentence misleadingly reads The GNU project started 12 years ago), COOKIES (whose relevance, copyright status, and humor value is unclear), etc. Rob Browning, who packages GNU Emacs for Debian, could remove all of these snippets, or could go through and remove only some of them. But he doesn't, and I daresay I'd be quite shocked if he ever did. Debian does require the *right* to remove such snippets. And if there were an unacceptable snippets (racist screeds say, or SCO lawsuit apologist tracts, or libelous text) we would probably exercise that right. To my knowledge, this has never occurred. People who say that such snippets have no place in Debian, and constitute violations of the DFSG, are attempting to impose a very foolish consistency. And Jan Schumacher's statement: A /non-modifiable/ text could not be included in Debian, a /modifiable/ one would most likely be. is a load of hooey. Inclusion of snippets is not a violation of the DFSG. Such an overly-literal interpretation of the rules is precisely why we call them D-F-S-***GUIDELINES***! Because we use common sense in their application.
Re: Respect for Upstream Authors and Snippets of Interest
Can you provide a concrete example of such a snippet which is not under the licence applied to the entire package by the COPYRIGHT, COPYING, or AUTHORS file and restricts modification or removal? ^(2)^(1) (1) No, since such a snippet is *by definition* removable. (2) I *did* include concrete examples of snippets under a different license than the package which includes them. $ head -10 /usr/share/emacs/21.2/etc/GNU
Re: Respect for Upstream Authors and Snippets of Interest
Please do not attempt to make the Debian has no principles but the DFSG, and the DFSG is only a set of guidelines, therefore Debian has no principles and can do anything argument, because it's nonsense. Okay. I didn't make that argument, but as you request I will not make it in the future. (In fact, even without your request it seems unlikely that I would make such an argument.)
Re: Respect for Upstream Authors and Snippets of Interest
Dylan Thurston [EMAIL PROTECTED]: On 2003-09-27, Barak Pearlmutter [EMAIL PROTECTED] wrote: Based on long-standing Debian tradition and practice, this [removing non-modifiable texts] is decidedly and demonstrably not the case! It is long-standing tradition; however, whether it should continue is another question. I haven't seen many people offering a principled defense of the practice. Perhaps most people either felt that it was outside debian-legal's mandate to question such a long-standing practice, or that the practice is so obviously reasonable and common that it does not merit discussion. Already filed as bug #207932, marked as sarge-ignore (per the release manager's stated policy). If you want to offer a principled reason why this is not a bug, I'm eager to be convinced (although IANADD, so you don't need to convince me). Okay - that's not a bug because they're just little harmless snippets which are informative and interesting, are not functional, are *removable*, and merely accompany the package but do not constitute an integral part of it. By long-standing Debian tradition their inclusion is considered reasonable and proper, and not a violation of policy. Since this is the case, the burden of proof is upon you to demand such an serious change in Debian practice. Certainly their removal goes far beyond the GFDL-related consensus reached by debian-legal, which was concerned with non-removable materials. Peace, Luv+Reflection
Re: Respect for Upstream Authors and Snippets of Interest
Mahesh T. Pai [EMAIL PROTECTED]: Debian does require the *right* to remove such snippets. rights specific to Debian are not DFSG free. Absolutely Correct! When I said Debian does require the *right* to remove such snippets I did not mean to imply that the right might be exclusive to Debian. The right must be there for everyone. Debian requires that this right (available to everyone) be present. My statement was verbal shorthand for this.
Re: Respect for Upstream Authors and Snippets of Interest
Mahesh T. Pai [EMAIL PROTECTED]: Debian does require the *right* to remove such snippets. rights specific to Debian are not DFSG free. Absolutely Correct! When I said Debian does require the *right* to remove such snippets I did not mean to imply that the right might be exclusive to Debian. The right must be there for everyone. Debian requires that this right (available to everyone) be present. My statement was verbal shorthand for this.
Re: Respect for Upstream Authors and Snippets of Interest
Jan Schumacher [EMAIL PROTECTED] (using an expired key) writes: Fair enough. However, all of these statements are removable, and their modification is probably not prohibited by the license. The flow of the argument was: one example of Debian's respect for upstream authors is not removing these requests and offers. If they were unremovable, this would have made a poor example. Do you believe unmodifiable essays like the GNU Manifesto could be accepted in Debian with the DFSG as they stand? This is not a matter of belief. This is longstanding, and heretofore uncontroversial, accepted Debian practice. The GNU manifesto is in Debian right now, right where it belongs: /usr/share/emacs/21.2/etc/GNU and analogous locations in emacs20 and xemacs. The Debian ftpmasters are doubtless quite aware of such snippets, and have no problems with them. *Changing* this tradition would be a big deal. If there were a package whose bulk consisted of the GNU manifesto and related materials, I think people might have some problems with that. Certainly I would. That would also not fit the definition of a snippet I gave, which was an attempt to explain current Debian practice.
Practical Problems with the GFDL
Perhaps instead of debating the freeness of the GFDL, which seems to be an emotionally charged issue, we could discuss its inconveniences without bringing in freeness per-se. If these inconveniences, or other practical issues, could be shown to the FSF's satisfaction to be too onerous or problematic, it is possible that the FSF would want to reconsider the GFDL for that reason alone. I see a few practical problems with the GFDL: - incompatibility with the GPL - not a full copyleft (because people can add invariant sections thus distributing the document under terms more restrictive than those imposed on the materials they received) - lack of clarity (even debian-legal can't figure it all out; even the FSF makes mistakes in labeling invariant sections; even wikipedia used it incorrectly; even with lots of helpful explanations from RMS himself there is considerable lack of understanding on just what the GFDL actually requires) - possibility of obsolescence, via dated invariant sections - possibility of obsolescence, via changes in technologies (such as the disappearance of printed matter, or the particulars of file formats and access restrictions) - difficulty in modifying invariant sections of GFDLed documents not under unified central control (need permission from many contributors or their estates/agents, which becomes more difficult with time) - can be very difficult or impossible to repurpose chunks (eg copy regexp chapter) - does not lead by example (if all software used the GPL, all code would be freely available and sharable. if all documentation used the GFDL, differences in invariant sections and cover matter would impede sharing. perhaps licenses should lead by example to the world we all want: a world where sharing is always unimpeded) - is causing a lot of fighting and bad feeling between people who have the same goal and who should be cooperating and helping each other Some of these do not impact the FSF in its productions of manuals, due to the FSF's possession of copyright assignments, and its ability to break the rules as necessary. They would however affect more distributed groups attempting to communally maintain software that includes GFDL'ed documentation. They would even affect groups that want to exchange share materials despite having highly divergent technical goals. As we all know, one of the FSF's central tennants is that everyone should have the right to modify and share. So it seems to me that these issues may concern the FSF even if they do not directly affect it.
Re: Legal status of software licences
You hold the gun and I'll pull the trigger while wearing a blindfold, then neither of us will be convicted of murder. Won't work. The law is not a computer program. There's this thing called intent. And conspiracy, and guilty as charged, and punitive fines, and jail ... If C knows (or has good reason to suspect) that the software he got from B is an unauthorized copy then he is contributing to the illegal act, and would likely be liable. It is like receiving stolen goods in the non-digital world. Microsoft has how to recognize an authorized copy of MS Windows blurbs all over place explaining how their holograms and seals are supposed to look. They do this in part so courts will find it less plausible when someone defends themselves by claiming to have been unaware that some particular copy of Wondows wasn't authorized.
Re: mozilla export restrictions
I've discovered following note on the mozilla download page (http://mozilla.org/releases/#1.5) : This source code is subject to the U.S. Export Administration Regulations ... Does this mean that we have to put mozilla to non-free? No. That statement is not part of the license. It's just a note to make sure downloaders are aware of something that may be of relevance to them, so they can avoid breaking the law out of ignorance, and so mozilla.org can't possibly be construed as encouraging such an illegal act. It's like a FOR HUNTING AND TARGET PRACTICE ONLY label on a '57 Magnum. This is in fact exactly the right way for them to deal with the export restriction issue: as an advisory notice and not a license clause.
Re: Additional restriction to LGPL
If you modify this library, you have to make sure that the powered by HAWHAW copyright link below the display area is kept unchanged. I queried the author about the including copywrite line, and got this response: IMHO this additional statement is covered by this sentence in the LGPL (chapter 6, 2nd paragraph): You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. The causality/reasoning there seems a bit unclear. But instead of getting into it, talking about modification+use vs distribution, etc, maybe you could just ask the author to rephrase it in a way that no one could object to? Something like this: Please note that the LGPL (sec 6.2) requires you to give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. I consider the powered by HAWHAW copyright link below the display area to be such a prominent notice. I would prefer that you leave this link as is. If you remove the link without discharging the obligations of LGPL sec 6.2 in some other fashion, you will be in violation of the license. This would make it absolutely clear that he is not requiring anything beyond what the LGPL requires, while also letting people know that the copyright link shouldn't be removed without consideration as to an appropriate alternative mechanism for giving credit to the software.
Re: Unable to contact author of DFSG FAQ
Sorry about that. The mail server I use crashed, and during restoration the sysadmin turned on the SMTP server before restoring the accounts, unceremoniously bouncing days of incoming queued email. I should be reachable again. And if anyone wants a relaxing job as sysadmin of a friendly department in lovely Ireland, please contact me. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.may.ie/~barak/
Re: GNU FDL and Debian
... To the extent that the GFDL caters for the wishes of publishers at all, it is in that it makes it inconvenient for *competing* publishers to publish and sell hardcopies. ... I'm not quite tracking you there. The GFDL isn't supposed to have that effect, at least as I read it, and as I understood RMS's messages. Maybe it does though, but even if so that's not really the point. The FSF wouldn't consider such an effect desirable, so that's not a reason they'd use to decide against going dual GFDL/GPL.
Re: GNU FDL and Debian
From: Sergey V. Spiridonov [EMAIL PROTECTED] I like FSF and I like Debian. So, I ask you (FSF and Debian) to find a solution. Both goals are important. I (user) need documentation and I (user) need free software. Please, find a compromise! You are absolutely right. Failure to find a workable solution will hurt both organizations, and free software in general. Debian is aware of this - we have moved very slowly for this very reason, and would quite like to find a happy resolution. Here is one proposed compromise. This was suggested earlier, and although the FSF did not adopt it neither did they reject it or even critique it. So it might be workable; I don't know. Since the FSF felt that publishers could not use the GNU GPL for printed documentation, they adopted the GFDL for their manuals, to allow printed publication under terms they felt publishers would find acceptable. (The correctness of their reasoning is irrelevant for our current purposes, so please let's not get into it.) On the other hand, Debian has serious issues with the GFDL, some of which apply mainly to its use in the context of non-printed (digital) distribution. Debian also has some convenience issues, the foremost being that the GFDL is not GPL-compatible. One bit of contention is whether some of the issues identified by Debian are issues of freedom or mere issues of convenience. (Everyone however does agree that the GPL-compatibility issue is one of just convenience. There is disagreement even there over the magnitude of the inconvenience though.) A solution that springs to mind is for the FSF to re-license manuals under a dual license: GFDL/GPL. This would solve all the issues in one stroke. It would also render the freedom vs just convenience issue moot. Debian has a general policy of respecting upstream desires in our contributed code. In this case, Debian would I'm sure be happy to respect the FSF's desires and place its contributions under a dual GFDL/GPL.
Re: DFSG FAQ (draft)
Q. How can I find out if there are known doubts about the freedom of a particular package in Debian but for some reason they have not yet led to it being removed from the archive? I agree that this is an important QA to have. This is arguably covered in the answer to what is debian-legal at the top of the document. Does this extra material provide more information? It just says that debian-legal is where we discuss this kind of thing, which is already (I hope) clear.
DFSG FAQ (draft)
With a little help, I've composed a draft DFSG FAQ. It meant as an introduction to issues discussed on debian-legal, with some general background material to help bring naive readers up from ground zero. http://people.debian.org/~bap/dfsg-faq.html It is a bit rough, so I'd welcome modifications. You can email patches, or for little things just edit in place - the file is g+w and under CVS control so I'll just cvs diff / cvs commit as appropriate. If people think it could be of some official use, I'd be pleased if it were taken over into a more formal location. -- Barak Pearlmutter
Re: DFSG FAQ (draft)
Thanks. I incorporated your mods, leaving out the public domain change because I'm not sure how to phrase except in France and places like that where we take that to mean effectively the same thing even though their legal system doesn't have such a concept except for people like Leonardo da Vinci because obviously it's what the author wants and they do have the concept of doing what the author wants even though authors don't technically have the right to actually put their own works in the public domain so don't worry about it. Especially without sounding like I'm baiting the French. Which, don't get me wrong, I enjoy as much as the next red-blooded American expat. But here, not there. I think that's what Henning Makholm meant in his followup.
Re: DFSG FAQ (draft)
free license, Debian in general does not consider material under the GFDL to be free. I think it's premature to include such a statement in an official Good point. Can you suggest a re-phrase for the GFDL question? I think it is fair to say that Debian strongly discourages its use, ie there does seem to be consensus on that. There also seems to be consensus that it is not free if enough of the clauses are activated. With no clauses activated, there seems to be consensus that it is unpleasant but tolerable, although that feeling was not unanimous. With just minimal activation, I'm not sure... --Barak.
Re: DFSG FAQ (draft)
Okay, I rephrased the GFDL stuff a bit. Let me know if you're not comfortable with it. --Barak.
Re: DFSG FAQ (draft)
(IMHO, the GFDL is a very interesting starting point, and will almost certainly evolve to something genuinely useful. The problems that are I'm not aware of any plans on the FSF's part to significantly evolve the GFDL. That's not to say that no such plans exist, but we still need to deal with what we have today. I agree that it read much too harshly. I've tried to soften it way down, eg by removing the second half and adding a gentler first sentence. --Barak.
Re: The debate on Invariant sections (long)
... Since RMS seems unwilling to change anything, I'd say that _all_ GFDL'd works have to go into non-free. RMS did not say that. He listened to Debian's concerns, and acknowledged that there were GDFL-related issues he had not previously been aware of. He characterized them as *primarily* consisting of license compatibility problems, which was indeed the case. To quote RMS's relevant message: ... the rest are real inconveniences ... Debian should give RMS a chance to think for a while, and consult with others including his legal council and other parties at the FSF, rather than taking hasty action. This is a courtesy we've extended to upstream authors many times before, and it seems unreasonable not to extend it in this case as well.
Re: The debate on Invariant sections (long)
My understanding is that the FSF requires copyright assignments in order to give themselves the ability to most effectively defend the community against poachers and legal attacks. It would be a drastic misunderstanding to think they do it in order to give themselves an ability to share that they'd deny to others. The FSF's fundemental value is to give everyone the ability to share, even (or perhaps especially) in the absence of copyright assignments. ... the FSF will never have a problem, because it demands copyright assignments for all contributions. Although this might be true it is irrelevant, as given copyright assignments they would not have a problem even if they used a proprietary license. Furthermore, since assignments are just a matter of expedience, under appropriate circumstances the FSF might well incorporate materials without an assignment. That would be their call, but I cannot imagine it is something they'd want to rule out unconditionally. If the GFDL is impeding sharing, there is one thing we can be confident of: that the problem was not anticipated when the GFDL was drafted.
Re: The debate on Invariant sections (long)
My understanding is that the FSF requires copyright assignments in order to give themselves the ability to most effectively defend the community against poachers and legal attacks. It seems perfectly plausible to me that the reason you cite was never the sole motivation for this policy, though it may have been the most frequently and publicly articulated one. Sure, and it's also perfectly plausible that RMS is a secret employee of Microsoft and Chinese double agent plotting the use of free software to assassinate the Dalai Lama. But this is debian-legal not debian-wacko-conspiracy-theory. Given the FSF's highly successful GPL enforcement activities and prescient concern with optimizing the community's legal position, and RMS's track record of both contributing to and founding the community, it seems like Occam's razor dictates taking the FSF's explanation for requesting assignments at face value. Consider the current SCO/IBM brouhaha - it's a shame the FSF doesn't have assignments for the Linux kernel which would put it in a position to stand up for the community against SCO's bullying. It is no coincidence that SCO chose to attack something that the FSF doesn't have legal paperwork on.
Re: The debate on Invariant sections (long)
From: Richard Stallman [EMAIL PROTECTED] This problem is unfortunate, but no worse in the case of two ways of using the GFDL than with a pair of two different free software licenses. True, but this kind of problem never bites people who just use the GPL, while it seems to be biting people who just use the GFDL with alarming frequency. I would note that *even the FSF* has had trouble using the GFDL properly so as to avoid this problem. And even the FSF will be bitten by it again, should someone add some text to the GDB manual which the FSF incorporates back into its master copy, and then the FSF decides to modify the that document's invariant parts. The GFDL with any kind of invariant thing activated seems to largely break the commons property. In effect, each document is an isolated island, with serious transfer of text between documents made quite difficult. (At least, unless the same entity is in a position to relicense them both. In which case even a completely proprietary license would allow sharing, so this isn't a counterexample.) Regardless of whether this is an issue of freedom, it does seem to be a rather serious practical problem. From: [EMAIL PROTECTED] (Thomas Bushnell, BSG) Let me point out that just as Debian doesn't get to demand that the GFDL be changed, so also the FSF does not have a role in determining the interpretation of Debian's standards. I must take exception to this. Debian does indeed listen to the FSF, take its needs seriously, and listen to its arguments with an open mind and more importantly with an open heart. We are on the same side, working for the same ends. Debian is distributing the FSF's GNU system (plus a bunch of free applications and a kernel), a fact which we insist on acknowledging in the very name of our distribution. We nurture a Debian GNU/Hurd, and our founding documents codify ideas taken from the FSF. All of us were moved and motivated by RMS's eloquent writings on the subject. Debian has very close relations with upstream GNU developers, and strives to work together to solve technical problems and to advance our mutual goals. The same spirit of mutual respect and cooperation has carried through to license issues, where we should continue to strive to listen to and understand each other, and to try to work out any problems so as to together continue to advance the cause of the free software movement. Our cooperation on past license issues (KDE/Qt comes to mind) has been successful. So we do, in fact, have a history of working together to address license issues, both those of freedom per-se and those (like the KDE/Qt issue, and Mozilla as well) of convenience and the health of the copyleft commons.
Re: The debate on Invariant sections (long)
The Wikipedia used the GFDL because it was recommended by the FSF. They used it in its natural way. And then they got burnt. I fetched those pages, anxious that they might have had a serious problem, but when I saw the contents I was relieved. They were just discussing whether they are better off using or not using invariant sections, and how to use them. Words like burnt do not fit the situation. I'm not sure if the gravity of the situation really conveyed itself. With their invariant stuff, the encyclopedia was much less useful. So they had to remove it. But they already had lots and lots of entries, all licensed with that invariant text. In order to just remove it, technically speaking they needed permission from EVERY SINGLE CONTRIBUTOR, since all the contributions had been made using the with-invariant license and needed to be re-licensed with the modified sans-invariant license. If they couldn't get in touch with someone, or that person didn't want to give permission, they should have removed that person's text. If multiple people worked on the same entry they would have had to remove the whole entry, even if it was really long, if they were unable to get in touch with just one person, even if that person's contribution to that entry was relatively minor. Note that their web-based interface makes adding or editing text very easy, for anyone in the world. So they had an army of contributors, and people often fixed typos or added sentences to many many entries. This is the very power of their approach - but it makes contacting everyone, or removing one person's contributions without removing a great deal of adjacent material, extremely difficult. Instead they took a third route: they removed the invariant section without getting everyone's permission. This I'm sure you'll agree is of dubious legality! It is something I'm sure the FSF would not recommend. To summarize: they had a choice. (a) start over (b) contact everyone, maybe have to remove rewrite large fraction of entries (c) just ignore the legalities and relicense without permission If (a) or (b) don't count as getting burned, I don't know what would. Option (c), which is what they took, is not exactly comforting! The FSF has also been in the position of having to modify the invariant clauses of a GFDL document, due to an error. You have the luxury of just re-licensing it though, because you have copyright assignment. You can modify an outdated essay, or remove an invariant section that is no longer useful. But you should be aware that holding all the copyrights gives the FSF a practically unique position. Others without that position also want to contribute to, maintain, and develop free documents. The genius of the GPL is that it allowed this - everyone could use it without fear. This is not true of the GFDL.
Re: The debate on Invariant sections (long)
A number of people have said some intemperate things in this thread, but I really think that this comes down to a matter of 90% miscommunication, and 10% differences in circumstances. I believe that a meeting of minds should be possible, since we share the exact same goal here: WHAT IS BEST FOR FREE SOFTWARE. Debian insists that all which it distributes be free, under a single definition which does not require asking whether a given bit of text is technical or political. Can you help us find a suitable definition for that? It makes no sense to apply the same standards to political and legal text as to technical material. Ethically they are different situations. This issue is, I believe, a red herring. To my mind the question we ask should not be concerning the existence of political essays, or the inappropriateness of people revising them without permission, or even their being carried along in the free software distribution chain. The issue here is subtly different - it is that (as I hope is explained below) in the particular case of the GFDL such invariant essays interfere with the functional freedom of the documentation they accompany. I put my political essays under a license that permits only verbatim copying because in my view that's proper for for political essays. That seems entirely reasonable. (One danger is that essays can become outdated. That is not so bad in a magazine, but is a bit of a PR problem when they enjoy distribution along with source code, eg in the GNU Emacs sources. So---just a suggestion---it might be a good idea to regularly re-evaluate the rhetorical effictiveness and timeliness of such materials.) It was clear from an early stage that companies might package parts of GNU with non-free software and would present the non-free software to the users as something legitimate and desirable. (This problem is getting bigger, not smaller: today, nearly all packagers of GNU/Linux distribute non-free software with it and try to argue it is a good thing.) So we had to search for ways to make sure that our message saying non-free software is wrong would at least be present in the GNU packages that they redistribute. We did this by putting invariant political statements into programs and manuals. In programs, these statements are included in the license text, in the preamble to the GPL. In manuals, they are separate sections. When we make decisions in the GNU Project about what counts as free software, or free documentation, they are based looking at freedom as a practical question, not as an abstract mathematical one. That seems like a good way of looking at these issues. You are trying to make the best possible copyleft for these things. I don't think there's any real disagreement about that goal. There is instead a tactical question, of how free software can be best supported via a copyleft on its free documentation. There are also some practical questions about how documentation can best be copylefted. These sections are consistent with freedom because practically speaking they don't stop people from making the software do what they want it to do, or the making the manual the manual teach what they want it to teach. This is the heart of the matter. They don't stop the FSF in such endeavors, because the FSF holds copyright to the whole ball of wax. So you probably have not encountered, or even thought of, the problems I'm about to describe. After all, they do not affect you. But *as treated by the GFDL* these invariant section do, as a practical matter, dramatically interfere with the freedom of others to utilize the covered materials as free documentation for free software. Here are some xerox printer control software kinds of scenarios that I hope will make the issues explicit. (For each there is an implicit and share the result with my friends, of course.) I wanted to add online help to a GPLed program using text from the GFDLed manual that came with the program ... but I *couldn't* because of the *license*! (Of course *you* can, RMS. But only because you hold the copyright, so you're not bound by the letter of the license. This simple act is forbidden by the GFDL.) I wanted to combine materials from two GNU manuals into a single manual, but it *wasn't allowed* (incompatible cover texts, or the union of the two sets of invariant sections was too burdensome.) I wanted to make a BSD DIFF manual by editing the GNU DIFF manual, but I *couldn't* (cover texts say GNU which wouldn't be accurate). An invariant section was outdated/inappropriate/incorrect but could not be removed. I wanted to snip a long section from a GFDLed manual into my GPLed program debian-bug.el, but I couldn't. (This one actually happened.) I modified the texinfo documentation for GNU Emacs, and now I'm not sure if I can distribute them together (because the info pages and the executable make a single coherent work but the
Re: query from Georg Greve of GNU about Debian's opinion of the FDL
You know, the fact that moral rights might in the future theoretically be an issue for free software in Europe is not an excuse for the FSF to promulgate a license that itself has already caused serious problems to people trying to build community commons free documents, like that encyclopedia. I'm simply not following your logic. Here is the case against the FDL: - it is obviously inappropriate for software - the line between documentation and software is very blurry - eg in the debian-bug.el example, if the FDL were in use it would be to the detriment of free software another case against it: - used in the recommended fashion, by innocent people trying to build a common free encyclopedia, it has *already* caused serious problems These are telling: the FDL, if used for documentation of free software, damages the cause of free software; and when used for non-documentation documents like an encyclopedia has damaged the cause of free documents. Conclusion: the FDL is a bad license. --Barak.
Re: query from Georg Greve of GNU about Debian's opinion of the FDL
Sure, here is some text related to the Wiki debacle: http://www.wikipedia.org/pipermail/wikipedia-l/2001-October/000624.html http://www.wikipedia.org/pipermail/wikipedia-l/2002-June/002238.html That doesn't make the situations dissimilar, however, as there are people complaining about not being able to take some pieces of GPL'ed code from one program and put them into their Free Software programs without adhering to the GPL. This is not a valid comparison, because in *this* case the inconvenience and damage is happening to not just to some random free software developer (which is already a shame, and something to be avoided if at all possible) but in fact to a developer of software under the GNU GPL. In other words, J. Random Hacker, who is simply following the recommendations of the FSF and putting his code and documentation under the FSF-recommended licenses, the GPL and FDL, is the one being hurt. To my mind there is something very wrong with that scenario. --Barak.
Re: query from Georg Greve of GNU about Debian's opinion of the FDL
At first I thought the GNU FDL was okay. And I tend to cut RMS a lot of slack. But the more I think about it, the less I like it. One principle of a proper free license is that it doesn't allow the thing it is protecting to be poisoned. In the case of the GNU FDL, despite the laudatory goals, it basically makes a deal: here's the text or code or whatever, and in exchange you have to give the author a soapbox. Some advertising space, really. New and contributing authors can add their own little soapbox speeches, their own little bon mots. There's nothing to prevent a manual from becoming rapidly covered with a hundred little impassioned pleas. Once there are two, adding a third is irresistible. And each one would be considered using a marginal cost/benefit analysis. Each one would be little extra cost, so the benefit of added meat for the document itself that comes along with each extra invariant blurb could actually be pretty small. This would be a bad result. It is not a road we should start down. Don't get me wrong - I don't have a problem with RMS's impassioned pleas for free software sitting on *my* machine. If he asked me, as a personal favor, to let him put up a collection of his writings on each machine in my lab, and make them all web servers, and put an FSF billboard on the sign on the top of my car, and some FSF decals on my luggage, I would. As a personal favor. Because I'm so grateful to him for the wonderful things he's done. But I do have a problem with forcing people who just want some documentation to keep unrelated invariant text around. Especially since it wouldn't have to be RMS's, it could end up also having some advertising copy from IBM, and some more adds from a book publisher, and a sad story from a native american about how his people were screwed a hundred years ago, and another little bit about the horrors of Waco, and something from the ACLU, and then an add for UNICEF, and some gun nut screed of Eric Raymond's added by one of his disciples. This is a very bad direction to go. At heart, the FDL allows an add-space-for-usage deal. This is roughly equivalent to licenses we've rejected, like link-on-your-web-page-ware. I really hope the GNU project comes to its senses on this one. (The technical argument - that the line between code documentation can be blurry and therefore the documentation should have something GNU GPL compatible - also seems rather strong.)
Re: Revised LaTeX Project Public License (LPPL)
Something like this:
You must not cause files to misrepresent themselves as approved by
the official LaTeX maintenance group, or to misrepresent
themselves as perfectly compatible with such files (according to
compatibility criteria established by the official LaTeX
maintenance group).
does this ban
% This is not actually standard LaTeX, but we do this for ease of use:
\set{\latexversion}{standard}
The LaTeX people [...] want a ban on something which
programmatically interfaces in certain ways with Standard LaTeX.
The DFSG will accept a ban on making false claims of authorship to
humans, but not a ban on making such false claims to a program.
Well, under the misrepresentation clause above, this would in fact
be banned ... if its effect were to misrepresent the file as standard
LaTeX, and the comment were just a subterfuge. Whether this is the
case would depend on the context. But if something like that ended up
fooling people about whether it was standard, then it certainly would
be a misrepresentation!
On the other hand, my impression is that the LaTeX people would be
okay with such a file if (in context) there was care being taken to
not fool anyone (accidentally or deliberately) into thinking that what
was running was standard LaTeX, and the line of code were the just a
technical means to get something to run, eg with some modified
non-standard proprietary engine.
In other words, I suspect that what is really going on is a question
of INTENT, and subsequent effect. In this light, maybe the reason the
LaTeX people are having such problems crafting a clear simple license
is that at root they want to ban something based on intent, but (being
computer programmers) they're trying to implement this by writing more
and more complicated rules related to mechanism, and getting more and
more specific to their particular implementation.
I've CC'ed this to a LaTeX person - any comments from the LaTeX crowd?
Re: Revised LaTeX Project Public License (LPPL)
Maybe instead of sinking further and further into little details of how files are verified to be standard LaTeX and the distinction between the LaTeX engine and the files it reads and all that good stuff, we could back up a step? This all really an attempt to procedurally implement an underlying concern. Maybe the concern itself could be directly expressed in the license, abstracted away from its implementation? Something like this: You must not cause files to misrepresent themselves as approved by the official LaTeX maintenance group, or to misrepresent themselves as perfectly compatible with such files (according to compatibility criteria established by the official LaTeX maintenance group). Would this satisfy the LaTeX people? Because I think it would satisfy the DFSG. It might (arguably, perhaps) even be GPL compatible, if the authorship representation parts of the GPL are properly construed. -- Barak A. Pearlmutter [EMAIL PROTECTED] Hamilton Institute, NUI Maynooth, Co. Kildare, Ireland http://www-bcl.cs.unm.edu/
Re: OSD DFSG - different purposes - constructive suggestion!
I've edited that nascent DFSG FAQ and put it at http://www-bcl.cs.unm.edu/~bap/dfsg-faq.html I'd appreciate comments. Especially from the OSD/DFSG WE MUST UNIFY folks, who might perhaps be able to use some of this material to clarify their OSD into conformance with Debian practice, ie to reject licenses they previously felt obliged to accept but which Debian rejects. Also, should this go somewhere on the Debian web site? (If someone thinks it should please just take it over from me and put it up.)
Re: license requirements for a book to be in free section
Given this: From: Stefano Zacchiroli [EMAIL PROTECTED] Date: Wed, 23 Jan 2002 16:21:54 +0100 Cc: Debian Ocaml Maint ML debian-ocaml-maint@lists.debian.org I get an answer from O'Reilly, they told me that in their opinion the reported notice (i.e. the text they want to appear in the debian package that I reported in the first mail) is enough to meet the DFSG requirement. They also ... One thing we could do is this: - Get O'Rielly to send us, in writing, signed, a simple unambiguous statement that assures us that their conditions for distribution of this document conforms with the DFSG, and that any interpretation of their written license terms, no matter how faithful to the text they might seem, which disagrees with this, are incorrect. Eg: We (O'Rielly) assure you our terms for distribution of [this document] conform with the requirements of the DFSG. Any interpretation of our distribution terms, no matter how faithful to the text they might seem, which are inconsistent with this assurance, are incorrect. Signed: __John_J._Authorized_O'Rielly_Representative__ - Include a copy of their statement in the debian/copyright file for the package. - Put the package in main. If there is a contradiction in what they say (ie if their license seems to us not in fact consistent with the DFSG even though they think it is) and some disagreement about it went to court, these ambiguities would be resolved in the user's favor. This is according to a very sensible legal princple embodied in the UCC and also in Common Law: O'Rielly is using a lawyer and Debian isn't, so if O'Rielly makes a contradition it's their fault. (It is worth noting that books are different from software, and it's not unreasonable on the face of it for O'Rielly to want to be the sole paper publisher of a document while allowing unlimited distribution in forms that don't require expensive printing presses. This is something we might want to discuss in general terms on debian-legal. But in this particular case it seems to me that it's their problem, not ours. O'Rielly has real lawyers to protect their interests, and if these lawyers do a bad job, for instance by not carefully reading the DFSG, that's too bad for O'Rielly.)
Re: New idea for finessing patent issues (was: lame (again!))
From: Richard Braakman [EMAIL PROTECTED] I could support this proposal if it simply pops up a screen that says These corporations claim to hold patents on [part of] this package's functionality. [list of patent numbers, countries, expiration dates, short descriptions, links to more information]. Then the user is informed of a potential problem, and can make up his or her own mind and take any measures necessary. At the same time, Debian has fulfilled its potential obligation to inform the user, yet does not take a stance about the validity of the patent. That sounds very reasonable to me. From: Jeffry Smith [EMAIL PROTECTED] ... I dispute (note: IANAL) they have legal weight! Click-through's suffer from the problem of no way to ensure they ARE a contract. Only under UCITA (ack) can they be guaranteed to have force (assuming UCITA is upheld). I agree. And UCITA is an abomination. Fortunately we're not actually talking about a *contract* here, just a warning. Be aware, some people claim that there might be a patent issue in some uses of this software (patents US7549857398573498, US84973549753987538, and US2153987543895473). Use it at your own risk. No warranty expressed or implied. You're own your own, son. We're not asking them to agree to anything at all, just making them aware that Debian isn't agreeing to anything or giving any assurances either. Like the GPL's recommended: Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
Re: New idea for finessing patent issues (was: lame (again!))
I think chose my terminology poorly. When I wrote click through license I was using the word license sarcastically. Hence the scare quotes. From: Steve Greenland [EMAIL PROTECTED] ... The fact that proprietary software vendors engage in those acts is not an argument in favor of Debian doing the same. (Nor is it an argument against doing it, either.) Yes, that is quite true. But it wasn't my point. The fact that vendors of proprietary software use these mechanisms is an argument that, if Debian used click-through notices, Debian could trust them to have some legal weight. The idea itself actually click-though notification. The click through was meant to imply that we could count on this being a valid information distribution mechanism just as much as many software vendors count on their click though licenses. Ie, we could pretty bloody well count on them being read and understood, in the same legal fiction sense that vendors count on click through licenses being read and understood. Let me note that we actually have many click-through notifications already. Some are so aggressive that a package won't configure without the system administrator acknowledging the notification. Some email the notification to the administer if there is suspicion the notice hasn't really been read. I'm not thrilled about the idea of notifying users of potentially relevant patents. I wish the issue were moot, and that we lived in a world without software patents. I do what I can to make that true in this world. But the alternative - namely the status quo - is I think worse. STATUS QUO: do not distribute package ALTERNATIVE: distribute normally, but mention relevant patents Which of these is - less disruptive of development activities? - less sensitive to changes in the software patent situation? - more expressive of our disapproval of software patents? - more encouraging of development of free software whose use might violate some stupid patent in some stupid country? - more convenient for users in software-patent-honoring countries? - more convenient for users in countries without software patents? I would contend that the ALTERNATIVE seems favorable by these criteria. On the second-to-last it is a wash, on all the others it is winner.
New idea for finessing patent issues (was: lame (again!))
We have a conflict: staying true to our ideals, which hold that software patents are a travesty, and preventing nasty lawyers from suing Debian for contributory patent infringement. To shield Debian from legal liability, we do not include patented algorithms in the main archive. This means that even people who would not violate the patents by using the software in question (eg for research purposes, or in countries where the algorithm in question isn't patented, or people who hold explicit licenses, or people who would use the software in circumstances covered by a waiver from the patent holder) are also denied the convenience of having the software included in Debian. I'd like to propose a less onerous solution to the conflict. A solution which would allow Debian to package and archive the software in question, and would allow people in above situation to use the software, while preventing anyone in violation of the above rules from using the software. As a consequence, even though Debian would be distributing the software in question, it would be shielded from legal liability. The idea is to have a click-through license of sorts. Before a potentially-patent-violating package is installed (ie in a preinst) the user would be notified that the software contains a patented algorithm, the identity of the patent would be explained, and the user would be asked if they might be violating the patent by using the software. The list of reasons by which one might not be in violation (see above) would be available for viewing. The user might even be required to mark which of the above reasons, if any, apply to them. If they do not indicate that they have the legal right to use the software in question, then the system would refuse to install it. As an added legal protection, another question could follow this one, in which the user is informed that lying on the previoius question is a violation of the law, and requiring them to swear that they are telling the truth, and to assume any and all legal risk from any patent violations that might occur in using the software, and specifically to indemnify Debian from any legal risk. Again, if they do not agree the software would not be installed. As a convenience for developers, and to allow the legal wording to be modified more conveniently, most of this dialog could be encapsulated in a package: software-patent-warning.deb. In the configuration for the software-patent-warning package, the user could indicate that they live in a country in which software patents are invalid. In that case, the click-through text could be skipped, and instead a warning displayed. This warning would mention that software embodying a patented algorithm is being installed, but that the user has indicated that the computer is residing in a venue in which such patents do not apply - but that if the computer is ever moved the user should take care to either remove the software in question, obtain authorization from the patent holder, or otherwise ensure that they are not in violation of the patent. This would be very simple to implement. (I'd be happy to do it myself, in consultation with lawyers here at my university, and/or any other council that Debian or SPI has access to.) It would allow Debian to support authorized users of patented algorithms, but would prevent any patent violations from taking place. Debian would not be contributing to any patent infringements; quite the contrary, it would be taking strenuous measures to ensure that no such infringement occurred, including educating its users in relevant patent law. It has been suggested to me that system administrators might actually lie in their responses to the above dialogs, but I consider that highly unlikely. In any case, we shouldn't contort our software infrastructure to shield bald-faced liars from the legal consequences of their actions. If sys admins lie in such a setting, especially in the face of such clear warnings, it wouldn't be Debian's fault.
Re: New idea for finessing patent issues (was: lame (again!))
Hey, hang on! If there's something wrong with the idea (eg, you think it wouldn't really shield Debian from liability) please explain in more detail. Vendors of proprietary software use click-through licenses all the time. In part, these agreements are used to shield the vendors from legal liability. Similar agreements give users notification of legal prohibitions, eg on public performance of some DVDs, or unsuitability of material for viewers below the age of eighteen. I don't see why we can't avail ourselves of the same mechanisms, or why they would work for other distributors but not for Debian. It would be prudent to consult legal counsel, to make sure it actually does work the way we want it to, and to make sure everything is phrased just so. But you seem to have some kind of in-principle objection to the idea, even assuming it passes muster with lawyers?
Re: RTLinux patent
These are linux-specific kernel modules, I doubt that they're going to be usable in debian/hurd or debian/bsd... Perhaps not, but you are free to use, modify, and redistribute this code in any place where it makes sense to do so would not pass DFSG muster. Discrimination against uses that are impossible, or don't make sense :). GPL Preamble: ... we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
Re: RTLinux patent
http://www.rtlinux.org/documents/faq.html#Q5 Q: What's the license? How much do I pay? What about the patent? A: RTLinux is released under the GPL and can be freely used, modified, and redistributed under the terms of that license. If you modify RTLinux code, the new code is automatically governed by the GPL. However, if you write your code as separate modules, then the license for the modules is up to you: GPL, proprietary, whatever. RTLinux is also governed by a license to use the base RTLinux mechanism under U.S. Patent 5,995,745. The patent license basically reinforces the GPL terms. There is no fee for using RTLinux, for using your module/applications with RTLinux or for using modified RTLinux code under the GPL, as long as things are properly labled and credited. If you use some other operating system with this mechanism, you need to discuss licensing terms with us. If you want out of the GPL, you need to talk to us as well. If you violate or evade the terms of the GPL or our copyright, you have invalidated this license to use the patented mechanism. Our license applies only to the combination of RTLinux with Linux, and we do not automatically license any other use of the mechanism. We are very sympathetic to GPL uses of the patent license. [top] My reading of this is that the RTlinux code cannot be integrated into some other GPLed OS, eg the Hurd, without incurring patent license fees. To my mind this should be enough to consign it to non-free. It might be that the holders of the patent would permit its free use in GPL-compatibly-licensed OSes other than Linux. Perhaps someone should ask them.
Re: a better copyleft licence
I must have phrased that poorly. If so, I'd appreciate a proper unambiguous wording. Here is my intent: I will allow you to take my code and use it as a module in another program, *provided* that *entire* program is distributed as free (as in speech) software (including full sources available). Ie it's okay to distribute it linked so something else that's incompatible with the GPL for some lame reason, but not with something that's incompatible with the GPL because it's not free or doesn't include sources. I was hoping that DFSG was sufficient to specify this. Particularly with regard to sources, due to DFSG point 2, The Debian Free Software Guidelines (DFSG) 2.Source Code The program must include source code, ...
Re: a better copyleft licence
You all know the sort of problem: according to some people's understanding of the GPL and copyright law, GPL software X cannot be linked with GPL-incompatible software Y and then distributed even if X and Y are separate works in separate packages. Invent yet another licence? I hope not. I've been pondering this issue. What do people think about the below? We're considering using it in some new GPLed software we're developing, so I'd appreciate feedback. This software is licensed under the GPL [... standard boilerplate.] In addition to the distribution rights granted by the GPL, this software may used as a module linked to other modules resulting in a whole which constitutes a single work, eg as a library linked into a program, even if the entire program is not licensed under terms compatible with the GPL, and the resulting work distributed, *provided* that the composite work is distributed under DFSG-compatible terms.
