Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wednesday 13 April 2005 10:13 pm, Raul Miller wrote: What compels you to agree with an EULA? On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote: If you do not agree with the EULA, you cannot and do not acquire lawful possession of the work. What about cases where you pay for the software before you're allowed to see the EULA? It is enforcable and is called a rolling contract. Seminal case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Circut, 1996). -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 01:22:56 +0200, Francesco Poli escribía: A: The DFSG is a set of minimum criteria that are taken into account when deciding if a particular copyright license is free or not. I would prefer if a particular /work/ is free or not. Actually, it would be a mix of both: if a particular work, with its copyright license, is free or not. [...] the existence of different DFSG and DFDG would mean that there are some freedoms that are necessary for programs but are irrelevant for documents, and vice versa [...] I would add Nobody has yet provided a convincing rationale to explain *why* programs and documents should need a different minimum set of freedoms. The Debian project claims that the same freedoms are important for both programs and documents. Agreed; I intended to add something like this all along, but I finally forgot it. Thanks for adding it :-) A: First, standards documents should be modifiable: that's how old standards are improved and new standards are made. Modifying a copy of a standards document, such as a RFC, does not modify the RFC itself. [...] they fail to see the difference between creating a derivative work and modifying the work itself [...] I'll add ; it just creates a new work, derivative of the original RFC to the sentence, since the derivative work bit is important :-) Perhaps it's better avoiding recommending trademarks or otherwise we should be prepared to see more and more Mozilla-like mess in the future... :-( Mmmm, you are right. I'll delete the comment about trademark laws (will leave the reference to libel), but they will eventually have to be mentioned, since I believe that they're the ones to be used for protecting the reputation of the authors/of the original works, etc., etc., not a clause in the copyright license. But while the implications of using trademark law for this are not fully explored by us and put into writing, perhaps they're best left out of this FAQ... (I was going to remove slander, since slander is speech and libel is writing, but perhaps someone would modify a voice recording just to prove me wrong, so... ;-)). [Comment] Good example. My favorite one is the following: if the license of a MUA forbade to add HTML mail support (because the authors are philosophically against HTML mail), this license would be considered non-free, even when it would be protecting the authors' own opinions. This is even a better example than mine. I'll change mine to this (the old one is kept saved in the page's [1] history). == [1] http://jacobo.tarrio.org/Documentation_licensing_FAQ -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 10:15:25AM +0200, Jacobo Tarrio wrote: Perhaps it's better avoiding recommending trademarks or otherwise we should be prepared to see more and more Mozilla-like mess in the future... :-( Mmmm, you are right. I'll delete the comment about trademark laws (will leave the reference to libel), but they will eventually have to be mentioned, since I believe that they're the ones to be used for protecting the reputation of the authors/of the original works, etc., etc., not a clause in the copyright license. It could also be fraud, or (strangely enough) in some jurisdictions, copyright. Although not the part of copyright law that is related to licensing; the right to not have things misattributed to you cannot be waived, transferred, or otherwise licensed. But it is sometimes written into the copyright statute rather than anywhere else. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 09:37:12 +0100, Andrew Suffield escribía: It could also be fraud, or (strangely enough) in some jurisdictions, copyright. Although not the part of copyright law that is related to licensing; the right to not have things misattributed to you cannot be waived, transferred, or otherwise licensed. But it is sometimes written into the copyright statute rather than anywhere else. And that's why don't use the name «apache» or don't misattribute me clauses in copyright licenses are stupid: because then I might create a completely new work called «apache» or attributed to that author without contravening the terms of these licenses. What stops me from doing these things are other laws. If I find the right wording, I'll add it to my FAQ proposal. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 11:03:06AM +0200, Jacobo Tarrio wrote: And that's why don't use the name «apache» or don't misattribute me clauses in copyright licenses are stupid: because then I might create a completely new work called «apache» or attributed to that author without contravening the terms of these licenses. What stops me from doing these things are other laws. Of course, for the same reason, don't modify this standards document is stupid: if my intent is to confuse people, I could create an entirely original document and claim that it's RFC1234. Renaming requirements, stupid as they are (what about my helicopter sim, Apache Combat, and my military combat game, Apache Warriors?), are a big step up from complete invariance, though. (At least the new Apache license dropped that dumb clause--but not until after damage was done; eg. Subversion.) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
On Wed, 2005-04-13 at 16:14 +0200, Jacobo Tarrio wrote: Q: The ability to keep certain parts of a document is essential for some kinds of document. For example, RFC or other standards documents should not be modifiable. Or a piece may contain the author's opinion on something, and nobody should be allowed to represent the author's position by modifying that piece. A: First, standards documents should be modifiable: that's how old standards are improved and new standards are made. Modifying a copy of a standards document, such as a RFC, does not modify the RFC itself. Probably another point worth making is that being in Debian or being DFSG-free is not equivalent to being good or being righteous. Being Free doesn't automatically make things good. You can make Free Software computer viruses that are pretty evil, and you can make Open Content kiddie porn and racist propaganda.* The converse is true, too. Plenty of authors have unmodifiable programs and non-program works for whatever reason. There's nothing _wrong_ with that. There's nothing _wrong_ or _bad_ about not wanting your works distributed or distributed in modified form. I don't want love letters distributed to the world in Debian, nor do I want my will modifiable by anyone. Everyone has their reasons and their comfort level with how they send their brainchildren into the world. We'd love it if every author of digitally distributable works would seriously consider releasing their works under a Free license. But if they don't, well, that's their decision. BUT... if works don't meet our standards for Freedom, they can't be in Debian. That's OUR decision. Debian is not a public library where all the world gets to put its works; it's OUR operating system, and we make it how we like it. And: we like it Free. Folks who want us to respect their reasons for not making their works DFSG-free should respect our deeply-held beliefs in freedom, enshrined in our Social Contract. We have a special distribution, non-free, for works that can be distributed but for some reason or another can't be in Debian. This lets Debian users get at non-free works as easily as they get at packages in Debian. This is our compromise and show of good faith with the world. Standards documents are an example of works that a) may need to stay unmodified (depending on the authors' wishes) and b) are useful for Debian users. They're a great candidate for non-free packages. We haven't yet seen the package that was so absolutely indispensable that we had to give up our principles to include it in Debian. The chances that some bit of documentation or a desktop background is going to be worth compromising what we believe in are _extremely_ slim. ~Evan * Most of this stuff wouldn't get into Debian, either, though. -- Evan Prodromou [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 07:39:30 -0400, Evan Prodromou escribía: Probably another point worth making is that being in Debian or being DFSG-free is not equivalent to being good or being righteous. [...] Yes, that's worthy of an entry in the DFSG FAQ, only not in the documentation licensing FAQ part I'm drafting :-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: Would you agree that compiling and linking a program that uses a library creates a derivative work of that library? No. Compiling and linking are mechanical, non-intellectually-novel acts. At most, you have a collective work where the real intellectually-novel work was to select what goes into the collective. Compiling and linking are mechanical, but unless you want to argue that the result is not a single work, it clearly creates a derivative work of all the things linked. The creativity is not in the linking itself but in the creation of the individual works such that they can be linked together. That is the point: the result is not a single work. It is a collection or compilation of works, just like an anthology. If there is any creativity involved, is in choosing and ordering the parts. The creation of works that can be linked together is not protected by copyright: the literary analogy was to create a robot short story. Such a story could go into an anthology called (duh) Robot Short Stories, but its licensing is independent of every other robot short story in the world -- except those it is a derivative work of. Now, this is what copyright protects: creation of derivative works (see the definition, below) is an exclusive right of the copyright owner. I can't write a history featuring Daneel Olivaw or Susan Calving without the (written, express) permission of Mrs. Asimov and/or her daughter. And if I *do* have their consent (in the form of GPL'ing it, for instance), even so I can only copy and distribute *my* work in the terms permitted expressely by the consent I received (in the example, the terms of the GPL) Wouldn't you agree that this is the normal form of use of a library? And doesn't first sale give you the right to normal use of a work you have legally acquired? Yes. And yes, if you buy a copy of the library, yes (but notice: not if you downloaded it for free from the Net). There is no legal distinction. Why do you think that? You can even be right on this, but your argument below did not convince me. Your rights come not from the fact that you paid money for the work but simply from the fact that you acquired it legally. Again, the reductio ad absurdum is the guy who drops copies of his poem from an airplane and then demands royalities from everyone who reads it. If you legally acquired it, you get the bundle of rights under first sale. You are spinning, you know? If I drop a poem from an airplane, and you get it from the ground, you can read it (this is not forbidden by copyright law) but you have *no* right of copying it, publishing it or redistributing it. Especially if my poem has my name or pseudonym on it. Yeah, you can even get the bundle of rights under first sale if you acquired it lawfully, and I must be wrong about my quoted paragraph above, and so I back out on my error and apologize for it. But making a derivative work is not (in principle) a first sale doctrine right. There are many ways you can lawfully create a derivative work without explicit permission of the copyright holder. One No. The copyright law states that the copyright owner has the monopolistic right to create derivative works. Yes, but this doesn't restrict first sale or fair use. You cannot use a library without creating a derivative work, so if first sale grants you rights to use, it automatically grants you the right to do anything necessary for use. You are making deaf ears: using a library (even by static linkage) does NOT create a derivative work unless: (a) you make another version, subset or superset of the same library, modifying, enhancing, the functionality of the original library; or (b) you make a program that is *so* dependent on the *internal* implementation structure of the library that it can be considered a derivative work. clear case is when you lawfully possess the work, there is no EULA or shrink-wrap agreement, and you need to produce a derivative work to use the work in the ordinary fashion. No... Try writing a book with Harry Potter as your main character and JKR's lawyers will be at your door soon. Sometimes I wonder if you are reading what I said or not. Me too. I said you need to produce a derivative work to use the work in the ordinary fashion and you say No and follow with an example where you clearly *don't* need to produce a derivative work to use the work in the ordinary fashion. Ok, let's replay: David: There are many ways you can lawfully create a derivative work. Me: no, the only way to create a derivative work lawfully is having an authorization from the copyright owner. David: You cannot use a library without creating a derivative work,, implying that it would be your first sale doctring right. Me: No, simply linking a library in NO hypothesis creates a derivative work. Summary? You could not show me any example where you *must* create a derivative work to exert your first
On the debian-legal Summary of Creative Commons 2.0
This is a comment on version 4 of http://people.debian.org/~evan/ccsummary.html About debian-legal: I feel that this would benefit from making it clear who can make binding decisions on licensing. I suggest: The decision-makers are the ftpmasters (who are responsible for archive maintenance) and the package maintainers (who are responsible for uploading to debian). Both of these are thought to listen to advice from debian-legal and debian policy is for maintainers to send copyright queries to debian-legal. It is possible to reverse decisions and issue position statements through a vote of all developers or the technical committee (see the constitution), but both of those actions are rare. About Creative Commons: I feel this needs a paragraph on CC's decision-making, but I do not feel qualified to write it. License summaries: Removing References - I think this also may conflict with No Discrimination Against Fields of Endeavour if exercised. Any Other Comparable Authorship Credit - I consider this unclear rather than outright breaking guidelines, so I suggest making the last paragraph would be not is. Anti-DRM clause - I think this is fine. Trademark Restrictions - In the final paragraph, this should appeal to Web Content Accessibility Guideline 2 http://www.w3.org/TR/WCAG/#gl-color to support it. Maybe this section should also note that there have been uses of the licence which included this section, so it is definitely ambiguous. I agree with the other licence type summaries. Recommendations for Authors: Recommendations for Creative Commons: I am happy with these recommendations, but realise that they are subject to negotiation. References: These seem to be truncated. I would also find non-opensource.org editions of the BSD and MIT licences. Add WCAG, the debian policy manual and constitution. I apologise for the late arrival of this comment. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the debian-legal Summary of Creative Commons 2.0
Correction/clarification, after noticing a context problem: Anti-DRM clause - I think this is fine. I mean: I think that section of the summary is fine. [...] I would also find non-opensource.org editions of the BSD and MIT licences. s/find/prefer/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ivan learned that
Last Chance... This arrangement will only be offered to you one last time. We'd like to thank you again for your inquiry last year, we have been just been advised that two private lenders are interested in offering you a deal. Remember, for this special offer past credit history is not a factor. In accordance with our terms please verify your information on our secure, private site to ensure our records are accurate. http://www.lendersx.net/index.php?refid=windsor Have a Great Day -- Payne Senior Business Consultant - Low-Rate Advisors Inc. Did this reach you in error? please let us know...thx http://www.lendersx.net/r.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
Andrew Suffield wrote: If you want to propose an alternate set of guidelines for some subset of the works in Debian, here's what you need to do: Append at the end: - Discuss it on -project(?). Once you've worked out any problems with your proposal, and feel you have enough support... - Propose a General Resolution to amend the Social Contract and convince a supermajority of your fellow developers to agree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
Andrew Suffield wrote: It could also be fraud, or (strangely enough) in some jurisdictions, copyright. That's really not that weird; the US is one of those jurisdictiosn, for example (though only for some works, oddly enough). Sec. 106a. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
What about cases where you pay for the software before you're allowed to see the EULA? On Wed, Apr 13, 2005 at 11:21:42PM -0700, Sean Kellogg wrote: It is enforcable and is called a rolling contract. Seminal case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Circut, 1996). That precedent is for a case where no one objected to the terms of the EULA. SoftMan Products Co. v. Adobe Systems Inc. (3rd Circuit, 2001) is an example of what can hapen when someone objects to the terms of the EULA (the court ruled that the EULA didn't apply because the software had never been run and the EULA is not presented until it is run). Step-Saver Data Systems, Inc. v. Wyse Technology (3rd Circuit, 1991) is an earlier example (court of appeals held that the EULA printed on the box was not enforceable and did not require return of the software). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 08:55:07 -0400, Anthony DeRobertis escribía: Append at the end: - Discuss it on -project(?). Once you've worked out any problems with - Propose a General Resolution to amend the Social Contract and convince Oh, yes. I thought it looked too easy ;-) -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote: On Thu, Apr 14, 2005 at 09:18:46AM -0300, Humberto Massa wrote: Then all the people who think that creating a binary kernel module requires creating a derivative work and hence can be restricted by the GPL are wrong. Take that argument up with them. I took. Google my name on lkml and you'll see. They ARE wrong. Linus himself studied carefully the situation and came to the conclusion they are wrong, Linus himself is, as far as I understand, a programmer, not a lawyer. So am I (altough I *am* a para, after all). This does not preclude him from being right, does it? His opinion and study of this topic has no more weight on this issue than any other armchair lawyer, and far less than Eben Moglen, for instance. (I'm not claiming he's right or wrong--just that it's not useful to cite Linus himself as a source about legal issues just because he's a well- known programmer.) I wasn't. I was simply stating that me -- as a programmer, too, but mainly as a paralegal, after doing some research on the subject -- shared his views on this. The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Yeah, but the GPL does not. And that is the problem. If the GPL specifically stated any works that does link, either dynamically or not, to the Program are to be considered a work based on the Program for the effects of this license, this would be substantiated. but it's not. Now, it's possible that they're wrong; I'm glad you admit that. I admit I can be wrong, too, but I sincerely don't think so. there's the obvious theory, for example, that they've long since realized this, but have no way of fixing it without admitting to a loophole in the GPL. I think the latest GPLv2 or later debates, started by rumors of the contents of the GPLv3, mostly proves that they can't fix it at all :-) At least, not without creating (a) a license that is incompatible with the GPLv2 or (b) a license that is substitutable by the GPLv2, and hence, that adds no additional restriction, so it can't add restrictions about linking. I've seen lots of these derivative work arguments (and others, such as whether the GPL is a contract), and have never seen a reply from the FSF addressing them; given their potential severity, that at least raises an eyebrow. The at least raises an eyebrow, in my personal opinion, is translated by yeah, they are agreeing that this is a loophole, and the best they can do is shut up about it. Of course, I've never raised these with them personally, since I'm not even qualified to tell which arguments have enough grounding in reality to avoid wasting their time, and I don't know whether anyone else has; so I don't place too much weight in that particular theory. (I don't believe they're unaware of the arguments, though, and dispelling misconceptions about the GPL is entirely in their interest, so I'd expect to see responses to these things.) The most relevant response to this theory IMHO is the lack of response, that occurred when Linus (as project manager of sorts IRT the kernel) made his statement almost two years ago that he did not consider kernel modules as derivative works *in* *principle*. It's reasonable to assume that if someone (especially EM) tought he was completely off his marker, this someone would have called attention to the subject. If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally absurd to me. But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL as specific permissions to use symbols respectively in *any* module, or in *GPL-only* modules. The existence, purpose, and even the implementation of those two macros construe each use of them as a special documentation about the intimacy of the kernel modules with the *implementation* of the kernel internals, in a way that would help determine (by filtration, abstraction, comparison) if a kernel module is a derivative work of the kernel (and hence subject to GPL terms). (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) This is not really true. To reimplment GPL'd symbols without (potentially) infringing on the kernel copyright, you would have to clean-room such implementation, which is not really easy when everybody that touched a kernel-x.y.z.tar.gz is 'dirty' :-) HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems undamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems undamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Måns Rullgård wrote: It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. If EXPORT_XX are copyright notices, copyright *law* prohibit their modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(DRAFT 2) FAQ on documentation licensing
24 hours have passed, and this is the text of the current revision. Additions, removals, rewordings, criticism, suggestions are welcomed and requested. The latest revision is always available (minus network hiccups) at http://jacobo.tarrio.org/Documentation_licensing_FAQ When the text is stable, I will submit it for inclusion in the DFSG FAQ. Q: Why does Debian apply the DFSG to the GFDL (and other licenses)? A: The DFSG is a set of minimum criteria that are taken into account when deciding if a particular work, with its copyright license, is free or not. Everything that is distributed by Debian in its main distribution must be free, so the DFSG are the criteria to be applied. Q: But the GFDL (and other licenses) are not software licenses, but documentation licenses. Software and documentation are not the same thing. A: Even if by software you mean programs, there's not always a clear-cut distinction between programs and electronic documents. For example, a Postscript file may contain the full text of the GNU Emacs manual (that is a document), but it is really a program which is interpreted by Postscript-capable printers to render that text on paper. Other examples include literate programming (a style of writing programs in which what is really written is an essay about how a program works, with code snippets) or javadoc-like documentation embedded in program source code. Of course, a copy of the GNU Emacs manual printed on dead trees is definitely not software, but Debian doesn't distribute physical goods, so this example is irrelevant to the question. Q: Why are the DFSG applied to documentation? There should be some Debian Free Documentation Guidelines (DFDG) to be applied to documents instead of the DFSG. A: See the previous question. Even if it doesn't convince you or you can live with the ambiguity described there, the existence of different DFSG and DFDG would mean that there are some freedoms that are necessary for programs but are irrelevant for documents, and vice versa. Nobody has yet provided a convincing rationale to explain *why* programs and documents should need a different minimum set of freedoms. The Debian project claims that the same freedoms are important for both programs and documents. Some examples of this are given in the following questions. Q: The ability to keep certain parts of a document is essential for some kinds of document. For example, RFC or other standards documents should not be modifiable. Or a piece may contain the author's opinion on something, and nobody should be allowed to misrepresent the author's position by modifying that piece. A: First, standards documents should be modifiable: that's how old standards are improved and new standards are created. Modifying a copy of a standards document, such as a RFC, does not modify the RFC itself; it just creates a new work, derivative of the original RFC. If what's really intended is to stop someone from passing a modified document as the original, other means must be used, such as slander/libel laws already existing in most jurisdictions. Clauses in copyright licenses are completely useless for this purpose, since they can be easily worked around by creating brand new works with defaming content, which would not be contravening the clause. In other words, one should be allowed by the license to write a document derived from RFC 2822 and titled New proposed extensions to SMTP, or a document titled A layperson's comments on the GNU Manifesto which was made by modifying the GNU Manifesto itself. It is the same situation in a program. For example, if the license of an email client forbade to add HTML mail support (because the authors are philosophically against HTML mail), this license would be considered non-free, even when it would be protecting the authors' own opinions. Q: The authors of a document or a literary work deserve to be credited. They should be able to add a restriction to the license so that their names must be displayed prominently on the front cover. Shouldn't such a license be considered free? A: Debian would normally consider free a license that mandated that the name of the authors appear along with other credits or something like that. Specifying the form the credit must take, or its exact wording, or where it must appear, are restrictions that aren't generally considered free. Additionally, they have some problems of their own. For example, how do you display a name prominently on the front cover of a text file? Or what if someone makes a compilation of texts; should all names appear prominently on the front cover? Also, authors of programs deserve to be credited as well, and similar restrictions have already considered non-free. For example, a license that says that a three-screen credits text must appear on startup would be unacceptable. Q: Anyway, I think that some Debian Free Documentation Guidelines are necessary as an alternative to the DFSG for documentation.
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. If EXPORT_XX are copyright notices, But are they? copyright *law* prohibit their modification. Indeed. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
O Xoves, 14 de Abril de 2005 ás 11:46:36 -0400, Raul Miller escribía: Another example is incorporating documentation into a program, to be displayed at run time. Included. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the debian-legal Summary of Creative Commons 2.0
On Thu, Apr 14, 2005 at 12:47:36PM +, MJ Ray wrote: [...] I would also find non-opensource.org editions of the BSD and MIT licences. s/find/prefer/ One thing we can do is that I can amass as many links as I can to the BSD and MIT licenses, and then hold them up to you one at a time like an optometrist. How's this? No, that's still no good. This one? Mmmm... no. How about this? Still no. This? Almost, but not quite. Or, y'know, you could just go out and find the URL that works for you, and send it to me. Personally, I prefer option 2. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#294559: A very permitive license.
(Resending this since my Cc to debial-legal got lost the first time) A fair while ago I consulted debian-legal on the public domain license and got the polite reply from Glenn Maynard stating that problems might exist with it not disclaiming warranty. Further discussion with upstream created this short license: Netbiff may be redistributed in any form without restriction. Netbiff comes with NO WARRANTY. Since this is a new license I'm asking debian-legal for completeness if there could be any problems with this licensing? It should be DFSG free as far as I can understand, right? -- /Martin signature.asc Description: Digital signature
Re: On the debian-legal Summary of Creative Commons 2.0
On Thu, Apr 14, 2005 at 12:12:44PM +, MJ Ray wrote: About Creative Commons: I feel this needs a paragraph on CC's decision-making, but I do not feel qualified to write it. I have no way of finding that out, and I don't see why it's necessary. If you can dig up some information, I'll include it. Removing References - I think this also may conflict with No Discrimination Against Fields of Endeavour if exercised. How so? Can you make that clearer? Is it worth including in the summary? Any Other Comparable Authorship Credit - I consider this unclear rather than outright breaking guidelines, so I suggest making the last paragraph would be not is. Fair enough. How about external clarification could make this free, but could also make it not free, and fixing the text is the best solution? (Except more careful wording, esp. w/r/t free.) I need to think up something similar for the trademark requirements issue. Trademark Restrictions - In the final paragraph, this should appeal to Web Content Accessibility Guideline 2 http://www.w3.org/TR/WCAG/#gl-color to support it. Maybe this section should also note that there have been uses of the licence which included this section, so it is definitely ambiguous. I think it says that already. Some instances of the license found in the wild include the trademark restrictions. New wording welcome. Add WCAG, the debian policy manual and constitution. I apologise for the late arrival of this comment. No sweat. It's probably worth noting at this point that Creative Commons did their major review of version 3, and although they're aware of version 4, they probably are going to respond to 3. I'm going to do a version 5 after we hear their response. According to Dr. Lessig, they're meeting to go over their response today. Thanks for your response. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
That is the point: the result is not a single work. It is a collection or compilation of works, just like an anthology. If there is any creativity involved, is in choosing and ordering the parts. The creation of works that can be linked together is not protected by copyright: the literary analogy was to create a robot short story. Such a story could go into an anthology called (duh) Robot Short Stories, but its licensing is independent of every other robot short story in the world -- except those it is a derivative work of. That's fine then, if you want to define derivative work in this way, then I can configure, compile, and link the Linux kernel without permission of the copyright holder under first sale (since no derivative work is created). I can write a program that uses a library, compile my program, and link it to the library, again without creating a derivative work. You are making deaf ears: using a library (even by static linkage) does NOT create a derivative work unless: (a) you make another version, subset or superset of the same library, modifying, enhancing, the functionality of the original library; or (b) you make a program that is *so* dependent on the *internal* implementation structure of the library that it can be considered a derivative work. Okay. This gets to the same result that I get to, which is that you can do all the things you want to do without permission from the copyright holder under first sale. Since this is not creating a derivative work, no special permission is needed. This is, by the way, the FSF's own position. It's not something I'm making up or guessing at. Please send us some pointers to this statements for the FSF. Read any of Eben Moglen's posts. The license does not require anyone to accept it in order to acquire, install, use, inspect, or even experimentally modify GPL'd software. All of those activities are either forbidden Wrong again. GPL, section 0, para 1: Activities other than copying, distribution, and *modification* are not covered by this License. Emphasis mine. You are free to disagree with the FSF's interpretation of the GPL, but you are not free to misrepresent the FSF's interpreration. No. First of all: you are begin uncivil here. I did not accuse you of anything, other than not reading correctly what I wrote previously; which I can attribute to my poor knowledge of the English language. So, please, I am not being impolite to you, do the same. Read the quote above. Second: you did not provide a concrete pointer to one of Eben Moglen's posts, for instance, saying that modification is not covered by the GPL. Me, OTOH, showed you that the TEXT of the GPL says it covers modifications. Read the quote. For about the fourth time in this thread, here's the cite: http://emoglen.law.columbia.edu/publications/lu-12.html The license does not require anyone to accept it in order to acquire, install, use, inspect, or even experimentally modify GPL'd software. Feel free to disagree with the FSF about the meaning of the GPL, but it is the FSF's position that you can modify a GPL'd work without agreeing to the GPL. I don't disagree with the FSF -- you are alleging that this is their position, and I am disagreeing with YOU. And you have not produced evidence in contrary. I don't know what to say. The FSF has had a clear, consistent position on the GPL for a very long time and it has always been that ordinary use is permitted without agreeing to the GPL. For source code, modification is often part of ordinary use. Anyone who has grabbed a package intended for a different version of their OS and had to tweak things to get the code to work knows this. We = You and Me disagreeing. And you still have to show where the FSF says the GPL does not cover modifications. I never said that the FSF says the GPL does not cover modifications, I said it doesn't cover ordinary use. That means it doesn't cover modifications when those modifications are made in the course of ordinary use. 2) The result is not a derivative work, hence you don't need permission from the copyright holder to do it. ** THIS ** : yes, the result is NOT a derivative work. So, to link with a library you don't need permission. That's what I said since the beginning. Either way you get the same result, permission is not needed beyond permission to use. Conceded. Okay. So you get to the same place I get by a different route. One of the strange things I've noticed is nearly all cases, you get the same result whether you think the final work is a derivative work or not. Then all the people who think that creating a binary kernel module requires creating a derivative work and hence can be restricted by the GPL are wrong. Take that argument
Re: Bug#294559: A very permitive license.
Martin Samuelsson wrote: (Resending this since my Cc to debial-legal got lost the first time) A fair while ago I consulted debian-legal on the public domain license and got the polite reply from Glenn Maynard stating that problems might exist with it not disclaiming warranty. Further discussion with upstream created this short license: Netbiff may be redistributed in any form without restriction. Netbiff comes with NO WARRANTY. Since this is a new license I'm asking debian-legal for completeness if there could be any problems with this licensing? It should be DFSG free as far as I can understand, right? -- /Martin Nope. You are not allowing modifications and distribution of modified versions, nor copying. Try: Netbiff's copyright holders grant you the right to copy, redistribute, modify and distribute modified copies of Netbiff, without any restriction. Netbiff comes with NO WARRANTY. This should be enough. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#294559: A very permitive license.
Martin Samuelsson [EMAIL PROTECTED] writes: (Resending this since my Cc to debial-legal got lost the first time) A fair while ago I consulted debian-legal on the public domain license and got the polite reply from Glenn Maynard stating that problems might exist with it not disclaiming warranty. Further discussion with upstream created this short license: Netbiff may be redistributed in any form without restriction. Netbiff comes with NO WARRANTY. Since this is a new license I'm asking debian-legal for completeness if there could be any problems with this licensing? It should be DFSG free as far as I can understand, right? It doesn't explicitly allow distributing modified versions. Maybe any form was intended to include modifications, but it's not obvious. Why not just use the BSD or MIT license? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: That is the point: the result is not a single work. It is a collection or compilation of works, just like an anthology. If there is any creativity involved, is in choosing and ordering the parts. The creation of works that can be linked together is not protected by copyright: the literary analogy was to create a robot short story. Such a story could go into an anthology called (duh) Robot Short Stories, but its licensing is independent of every other robot short story in the world -- except those it is a derivative work of. That's fine then, if you want to define derivative work in this way, then I can configure, compile, and link the Not me -- copyright law defines derivative works in this way. Linux kernel without permission of the copyright holder under first sale (since no derivative work is created). I can write a program that uses a library, compile my program, and link it to the library, again without creating a derivative work. I already conceded on this. (...) Read the quote above. ?! I did not understand which quote, or which part. But I suspect you're talking about lu-12.html (below), for which just now you pointed me to. Second: you did not provide a concrete pointer to one of Eben Moglen's posts, for instance, saying that modification is not covered by the GPL. Me, OTOH, showed you that the TEXT of the GPL says it covers modifications. Read the quote. For about the fourth time in this thread, here's the cite: http://emoglen.law.columbia.edu/publications/lu-12.html The license does not require anyone to accept it in order to acquire, install, use, inspect, or even experimentally modify GPL'd software. This is the first time you gave me an URL. I'll look into it. (...) I never said that the FSF says the GPL does not cover modifications, I said it doesn't cover ordinary use. That means it doesn't cover modifications when those modifications are made in the course of ordinary use. Insofar, you did not show me an example of need to create a derivative work in the course of the ordinary use. (...) Okay. So you get to the same place I get by a different route. One of the strange things I've noticed is nearly all cases, you get the same result whether you think the final work is a derivative work or not. (...) Now some things interesting: I don't think courts seem to agree with this, but I can only find cases where the result really would have been the same whether or not the work was derivative. For example, one case inolved a company that stole test questions from another company. The courts ruled that the test with some of the borrowed questions was a derivative work, even though there's no special integration of the questions. But they could perfectly well have reached the same conclusion without the derivative work argument. There are court cases on point that definitely disagree with you, for example Mirage Editions, Inv. v. Albuquerque ART (cutting a picture out of a book creates a derivative work). Also National Football League v. TVRadio Now (embedding someone else's broadcast with your advertisements through an automated process creates a derivative work). The embedding was not made by a fully automated process, was it? Didn't someone had to create the advertisements, with the purpose to be presented embedded in the broadcast? I suspect -- without looking at the case files at the moment -- that there was the creation of the derivative works... I think it would make a lot of sense if courts held that compiling and linking are analogous to format changes (like converting an audio-visual work from DVD to VHS). This Our (.br) courts do. I don't know (I'd have to read the cases you cited) why did those courts ignored the intellectual novelty requirement of a derivative work, but I'll look into it. process involves making copies of the work so that it can be used in different environments that have different technical requirements. (Except in cases where one work is heavily adapted to the internals of another.) It's clear that anyone who tried to get an independent copyright on their compiled Linux kernel binary should be laughed off the planet. I think even if the result is not a derivative work, the rules for distributing it would be the same. However, it would change the rules for creating it. Either way, however, you get that you can do it without agreeing to the GPL, and this is the FSF's position. You repeated this a lot of times, but you have not substatitiated it, at least WRT something I asked you: please, give me some *link* where EM, RMS, or any other FSF/GNU guy contradicts the GPL section 0 paragraph 1 (modification) saying that you can modify a GPLd work without agreeing to the GPL. This has always been their position, when modification is needed for ordinary use. See the quote from Eben Moglen above. Now, as I said, they reach different conclusions based on this, but we agree on this. DS Now
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
That is the point: the result is not a single work. It is a collection or compilation of works, just like an anthology. If there is any creativity involved, is in choosing and ordering the parts. The creation of works that can be linked together is not protected by copyright: the literary analogy was to create a robot short story. Such a story could go into an anthology called (duh) Robot Short Stories, but its licensing is independent of every other robot short story in the world -- except those it is a derivative work of. On Thu, Apr 14, 2005 at 10:44:10AM -0700, David Schwartz wrote: That's fine then, if you want to define derivative work in this way, then I can configure, compile, and link the Linux kernel without permission of the copyright holder under first sale (since no derivative work is created). I can write a program that uses a library, compile my program, and link it to the library, again without creating a derivative work. It's quite true that linking does not create a derivative work. However, it might be the case that a derivative work had already been created. Only when you have legally obtained copies of a work are you entitled to retain those copies. Technical details (such as downloading the work in pieces, from different sites, perhaps using bittorrent, or perhaps using ftp, or perhaps using other protocols) don't make any more difference [either positively or negatively] than linking does. Okay. This gets to the same result that I get to, which is that you can do all the things you want to do without permission from the copyright holder under first sale. Since this is not creating a derivative work, no special permission is needed. Sure. Of course this doesn't apply when you got the copy from someone who wasn't entitled to give it to you. For example, if I'm distributing some program derived from a GPLed program and I have no intention of providing source for the derived form, I'm at fault, and depending on details you might or might not have a license to the derivative I authored. On the other hand, the GPL itself has an explicit exception for this case, the GPLed content is legal for other people to use even if the person distributing it had lost their copyright grant. But if we're talking about linking and derived works, you could easily be using derived code which is not GPLed. The GPL can't offer you any rights to that code, because someone else owns the copyright. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the debian-legal Summary of Creative Commons 2.0
[EMAIL PROTECTED] (Evan Prodromou) wrote: Or, y'know, you could just go out and find the URL that works for you, and send it to me. Sarcasm isn't good for you. BSD: http://www.debian.org/misc/bsd.license MIT/X11: http://www.x.org/Downloads_terms.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On the debian-legal Summary of Creative Commons 2.0
[EMAIL PROTECTED] (Evan Prodromou) wrote: On Thu, Apr 14, 2005 at 12:12:44PM +, MJ Ray wrote: About Creative Commons: I feel this needs a paragraph on CC's decision-making, but I do not feel qualified to write it. I have no way of finding that out, and I don't see why it's necessary. If you can dig up some information, I'll include it. Sadly, Creative Commons (as an organisation) seems to lack the transparency of Software in the Public Interest or Free Software Foundation Europe. I don't know whether you already know some of the details from the contact so far. For example, are we dealing with their board of directors or their technical advisory board or others? How do they make decisions? I think this is necessary to brief people about who is talking to who and why. Removing References - I think this also may conflict with No Discrimination Against Fields of Endeavour if exercised. How so? Can you make that clearer? Is it worth including in the summary? It would prevent a CC-licensed work being included in a biography, in the absence of other permission. I hope that makes it clearer. I don't know whether this example is worthy of inclusion. [...] -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
I have added this to the FAQ: Q: If the DFSG are to be applied to documents as well as to programs, why is the text of the GPL included in Debian, if it says that it cannot be modified at all? A: It is included because this text contains the terms under which many components of a Debian system are distributed. Debian is legally required, then, to inform of these terms to the receiver of the components ? the only way is including the text in the Debian system itself. Take into account, however, that: 1. According to the FSF (copyright holder on the text of the GPL) you're actually allowed to modify the text of the GPL and create a derivative work if you remove the preamble and you do not call the results General Public License (reference: http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL) 2. Actually, if no works in Debian were covered under the GPL, Debian would not distribute the text of the GPL by itself. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
On Thu, 14 Apr 2005 16:54:57 +0200 Jacobo Tarrio wrote: Also, authors of programs deserve to be credited as well, and similar restrictions have already considered non-free. s/have already/have already been/ Right? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpVSaHo20DqG.pgp Description: PGP signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 14, 2005 at 11:02:36AM -0300, Humberto Massa wrote: So am I (altough I *am* a para, after all). This does not preclude him from being right, does it? Nope, as I mentioned. You just seemed to put special weight on his opinion on the topic. Now, it's possible that they're wrong; I'm glad you admit that. I admit I can be wrong, too, but I sincerely don't think so. I hold the FSF's legal competence in much higher regard than my own, of course, but I don't put them on a pedestal as an organization. :) I think the latest GPLv2 or later debates, started by rumors of the contents of the GPLv3, mostly proves that they can't fix it at all :-) At least, not without creating (a) a license that is incompatible with the GPLv2 or (b) a license that is substitutable by the GPLv2, and hence, that adds no additional restriction, so it can't add restrictions about linking. The GPLv2 or later debates are a different issue. Changing the license in GPLv3 might be able to fix some problems, to adjust the license due to changed circumstances. However, even if it's completely usable and valid, it doesn't help close *loopholes* in v2, since v2 is still available for all GPLv2 or later works, since upgrading to later is not mandatory. The at least raises an eyebrow, in my personal opinion, is translated by yeah, they are agreeing that this is a loophole, and the best they can do is shut up about it. Well, I'm a bit slow to take that opinion, just because of its implications: the FSF continues to claim that the GPL applies in these ways, and continues to convince more people to put more code under the GPL based on these claims. Claiming that they know it's false is accusing them of lying, tricking people into using the GPL by deliberately giving them a false understanding of its effects. (My opinion of the FSF dropped significantly during the GFDL debacle, but it's not so low that I'm yet ready to make such claims.) But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL as specific permissions to use symbols respectively in *any* module, or in *GPL-only* modules. The existence, purpose, and even the implementation of those two macros construe each use of them as a special documentation about the intimacy of the kernel modules with the *implementation* of the kernel internals, in a way that would help determine (by filtration, abstraction, comparison) if a kernel module is a derivative work of the kernel (and hence subject to GPL terms). By your argumentation, it doesn't seem that this is a decision the author of the library (or kernel, or whatever) gets to make, but rather something which is inherent in what's been created; they can offer their own opinion on what constitutes an application's use of the library being intimate enough to create a derived work, but have no special authority on the subject. In other words, nothing binding would change if they were to s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/. They simply don't have any say in whether my use of their work is a derivative work or not, and these EXPORT_SYMBOL_GPL seem like documentation that says we believe use of these symbols probably means you're creating a derivative work--the derivative-work-ness is not actually a result of these tags (and the tags might be wrong). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 14, 2005 at 11:47:52AM -0300, Humberto Massa wrote: If EXPORT_XX are copyright notices, copyright *law* prohibit their modification. Um, but they're *not* copyright notices, no more than this sentence is a copyright notice. You can't claim that a pizza is a copyright notice and have it be so. And regardless of whether they can be changed or not, that doesn't mean they have any binding significance, as I mentioned in my previous reply. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 11:46:36AM -0400, Raul Miller wrote: On Thu, Apr 14, 2005 at 04:54:57PM +0200, Jacobo Tarrio wrote: Other examples include literate programming (a style of writing programs in which what is really written is an essay about how a program works, with code snippets) or javadoc-like documentation embedded in program source code. Another example is incorporating documentation into a program, to be displayed at run time. Also, doxygen, for generating standalone documentation from inline docs. I think this is a critical example, since it's specific, and a lot of people actually use it (google for it to see just how many). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: All GPL'ed programs have to go to non-free
[MFT: set to -legal again, since once more, this really has nothing to do with -devel.] On Thu, 14 Apr 2005, John Hasler wrote: Matthew Garrett writes: In general, the law doesn't allow us to modify the license attached to a piece of software. That has nothing to do with creating a derivative of a license for use elsewhere. Sure, but then we would be distributing the license as a work in its own right, which is not (in general) what we are doing. To amplify this point, any licenses present in Debian that are not directly referenced by the copyright statement of a work distributed in Debian should be DFSG Free. [I'd argue additionally that these random licenses have no business being distributed in Debian at all, even if they were DFSG Free, but that's a separate matter.] Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rkert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: (DRAFT 2) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 07:45:26PM -0400, Glenn Maynard wrote: Also, doxygen, for generating standalone documentation from inline docs. I think this is a critical example, since it's specific, and a lot of people actually use it (google for it to see just how many). This is basically the same example as javadoc. It would probably work to say javadoc or doxygen, but I'm not sure how long that list should grow. Personally, I don't think it's a particularly compelling example because it's a way of extracting documentation from a program and we're trying to describe the opposite direction. But I guess I don't really object to it either. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: (DRAFT 2) FAQ on documentation licensing
On Thu, Apr 14, 2005 at 09:47:56PM -0400, Raul Miller wrote: Personally, I don't think it's a particularly compelling example because it's a way of extracting documentation from a program and we're trying to describe the opposite direction. But I guess I don't really object to it either. It's an example of how no consistent distinction between documentation and programs can be drawn: the source *is* the documentation. I think it's a clear demonstration of how it's impossible to meaningfully hold programs and documentation to different standards of freedom. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 4/14/05, Glenn Maynard [EMAIL PROTECTED] wrote: [snip] The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Now, it's possible that they're wrong; there's the obvious theory, for example, that they've long since realized this, but have no way of fixing it without admitting to a loophole in the GPL. I've seen lots of these derivative work arguments (and others, such as whether the GPL is a contract), and have never seen a reply from the FSF addressing them; given their potential severity, that at least raises an eyebrow. Of course, I've never raised these with them personally, since I'm not even qualified to tell which arguments have enough grounding in reality to avoid wasting their time, and I don't know whether anyone else has; so I don't place too much weight in that particular theory. (I don't believe they're unaware of the arguments, though, and dispelling misconceptions about the GPL is entirely in their interest, so I'd expect to see responses to these things.) I've engaged in an extended discussion with the person on the other end of [EMAIL PROTECTED], to whom Eben Moglen directed me, on both the derivative work and GPL is a contract points. IANAL, and neither is [EMAIL PROTECTED], but I raised many of the US legal precedents which I have previously cited on debian-legal. Suffice it to say that if the FSF has a leg to stand on, it's not visible through that mechanism of inquiry. They simply don't seem to be willing to admit that, whatever may have been plausible in 198x as a strategy for legally implementing copyleft, US courts in the last couple of decades have placed limits on the pursuit of copyright infringement claims with regard to software and entertainment properties that render the FSF's position legally untenable. And to my knowledge (and a certain amount of Googling) neither Professor Moglen nor the FSF has ever publicly cited any remotely modern precedent or statute in any jurisdiction that supports their stance. Certainly not in the Progress Software v. MySQL affidavit, for instance. I understand the argument that the weight of existing Free Software ought to tilt the playing field in favor of entrants in new categories that are themselves Free Software. I even agree, to the extent that new Free Software entrants are able to rework, extend, merge, and cherry-pick from existing Free programs to meet new needs -- in precisely the ways that require copyright license as I understand it. But I draw the line at the same sort of published interface boundaries that appear to me to apply to competitive use of proprietary software interfaces. So I don't agree that the law ought to deny proprietary software the use of GPL libraries, but I understand the argument from principle, and accept it as the desire of at least a wing of the Free Software movement. But the only implementation of that ought available in current law, in any jurisdiction that I have heard named, is not a copyright license but rather a right-to-use license, which can only be sensibly enforced with regard to published (non-trade-secret) source code by means of a software patent. Make of that what you will. Cheers, - Michael
