Re: Tarball licenses (was: Free documentation licenses)
Rick Moen wrote: Weren't you saying that a derived work remains a derived work, even after all the original content has been replaced? If so, then why should it matter if the original modules were eventually replaced by wholly new modules that interact in wholly new ways? Because if neither the original content *nor* the original structure remains, we pretty certainly have a new entity by this time. It's a fuzzy area in the law, to be sure. One of the issues in the case of a certain Web site vs. the print version of the same thing was "How much has changed on the Web site since the book was issued?" According to the judge: not enough. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Tarball licenses (was: Free documentation licenses)
John, I appreciate the trouble you've been taking on this, especially
the relevant quotations from 17 USC 103. I've been meaning to
straighten out my understanding of this matter, and really should have
read the relevant statutes. Far too much of what's said on this matter
ignores the statutes and legislative history, not to mention caselaw.
(Consider the necessary disclaimer added, about other legal jurisdictions
differing.)
begin John Cowan quotation:
Case 3. Programmer Alice wrote source modules A and B. Her copyright
notice grants BSD usage and distribution rights. You improve module A,
and throw the improved version with module B into tarball X, asserting
in an included file copyright over your "derived work" X and that it is
GPL-covered.
Let us suppose that my changes rise to the level of a derivative work
(reformatting doesn't cut it, e.g.). So now I have module A1.
[...]
If I acquire a license to work A (a public license or otherwise, no
matter), and create from it a derivative work A1, that work A1 is
*copyrightable*, and I may enforce license breaches with respect to
the parts of A1 that are not copied from A.
[...]
Alice licensed me (as a member of the public) to create and distribute
derivative works. As long as I conform to the BSD stipulations, I am
fine.
And this is where I need to slow down and straighten things out. Few
of us have time to pursue the matter properly, and it's easy to get
tripped up by all the varied and conflicting claims, here. For example,
other parties on this list have asserted -- plausibly and without
contradiction -- that only the copyright holder may relicense a work.
At first glance, that allegation would seem to contradict your statement
regarding hypothesised work A1, which you assert to be GPL-licensed, and
which you derived from Alice's BSD-licensed work A. (And, frankly, I'm
not sure that you have _not_ substantively relicensed Alice's work, or
that you would have the right to do so. But let's continue.)
However, if I understand you correctly, you are asserting that you are
_not_ relicensing Alice's work, but rather creating a derivative work
fully in compliance with Alice's terms for the portion she created -- in
the sense that re-using BSD code in creating a GPLed derivative
continues to satisfy the BSD author's conditions.
Anyhow, as I was saying earlier, part of the trick of dealing with these
matters is to use a fruitful mental model. Let's try to picture one,
here: Alice creates A (thereby gaining copyright). She releases it,
after soaking it in BSD sauce. You like it, but mix it with a bunch of
your own ingredients, mixing in GPL extract, calling the result your and
Alice's GPL-flavoured pudding A1 (a derivative work). Which Alice's
choice of sauce indicated would be OK by her.
This reading appears to be shared by, among other people Australian
programmer Eric A. Young, one of the creators of OpenSSL (formerly
SSLeay, after Young's initial): All other coders' modules in OpenSSL
are straight BSD-licensed, but Young's is BSD w/advertising clause plus
the following addition:
* The licence and distribution terms for any publically available
* version or derivative of this code cannot be changed. i.e. this code
* cannot simply be copied and put under another distribution licence
* [including the GNU Public Licence.]
It would certainly be a clean and tidy way to deal with things, to
regard code modules as the atomic unit for licensing issues, such that,
if you work on Alice's A that bears a specific licence, what would
result is a larger or revised A under the same licence, possibly bearing
your name on the copyright statement alongside Alice's. For, of course,
the second party's creative content is essentially impossible to
distinguish (disentangle) from Alice's, and who owns what becomes very
murky on the intra-module level. But the law is the law, and
you (citing 17 USC 103) say it happens to be untidy, here. {sigh}
Bram went on to help Pat Beirne create the MakeDoc utility, whose source
code I eventually tracked down. It likewise has no explicit licence.
Beirne's last version was a Java one, MakeDocJ, which I can no longer
find. However, Jeffrey A. Krzysztow found Beirne's Java code, improved
it, and purports to place the result under the GNU LGPL:
http://linuxmafia.com/pub/palmpilot/MakeDocJ-3.6.0.zip .
I would estimate that Krzysztow's LGPL assertion is simply ineffective,
as it would violate Beirne's rights
Specifically the right to control the making of derivative works.
My point, in part, is that there's probably a great of such derived
works from dubious sources, whose new licence status gets asserted and
semi-established through sheer bluff by a later modifier. When the
original codebase is less trivial than MakeDocJ, this practice can be a
hidden pitfall for programmers, users, and others who rely on the
derived work's (alleged) licence status.
And, in the real
Re: Tarball licenses (was: Free documentation licenses)
Rick Moen wrote: Seems almost like homeopathy, doesn't it? None of Alice's code may remain in A1, but (as you say) its being a derived work remains, and thus the obligation to conform to Alice's licence terms persists. And of course the reason homeopathic pills don't work is that the efficacy of pills depends on the current state, not the historical origin. Another example is the ship of Theseus, which could be found in Athens (in what we'd call a museum) some 500 years after Theseus's death. Every plank had long since been replaced, but the conceptual integrity of the object remained intact. Which raises the interesting question of 4.4 BSD (and progeny) as a work derived from ATT System V UNIX. From 32/V, actually. CSRG was careful never to even look at any ATT code form System III or System V, although in order to receive older BSDs you had to get a System V license, because ATT wouldn't sell any other kind. I seem to recall that the Computer Science Research Group strategy going into the lawsuit involved gradual replacement of ATT code. They did this primarily because the ATT code sucked, but it's widely considered that this was having the effect of gradually creating a non-proprietary codebase. Each individual component of the 32/V base was replaced by something that was copyright-independent of it (neglecting include files and the like, which are not really copyrightable). ATT would have a hard time claiming copyright over 4.4BSD as a whole on the above ship-of-Theseus argument, though, because the relationships as well as the individual modules had been utterly transformed. The 32/V system, e.g., did not even have paging. Are you saying that interpretation is wrong, and that, but for the lawsuit settlement, BSD would have remained subject to ATT's licence terms even after all ATT code was gone? No. ATT's claim was that some of their code was *not* gone, particularly in certain drivers. The University claimed independent invention, and pointed out that ATT's hands were not clean either: they had appropriated some old-BSD licensed code while ignoring the advertising requirement. If you are aware that infringing derivative works have been created, and you do nothing But that's an additional hypothetical, above and beyond just "inaction". It was you who said "it's pretty clear that Beirne doesn't object". How is it clear? -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Tarball licenses (was: Free documentation licenses)
begin John Cowan quotation: And of course the reason homeopathic pills don't work is that the efficacy of pills depends on the current state, not the historical origin. Don't tempt me towards an off-topic disquisition, but you'll want to look up the "Law of Similars" and the "Law of Dilution". It was a decent attempt at a scientific theory when Samuel Hahnemann came up with it a couple of hundred years ago, but the ad-hockery still being used to justify it has become amusing but somewhat sad. Are you saying that interpretation is wrong, and that, but for the lawsuit settlement, BSD would have remained subject to ATT's licence terms even after all ATT code was gone? No. ATT's claim was that some of their code was *not* gone, particularly in certain drivers. That's _not_ the question I was trying to ask. I meant, "_Had_ the lawsuit not interrupted the process, and all ATT code been replaced" I was saying that it would _appear_, from your posted criteria, that 4.4BSD was a derived work from ATT code just as much as any A1 module would have been of Alice's module A, regardless of any subsequent changes. The University claimed independent invention, and pointed out that ATT's hands were not clean either: they had appropriated some old-BSD licensed code while ignoring the advertising requirement. I am quite aware of the latter, having heard (among other things) the long version of McKusick's talk on the subject. But the question of whether CSRG's derived work -- regardless of _which_ ATT codebase it branched from -- retains licence obligations to the original still strikes me as significant. Weren't you saying that a derived work remains a derived work, even after all the original content has been replaced? If so, then why should it matter if the original modules were eventually replaced by wholly new modules that interact in wholly new ways? It was you who said "it's pretty clear that Beirne doesn't object". How is it clear? Well, maybe it's not clear. Maybe that was a vague handwave of my own, having been infected by the sloppiness of sundry programmers. ;- So: Beirne issued makedoc7.cpp without an explicit licence. I _suspect_ that he did likewise for his MakeDocJ (but don't have a copy). Krzysztow says somewhere (his Changelog?) something that made me think Beirne was involved in some way, but I can't remember details. But, the more I've been trying to properly and scrupulously classify my PalmOS software collection, the more skeptical I've become of programmers' vague licence handwaves -- and of my own earlier ones. I _am_ attempting to track down Beirne, out of a stubborn desire to fix the licence status of what is, objectively, some fairly insignificant code. But the need (however reduced by the antiquity and insignificance of the project) to _attempt_ this, with no guarantee of success, underlines why licence information really needs to accompany the affected code in the first place. -- Cheers, "Reality is not optional." Rick Moen -- Thomas Sowell [EMAIL PROTECTED]
RE: Free documentation licenses
On Wed, 29 Nov 2000, Nelson Rush wrote: The GPL shouldn't be used for documentation, it is intended for use with software. I think RMS one time agreed with me on this when it came up in one of my other projects. Which is why he created the FDL, which is specifically designed for documentation. Be that as it may, if you publish a book which contains full source with detailed commentary (like the TeX and METAFONT sourcebooks or the Lions Book), the book is going to be a derivative work of the program. Do you suppose that if you got ahold of the Windows source code and published it in such a book that Microsoft wouldn't scream "Copyright violation!", and rightly so? What is, or is not, a derivative work is a matter for the law (ultimately, the courts), not the wording of any license, and the GPL goes out of its way to say so. Very simply: book containing full source is a derivative work of the source source is under the GPL GPL says derivative works must be under the GPL too -- book can only be published under the GPL None of this applies to a book that merely comments on the program, or uses at most fair-use excerpts from it, like the Linux kernel book. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Re: Free documentation licenses
begin John Cowan quotation: Well, that's not the whole truth either. I could take a bunch of BSD modules, create a derivative work, and license the result under the GPL. Or under a proprietary license, for that matter. No, not exactly (unless you _own copyright_ on those modules). I don't think you're quite understanding my point: You would remain bound to the obligations of those modules' BSD licence. (But, of course, there _are_ no BSD-licence obligations to speak of.) The modules' individual copyright licence statements would have to remain intact in copies of the source code. Otherwise, you are violating the copyright holder's terms. Of course, this is somewhat pointless, since you could do exactly the same thing with the same modules and license it under a different license. I'm having a difficult time parsing the above sentence. Perhaps after coffee, I'll have an easier time. -- Cheers, "Reality is not optional." Rick Moen -- Thomas Sowell [EMAIL PROTECTED]
Re: Free documentation licenses
John Cowan wrote: On Wed, 29 Nov 2000, Nelson Rush wrote: The GPL shouldn't be used for documentation, it is intended for use with software. I think RMS one time agreed with me on this when it came up in one of my other projects. Which is why he created the FDL, which is specifically designed for documentation. Be that as it may, if you publish a book which contains full source with detailed commentary (like the TeX and METAFONT sourcebooks or the Lions Book), the book is going to be a derivative work of the program. Scott Maxwell's "Linux Core Kernel Commentary" seems to argue otherwise. This book (published by Coriolis) contains a very large extract of the Linux source code (license GPL), followed by a short commentary (copyright, all rights reserved). I don't know what Coriolis's thinking was, but I can imagine two plausible justifications: 1) The book itself is an aggregation. (The book also provides a CDROM, so the GPL source code is also available in usable form, which is after all the primary concern of GPL.) 2) The GPL license has the side effect of significantly expanding the bounds of fair use -- primarily by making it hard to argue that any amount of fair use quotation economically impacts the copyright holder. I would think that an in-line commentary could not be justified as an aggregation -- that this would depend on fair use. I also think that extended fair use is consistent with the intent of GPL, which is to keep the source code public and freely accessible and reusable. TeX and Metafont are slightly different cases, since the doc is woven into the program source -- effectively, the doc and source are one. Nonetheless, the published books (my copies are Addison-Wesley, 1986) have conventional all rights reserved copyrights. The sources, of course, are not GPL, and even if they were the copyright holder would be entitled to do this. Do you suppose that if you got ahold of the Windows source code and published it in such a book that Microsoft wouldn't scream "Copyright violation!", and rightly so? Depends on the license. If there is no license, all rights are reserved, so one would have to depend on fair use. ESR has claimed that his publication of Microsoft's "Halloween" documents is defensible under fair use. What is, or is not, a derivative work is a matter for the law (ultimately, the courts), not the wording of any license, and the GPL goes out of its way to say so. Very simply: book containing full source is a derivative work of the source source is under the GPL GPL says derivative works must be under the GPL too -- book can only be published under the GPL Maxwell's book, noted above, is a counter-example. None of this applies to a book that merely comments on the program, or uses at most fair-use excerpts from it, like the Linux kernel book. Maxwell's quotation is 39338 lines of code. -- /* * Tom Hull * [EMAIL PROTECTED] * http://www.ocston.org/~thull/ */
Re: Free documentation licenses
Rick Moen wrote: Well, that's not the whole truth either. I could take a bunch of BSD modules, create a derivative work, and license the result under the GPL. Or under a proprietary license, for that matter. No, not exactly (unless you _own copyright_ on those modules). I don't think you're quite understanding my point: You would remain bound to the obligations of those modules' BSD licence. (But, of course, there _are_ no BSD-licence obligations to speak of.) The modules' individual copyright licence statements would have to remain intact in copies of the source code. Otherwise, you are violating the copyright holder's terms. Everything you say is true. However, the *derivative work* itself is your creation (minimal as that creation is) and has its own copyright. To that copyright you can attach a license, as long as it is not inconsistent with the licenses of the components. In the alternative, it is a compilation, and then you can assert a compilation copyright which need not even be consistent (a proprietary CD can contain GPLed software, e.g.) Of course, this is somewhat pointless, since you could do exactly the same thing with the same modules and license it under a different license. I'm having a difficult time parsing the above sentence. Perhaps after coffee, I'll have an easier time. Assume the existence of modules A and B, licensed as BSD, which neither you nor I wrote. I then create work X by combining A and B into a single file/package. I can issue X under the GPL. You cannot then add proprietary module C to it. However, you can go back to A and B and create a proprietary program A+B+C, bypassing X altogether, so what I have done doesn't limit you in any practical way. All of this is fairly theoretical, of course, since people usually add at least one module of their own when creating a program; programs built *entirely* out of existing parts, without even any glue, are probably rare. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Free documentation licenses
Tom Hull wrote: Scott Maxwell's "Linux Core Kernel Commentary" seems to argue otherwise. This book (published by Coriolis) contains a very large extract of the Linux source code (license GPL), followed by a short commentary (copyright, all rights reserved). I don't know what Coriolis's thinking was, but I can imagine two plausible justifications: 1) The book itself is an aggregation. I think that's correct. So the commentary is copyright, and there is a (not very useful) compilation copyright on the book. Maxwell's quotation is 39338 lines of code. I was actually thinking of _Linux Programming White Papers_, which clearly makes fair use of the kernel source. I think if Maxwell's commentary were inline, there wouldn't be any question that the result was a derivative work. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Free documentation licenses
begin John Cowan quotation: Rick Moen wrote: Well, that's not the whole truth either. I could take a bunch of BSD modules, create a derivative work, and license the result under the GPL. Or under a proprietary license, for that matter. No, not exactly (unless you _own copyright_ on those modules). I don't think you're quite understanding my point: You would remain bound to the obligations of those modules' BSD licence. (But, of course, there _are_ no BSD-licence obligations to speak of.) The modules' individual copyright licence statements would have to remain intact in copies of the source code. Otherwise, you are violating the copyright holder's terms. Everything you say is true. However, the *derivative work* itself is your creation (minimal as that creation is) and has its own copyright. (We will return later to this assertion, and my original point that it's most useful to state that only the components of a work have licences. But first:) I think we're hung up here on the wording of the original hypothetical, which was somewhat vague. It was "I could take a bunch of BSD modules, create a derivative work, and license the result under the GPL. Or under a proprietary license, for that matter." The phrase "create a derivative work", here, is somewhat non-specific. Yes, I'm quite familiar with the nature of compilation copyrights, having asserted one over the content of my BBS taken as a whole, a decade or so ago. Ah, I see that you've posted a specific example involving third-party code modules. Good. Let's examine it: Assume the existence of modules A and B, licensed as BSD, which neither you nor I wrote. I then create work X by combining A and B into a single file/package. I can issue X under the GPL. Can you? And what do you mean, specifically? Case 1. Programmer Alice wrote source modules A and B. Her copyright notice grants BSD usage and distribution rights. You put A and B into a tarball, making no changes to them, and assert in an included file copyright over your "derived work" and that it is GPL-covered. Here, it is clear that you have delusions of grandeur and own (at best) the very thinnest of possible _compilation_ copyrights. That is, you own the arrangement and selection of files you carried out in assembling the tarball. Your assertion that the "derived work" is GPL-covered in no way prevents user Bob from unpacking the tarball, extracting modules A and B, dropping your package README in the bitbucket, and creating some proprietary composite of his own that incorporates A and B. Case 2. Programmer Alice wrote source modules A and B. Her copyright notice grants BSD usage and distribution rights. You put A and B into tarball X, making no changes to them, add module C that you created and GPL-license, and assert in an included file copyright over your "derived work" and that it is GPL-covered. Here, your property consists of module C and the title you assert over tarball X, which again is essentially a compilation copyright. Bob swoops in again, spits on your README, and uses A and B in his proprietary product. Case 3. Programmer Alice wrote source modules A and B. Her copyright notice grants BSD usage and distribution rights. You improve module A, and throw the improved version with module B into tarball X, asserting in an included file copyright over your "derived work" X and that it is GPL-covered. Case 3a. You alter module A's copyright notice to assert that it was created by Alice _and_ you, and that it's now GPLed. Case 3b. You alter module A's copyright notice to assert that it was created by Alice _and_ you, and that some of the file is BSD-licensed and some of it GPLed. Case 3c. You leave module A's copyright notice alone. Here, your property consists of some claim to module A and (if you care) compilation copyright on tarball X. You rightfully point out that A has now moved beyond Alice's accomplishment, and assert that you deserve copyright over the difference as being your creative work. But I doubt (IANAL) that you can effectively assert that right and have it upheld, as your work is thoroughly entangled in Alice's, which you're not entitled to relicense unless you acquire her copyright. (Anyone have reason to think otherwise? Case law? Speak up.) In 3a, Alice hauls you into court over copyright infringement, and prevails: You attempted to misappropriate her property, and will be rapped over the knuckles. Meanwhile, Bob can successfully ignore your assertion about A. In 3b, Alice will be pissed off over the hash you've created. Maybe she will prevail in court on grounds that you've substantively attempted a disallowed relicensing of her work; I don't know. Bob will probably in the real world ignore tarball X and pull her original module A out of a package with fewer legal complications. Whether he can get away with using your version
Re: Free documentation licenses
I wrote: In 3b, Bob takes from X your new version of Alice's BSD codebase, and ^ maybe sends you a thank-you note. Should be "3c".
Re: Free documentation licenses
John Cowan wrote: Tom Hull wrote: Scott Maxwell's "Linux Core Kernel Commentary" seems to argue otherwise. This book (published by Coriolis) contains a very large extract of the Linux source code (license GPL), followed by a short commentary (copyright, all rights reserved). I don't know what Coriolis's thinking was, but I can imagine two plausible justifications: 1) The book itself is an aggregation. I think that's correct. So the commentary is copyright, and there is a (not very useful) compilation copyright on the book. Maxwell's quotation is 39338 lines of code. I was actually thinking of _Linux Programming White Papers_, which clearly makes fair use of the kernel source. I agree, but it's kind of a moot point, given that the book is itself GPL. This is not because it quotes GPL code. It's because some of the documents included were already GPL, and the exception was licensed under terms that could be relicensed as GPL. I think if Maxwell's commentary were inline, there wouldn't be any question that the result was a derivative work. I'm not so sure. I could see it as fair use, especially given that the commentary does not monetarily undermine the copyright holder, and that it does not subvert the GPL on the code. But I'm hard pressed to think of a good test case. I think that maintainable commentary should be somehow wed to the source code, and as such should follow the source code's license. I could imagine someone writing a book as sort of an introductory programming tutorial, which would take one or more GPL programs in toto and interleave detailed commentary, but in such a case I'm sure any conventional publisher would seek permission first. -- /* * Tom Hull * [EMAIL PROTECTED] * http://www.ocston.org/~thull/ */
Re: Free documentation licenses
begin David Johnson quotation: I think what John meant was similar to to following analogy: You are a book publisher and wish to release an anthology. All of the short stories you wish to include are licensed under the BSD license. You can release the anthology under the GPL license. A reader of your anthology cannot redistribute it under any terms except the GPL. However, a reader can redistribute the individual stories under the terms of the BSD license. That would be (an extremely thin) compilation copyright, as discussed separately. Such are somewhat more real-world significant for paper books, with chapters bound together and not really practical to cut apart and glue back differently, than they would be for adding a GPL COPYING file to BSD modules A and B, and claiming you have GPL title to the "derived work" the tarball constitues. That would be a rather W.S. Gilbert sort of intellectual property, methinks. Not that it doesn't happen; just that it's rather silly. -- Cheers, "Reality is not optional." Rick Moen -- Thomas Sowell [EMAIL PROTECTED]
Re: Free documentation licenses
[EMAIL PROTECTED] wrote: In the general case, if the documentation is to be freely redistributable to a large license, a license which allows distribution under terms at least as liberal as the software license should be sufficient. Indeed, but that is a general point not specific to documentation. It is commonplace for parts of a GPLed software package to be released under newBSD/MIT. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Free documentation licenses
on Tue, Nov 28, 2000 at 01:43:59PM -0500, John Cowan ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: In the general case, if the documentation is to be freely redistributable to a large license, a license which allows distribution under terms at least as liberal as the software license should be sufficient. Indeed, but that is a general point not specific to documentation. It is commonplace for parts of a GPLed software package to be released under newBSD/MIT. No, it is specific to documentation, so long as the documentation doesn't incorporate code from the project. Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I don't believe there's anything in the GNU GPL, e.g., which prohibits publishing of the source code within a book, so long as the source itself is clearly identified as GPLd. Your example is backwards: newBSD/MIT software can be relicensed under GPL. GPLd software cannot be relicensed, by third parties, under any other license (barring GPL versioning allowances), without specific authorization from the copyright holder(s). IANAL, this is not legal advice. -- Karsten M. Self [EMAIL PROTECTED] http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Free documentation licenses
[EMAIL PROTECTED] wrote: No, it is specific to documentation, so long as the documentation doesn't incorporate code from the project. My point was that it is convenient for documentation and software to be under the same license, so that the same set of persons can make revisions to both in synchrony. If the software were BSD and the doco GPL, then if I make a proprietary version of the software, then I have two unpalatable alternatives: write a manual for the proprietary version from scratch, or issue the manual for the proprietary version under the GPL. If the software were GPL and the doco BSD, then if anyone rewrote the doco for greater clarity or some such, then he would be able to make the improved version proprietary and prevent it from being distributed with current or future releases of the program. Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I agree; my argument speaks to expediency, not necessity. I don't believe there's anything in the GNU GPL, e.g., which prohibits publishing of the source code within a book, so long as the source itself is clearly identified as GPLd. I can't see this. A book which incorporates all of another textual work strikes me as a paradigm case of a derivative work. IANAL, but such a book looks clearly derivative of the source code and as such would have to be published under the GPL. Your example is backwards: newBSD/MIT software can be relicensed under GPL. GPLd software cannot be relicensed, by third parties, under any other license (barring GPL versioning allowances), without specific authorization from the copyright holder(s). The term "relicense" should be avoided, as it leads to wifty thinking. No one but the copyright holder can "relicense" anything, in the sense of changing the license. You can create a *derivative* work containing BSD parts and GPL parts, and license the whole work under the GPL. You cannot license the whole work under the BSD license. You also cannot change the licenses of the parts. In particular, I can extract a BSD-licensed component from a GPL-licensed work and use it in derivative works under the BSD license. -- There is / one art || John Cowan [EMAIL PROTECTED] no more / no less|| http://www.reutershealth.com to do / all things || http://www.ccil.org/~cowan with art- / lessness \\ -- Piet Hein
Re: Free documentation licenses
We're also trying to figure out a documentation license for the Mozilla Project. One reason we've talked about using the same license for documentation and code is that it can be difficult to separate the two. For example, the Help documentation is included in electronic format as part of the source code. It seems odd to treat this documentation under one license in this format and under another license if it's printed. And even odder to say that the help documentation in the code is not governed by the MPL, but by a different documenation license. Has anyone sorted through this type of problem? Apologies if this has been discussed and I missed the thread. Mitchell John Cowan wrote: [EMAIL PROTECTED] wrote: No, it is specific to documentation, so long as the documentation doesn't incorporate code from the project. My point was that it is convenient for documentation and software to be under the same license, so that the same set of persons can make revisions to both in synchrony. If the software were BSD and the doco GPL, then if I make a proprietary version of the software, then I have two unpalatable alternatives: write a manual for the proprietary version from scratch, or issue the manual for the proprietary version under the GPL. If the software were GPL and the doco BSD, then if anyone rewrote the doco for greater clarity or some such, then he would be able to make the improved version proprietary and prevent it from being distributed with current or future releases of the program. Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I agree; my argument speaks to expediency, not necessity. I don't believe there's anything in the GNU GPL, e.g., which prohibits publishing of the source code within a book, so long as the source itself is clearly identified as GPLd. I can't see this. A book which incorporates all of another textual work strikes me as a paradigm case of a derivative work. IANAL, but such a book looks clearly derivative of the source code and as such would have to be published under the GPL. Your example is backwards: newBSD/MIT software can be relicensed under GPL. GPLd software cannot be relicensed, by third parties, under any other license (barring GPL versioning allowances), without specific authorization from the copyright holder(s). The term "relicense" should be avoided, as it leads to wifty thinking. No one but the copyright holder can "relicense" anything, in the sense of changing the license. You can create a *derivative* work containing BSD parts and GPL parts, and license the whole work under the GPL. You cannot license the whole work under the BSD license. You also cannot change the licenses of the parts. In particular, I can extract a BSD-licensed component from a GPL-licensed work and use it in derivative works under the BSD license.
Re: Free documentation licenses
On Tuesday 28 November 2000 02:26 pm, John Cowan wrote: If the software were GPL and the doco BSD, then if anyone rewrote the doco for greater clarity or some such, then he would be able to make the improved version proprietary and prevent it from being distributed with current or future releases of the program. As long as the original documentation is available, I don't think it makes much of a difference (depending on the wishes of the author, of course). To take a specific example, a "proprietary" SAMS or IDG manual on emacs does not limit the emacs software in any way. A proprietarized derivitive would likewise have no effect on the emacs software, though RMS would be upset over it for other reasons. -- David Johnson ___ http://www.usermode.org
Re: Free documentation licenses
begin John Cowan quotation: The term "relicense" should be avoided, as it leads to wifty thinking. No one but the copyright holder can "relicense" anything, in the sense of changing the license. You can create a *derivative* work containing BSD parts and GPL parts, and license the whole work under the GPL. You cannot license the whole work under the BSD license. You also cannot change the licenses of the parts. In particular, I can extract a BSD-licensed component from a GPL-licensed work and use it in derivative works under the BSD license. This is an excellent (and key) point. At work, I've tried to explain the matter by saying it's best to think of a composite work as not _having_ a licence, per se: The individual modules bear licences. The resulting composite, then, either is or is not legally distributable, depending on how those licence terms interact. -- Cheers, "Reality is not optional." Rick Moen -- Thomas Sowell [EMAIL PROTECTED]
Re: Free documentation licenses
on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I agree; my argument speaks to expediency, not necessity. Indicating general agreement. I don't believe there's anything in the GNU GPL, e.g., which prohibits publishing of the source code within a book, so long as the source itself is clearly identified as GPLd. I can't see this. A book which incorporates all of another textual work strikes me as a paradigm case of a derivative work. IANAL, but such a book looks clearly derivative of the source code and as such would have to be published under the GPL. The way I read 3(c), the GNU GPL refers to the program, but doesn't preclude its inclusion into a larger, ***nonprogram*** work: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. My including, say, a T.S. Eliot poem in a manuscript of my own authorship doesn't give me rights to dictate terms for republication of the poem, but neither do its rights infect the manuscript. Which doesn't translate strictly to the GPL, but I'd say that the informal definition of source code above in the GPL might allow one to make the argument that a GPLd work within a larger work represents a "mere aggregation" in storage medium of two seperate works -- the text and the GPLd source. Your example is backwards: newBSD/MIT software can be relicensed under GPL. GPLd software cannot be relicensed, by third parties, under any other license (barring GPL versioning allowances), without specific authorization from the copyright holder(s). The term "relicense" should be avoided, as it leads to wifty thinking. No one but the copyright holder can "relicense" anything, in the sense of changing the license. You can create a *derivative* work containing BSD parts and GPL parts, and license the whole work under the GPL. You cannot license the whole work under the BSD license. You also cannot change the licenses of the parts. In particular, I can extract a BSD-licensed component from a GPL-licensed work and use it in derivative works under the BSD license. "Additionally licensed" might be a better phrase, though I tend to like your phrasing better than my original. As I understand it would be possible to simply publish without modification a newBSD/MIT work under the terms of the GPL. The work is effectively dual-licensed. Downstream modifications from this tree would be governed, as a whole, by the GPL. The original code would still be available under the terms of newBSD/MIT, as appropriate. From a strategic perspective, I'm coming to feel that it's the *possibility* of such a license-driven code fork of newBSD/MIT code which may be serving to help secure the availability of projects under these licenses in free versions. A credible proprietized fork would likely be countered by a GPL or otherwise copylefted fork. This is portrayed in its effect of tendency for code to avoid forking in Bob Young's licensing diagram, found in the back of _Under the Radar_. A similar diagram is used by Don Rosenberg in his _Unauthorized White Papers_, though his placement of the BSD/MIT license is significantly different from Young's. -- Karsten M. Self [EMAIL PROTECTED] http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Free documentation licenses
Karsten Self wrote: on Tue, Nov 28, 2000 at 05:26:20PM -0500, John Cowan ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: [...] The way I read 3(c), the GNU GPL refers to the program, but doesn't preclude its inclusion into a larger, ***nonprogram*** work: [...] I think section 2 has a lot to say about this. Its wording makes no - and allows no - distinction between programs and non-programs. However you may aggregate works together. So even though documentation and your program are distributed together, since each can be used independently of the other I would argue that that is just aggregation. An interesting precedent that related things shipped together need not be a single work under the GPL - the text of the GPL (which is shipped with many GPLed products) has a copyright that is in no way compatible with being part of a GPLed whole! Cheers, Ben PS IANAL etc. _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: Free documentation licenses
On Tue, 28 Nov 2000, Rick Moen wrote: At work, I've tried to explain the matter by saying it's best to think of a composite work as not _having_ a licence, per se: The individual modules bear licences. The resulting composite, then, either is or is not legally distributable, depending on how those licence terms interact. Well, that's not the whole truth either. I could take a bunch of BSD modules, create a derivative work, and license the result under the GPL. Or under a proprietary license, for that matter. Of course, this is somewhat pointless, since you could do exactly the same thing with the same modules and license it under a different license. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Re: Free documentation licenses
on Tue, Nov 28, 2000 at 02:43:13PM -0800, Mitchell Baker ([EMAIL PROTECTED]) wrote: John Cowan wrote: [EMAIL PROTECTED] wrote: ... Software and its accompanying documentation are generally considered two seperate works. There is no licensing compatibility requirement between the docs and the code. Even where short samples of code could be used in the document, they could be incorporated under fair use 107 exemptions or (possibly) by turning the document as a whole into a collective work. I agree; my argument speaks to expediency, not necessity. We're also trying to figure out a documentation license for the Mozilla Project. One reason we've talked about using the same license for documentation and code is that it can be difficult to separate the two. For example, the Help documentation is included in electronic format as part of the source code. It seems odd to treat this documentation under one license in this format and under another license if it's printed. And even odder to say that the help documentation in the code is not governed by the MPL, but by a different documenation license. Has anyone sorted through this type of problem? Apologies if this has been discussed and I missed the thread. John and I were arguing slightly different points. Where docs are clearly differentiated from code, independent licensing is an *option*. In the instance you describe, the close relationship makes the distinction harder to draw. I'd also look at some of the issues addressed in documentation licenses which are different from those of software -- the GFDL deals with several of these, though some could perhaps be more rigorously defined (e.g.: output-only HTML). -- Karsten M. Self [EMAIL PROTECTED] http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Free documentation licenses
On Tue, 28 Nov 2000, Ben Tilly wrote: I think section 2 has a lot to say about this. Its wording makes no - and allows no - distinction between programs and non-programs. However you may aggregate works together. So even though documentation and your program are distributed together, since each can be used independently of the other I would argue that that is just aggregation. Right. But a GPLed program in a book with commentary produces a GPLed book. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Re: Free documentation licenses
I have written such a license (IMHO) which is pending approval by OSI, and has been 'ok'ed for use on Sourceforge (who generally require OSI approval). It can be found at http://www.simpleLinux.org/legal/sLODL.html It's still not completely finished - I am waiting for feedback here (possibly some more constructive than the usual 'why bothers' I have received, asking why use a seperate doc license at all) before I finalise it. However, looking at your points, it may still be too restrictive for you - but you may as well just use the GPL - the license you propose isn't really a license as such, just a copyright with some brief, clearly stated permissions and restrictions. I like the simpleLinux Open Documnetation License (by me) as it ensures that not only is the authorship never misrepresented, but also that content added later by a person outside the controlling organisation is impossible to confuse with original text. It also provides protection against misrepresentation when people quote it. I like it anyway - see what you think... SamBC - Original Message - From: "David Johnson" [EMAIL PROTECTED] To: "License-Discuss" [EMAIL PROTECTED] Sent: Monday, November 27, 2000 7:26 AM Subject: Free documentation licenses I am in the process of writing a user manual and did some checking around for appropriate free licenses. Unfortunately, I didn't find anything suitable. The GFDL is just too much and contains undesired restrictions. Other licenses listed on the GNU page were not applicable either, for pretty much the same reasons listed by RMS. The Nupedia license is also unacceptable for various reasons. Variations of any of the above might work. So, any alternatives out there that I missed? I'm thinking of writing my own if there is no alternative available. In such a case, a very rough draft follows. I want something short, simple and to the point. I was thinking of some form of weak copyleft, but I don't know how applicable it would be to a document since the content would always be available. I'm also wondering whether an attribution requirement would cause any problems. --- [Free Text License] Copyright (c) YEAR, OWNER All rights reserved. Redistribution of this document, with or without modification, is permitted provided that the following conditions are met: Redistributions must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions must not misrepresent the authorship of this document. Neither the name of the author(s) nor the names of its contributors may be used to endorse or promote products derived from this document without specific prior written permission. THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. -- David Johnson ___ http://www.usermode.org
Re: Free documentation licenses
On Sun, 26 Nov 2000, David Johnson wrote: I am in the process of writing a user manual and did some checking around for appropriate free licenses. Unfortunately, I didn't find anything suitable. IMHO it makes sense to release a manual under the same license as the software, so that it can be changed in synchrony with the software. What you have here looks like a close variant of new-BSD. If you are releasing the software under new-BSD, then use new-BSD as the documentation license as well. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Re: Free documentation licenses
- Original Message - From: "John Cowan" [EMAIL PROTECTED] IMHO it makes sense to release a manual under the same license as the software, so that it can be changed in synchrony with the software. What you have here looks like a close variant of new-BSD. If you are releasing the software under new-BSD, then use new-BSD as the documentation license as well. What if, however, as in my case, you are writing standalone documentation to software you did not produce, or detailing techniques, or even an academic treatise... the sLODL is suitable for all... http://www.simpleLinux.org/legal/sLODL.html SamBC
Re: Free documentation licenses
On Mon, 27 Nov 2000, SamBC wrote: - Original Message - From: "John Cowan" [EMAIL PROTECTED] IMHO it makes sense to release a manual under the same license as the software, so that it can be changed in synchrony with the software. What you have here looks like a close variant of new-BSD. If you are releasing the software under new-BSD, then use new-BSD as the documentation license as well. What if, however, as in my case, you are writing standalone documentation to software you did not produce, The same applies. If the software can be changed under given conditions, it should be possible to change the documentation under the same conditions, or the two cannot be kept mutually up-to-date. A GPLed program should have GPLed documentation; a BSDed program should have BSDed documentation, IMHO. or detailing techniques, or even an academic treatise... the sLODL is suitable for all... Those cases are out of my scope. -- John Cowan [EMAIL PROTECTED] One art/there is/no less/no more/All things/to do/with sparks/galore --Douglas Hofstadter
Re: Free documentation licenses
- Original Message - From: "John Cowan" [EMAIL PROTECTED] What if, however, as in my case, you are writing standalone documentation to software you did not produce, The same applies. If the software can be changed under given conditions, it should be possible to change the documentation under the same conditions, or the two cannot be kept mutually up-to-date. A GPLed program should have GPLed documentation; a BSDed program should have BSDed documentation, IMHO. The docs I am doing are intended to supplement official stuff, not be canonical. I created the license to go with a WiP suite of beginners (I mean *really* beginners) docs for Linux. That applies to so many programs, not all of them GPL/LGPL, so it needs to be flexible. Get the idea? Not terribly important for this list anyway - unless people watnt to discuss my license (please). http://www.simpleLinux.org/legal/sLODL.html or detailing techniques, or even an academic treatise... the sLODL is suitable for all... Those cases are out of my scope. The idea being it is a flexible license for all sorts of written works, delivered electronically (or otherwise)
Re: Free documentation licenses
David Johnson wrote: The Nupedia license is also unacceptable for various reasons. I'd be curious to hear what problems the Nupedia license has for your project. As a side note, we are (at the suggestion of RMS) re-considering the GFDL for Nupedia. One major advatage that using a FSF-sponsored license can give you is "open source credibility". We have found that many people are suspicious that people in the open content movement are just trying to ride on the prestige of open source, and that people fear that the content isn't _really_ open. Using a Gnu license lets people know that we are serious. Also, although I dismissed the GFDL on a first reading as "too much", upon a second reading, I realized that the "invariant sections" stuff is exactly what we wanted, in terms of implementing an atttribution requirement. Still, I liked the original Nupedia license, and we are going slow in our reconsideration. --Jimbo
Re: Free documentation licenses
on Mon, Nov 27, 2000 at 08:13:58AM -0500, John Cowan ([EMAIL PROTECTED]) wrote: On Sun, 26 Nov 2000, David Johnson wrote: I am in the process of writing a user manual and did some checking around for appropriate free licenses. Unfortunately, I didn't find anything suitable. IMHO it makes sense to release a manual under the same license as the software, so that it can be changed in synchrony with the software. What you have here looks like a close variant of new-BSD. If you are releasing the software under new-BSD, then use new-BSD as the documentation license as well. I'm not sure license conformance between software and documentation is necessary for synchrony. There might be reasons for making documentation licensing more or less restrictive than software licensing. Unless there is inclusion of significant code in the documentation, the issue of compatability may simply be immaterial. In the general case, if the documentation is to be freely redistributable to a large license, a license which allows distribution under terms at least as liberal as the software license should be sufficient. David's license is largely similar to a BSD/MIT license, and looks on first glance to be relatively reasonable. I gather that the strong persistance features of the GPL are not of interest to him. The one benefit to conformant licensing I can see is that the downstream distributer/modifier doesn't have to deal with multiple sets of licensing terms in deciding how the work or derived works can be (re)distributed. IANAL, this is not legal advice. -- Karsten M. Self [EMAIL PROTECTED] http://www.netcom.com/~kmself Evangelist, Zelerate, Inc. http://www.zelerate.org What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/http://www.kuro5hin.org PGP signature
Re: Free documentation licenses
On Monday 27 November 2000 05:13 am, John Cowan wrote: IMHO it makes sense to release a manual under the same license as the software, so that it can be changed in synchrony with the software. What you have here looks like a close variant of new-BSD. If you are releasing the software under new-BSD, then use new-BSD as the documentation license as well. The software in question is under the GPL. I have thought seriously about releasing the documentation under the GPL as well. But a software license just doesn't fit well for documentation. I am also contacting the developer I am writing for to get his opinions, but he'll probably leave it all up to me. After all, he's overjoyed that someone stepped up to write it in the first place :-) I am heavily leaning towards the GFDL, but it still seems overkill for this document (it's a small to medium application handbook). If all else fails I'll probably wind up using the GFDL to at least add synchonicity with the application. In a later missive The same applies. If the software can be changed under given conditions, it should be possible to change the documentation under the same conditions, or the two cannot be kept mutually up-to-date. A very good point. But the document's license doesn't have to be the same as the application's for the benefit. It can also use a less restrictive license and achieve the same goal. -- David Johnson ___ http://www.usermode.org
Re: Free documentation licenses
On Monday 27 November 2000 11:30 am, [EMAIL PROTECTED] wrote: David's license is largely similar to a BSD/MIT license, and looks on first glance to be relatively reasonable. I gather that the strong persistance features of the GPL are not of interest to him. For API documentation, reference manuals, academic texts and the like, copyleft would be very useful. But for my own informal instructional text to the new user, I don't see any benefit. By it's nature, a text is naturally open in a way that a software application is not. The one benefit to conformant licensing I can see is that the downstream distributer/modifier doesn't have to deal with multiple sets of licensing terms in deciding how the work or derived works can be (re)distributed. And for this reason I am heavily leaning towards the GFDL anyway, in order to be more conformant with the developer's GPL application. -- David Johnson ___ http://www.usermode.org
Free documentation licenses
I am in the process of writing a user manual and did some checking around for appropriate free licenses. Unfortunately, I didn't find anything suitable. The GFDL is just too much and contains undesired restrictions. Other licenses listed on the GNU page were not applicable either, for pretty much the same reasons listed by RMS. The Nupedia license is also unacceptable for various reasons. Variations of any of the above might work. So, any alternatives out there that I missed? I'm thinking of writing my own if there is no alternative available. In such a case, a very rough draft follows. I want something short, simple and to the point. I was thinking of some form of weak copyleft, but I don't know how applicable it would be to a document since the content would always be available. I'm also wondering whether an attribution requirement would cause any problems. --- [Free Text License] Copyright (c) YEAR, OWNER All rights reserved. Redistribution of this document, with or without modification, is permitted provided that the following conditions are met: Redistributions must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions must not misrepresent the authorship of this document. Neither the name of the author(s) nor the names of its contributors may be used to endorse or promote products derived from this document without specific prior written permission. THIS DOCUMENT IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. -- David Johnson ___ http://www.usermode.org
