Re: SRFI copyright license
On Wed, Dec 24, 2003 at 10:06:10PM +0100, Lionel Elie Mamane wrote: I wish to get your opinions on the case of the reference implementations in the SRFI's. I have done some more digging around the issue. Several scheme implementations in Debian main contain code lifted from SRFI implementations, and several of those reference implementations are covered by the standard SRFI copyright license (others are covered by a different, clearly DFSG-free license, like those by Olin Shivers, like SRFI 1). One particular example of such a scheme implementation is Guile, which contains SRFI 19. The case of guile is exemplary, because it is an official GNU project. I have contacted the maintainers about this (in the case of guile, he happens to be the listed author of the file in the guile sources) and asked them to contribute to this discussion. The fact that some reference implementations are covered by a different license than the SRFI copyright is a hint that to SRFI authors themselves, the SRFI copyright isn't free (enough), or not intended for code at all. On the other hand, it looks like standard practice in the scheme community to consider the SRFI copyright as 'do what you want' when applied to code. -- Lionel signature.asc Description: Digital signature
Re: SRFI copyright license
Don Armstrong wrote: On Mon, 29 Dec 2003, Jakob Bohm wrote: The main trick is to distinguish between the original full text SRFI (the document) and the free software (document that excerpts or derives from the document). Sure, but if you take that tack, the prohibition of modification of the document becomes, in effect, a no-op. You can take excerpts of the document, modify them, slap some more changes on them, and then call it SRFI foo. According to this theory, it's no longer the document. I think this line of reasoning mistakenly blurs the line between technical and social restraint. The license bans modification of the document, and is written in a generic way so as to be applicable to any single SRFI. So when applied to an SRFI, what is the document? The given SRFI. The license clearly allows you to derive works, as long as you do not change the SRFI itself. That leaves an unfortunately fuzzy, but still clearly small area which you shouldn't touch -- and which nobody has a reason to touch anyway: conflicts with the original document. There's no good reason to release a new SRFI 86 instead of an SRFI 286 which references and quotes SRFI 86. So what's ruled out by this license? Well, calling a derivative work of SRFI 86 SRFI 86, or otherwise making something that appears to be a modified SRFI 86 would probably count. I can't see anything else as forbidden. Is your real problem, Don, the vagueness of the identity problem for documents? When is one document the same as another? When is one a modification of another, and not a separate document? Not that all of this matters, given the strange grant of permission for derivation. I didn't notice that weirdness in my first replies, sorry. -Brian
Re: SRFI copyright license
On Tue, 30 Dec 2003, Brian T. Sniffen wrote: The license clearly allows you to derive works, as long as you do not change the SRFI itself. The above sentence is in conflict with itself. A deriviative work must necessarily change the SRFI itself. The end product might not be an SRFI anymore, but the starting point is. It's as much in conflict as the following: Here is a piece of code. You can modify it, but you must not change it. This is, in a nutshell, the entire problem with this license. It gives with one hand, and then takes with the other, leaving the exact amount taken open to interpretation in court. Well, calling a derivative work of SRFI 86 SRFI 86, or otherwise making something that appears to be a modified SRFI 86 would probably count. I can't see anything else as forbidden. I agree that is quite likely what they mean, but that's not what the license says, at least at a conservative reading. One would have hoped that the presence of a FAQ about this section would have alerted the license authors that this section of the license was extreemly unclear. Is your real problem, Don, the vagueness of the identity problem for documents? When is one document the same as another? When is one a modification of another, and not a separate document? That's part and parcel of the issue. If the license clarified when a derivation ceased to be the document itself and became a totally different document, this license might possibly become acceptable, but they fail to do that. [Frankly, I'd much rather see this section rewritten along the lines I proposed earlier in this thread than definition clarification.] Don Armstrong -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: SRFI copyright license
On Mon, 29 Dec 2003, Jakob Bohm wrote: The main trick is to distinguish between the original full text SRFI (the document) and the free software (document that excerpts or derives from the document). Sure, but if you take that tack, the prohibition of modification of the document becomes, in effect, a no-op. You can take excerpts of the document, modify them, slap some more changes on them, and then call it SRFI foo. According to this theory, it's no longer the document. Another way is to claim that the SRFI license explicitly permits placing the derived document (the original implementation that copied the SRFI mostly verbatim) under a different, directly DFSG free license such as BSD or GPL, and that once this is done, the SRFI license cannot block further modification under the new license. It's not acceptable to consider phrases of a license in isolation. When a phrase conflicts, we must assume the most conservative interpretation, baring legally binding clarification directly from the copyright holder. Owing to this problem, it is not possible to relicense a work under the SRFI under another license, if the other license is in conflict with the terms of the SRFI. Both the BSD and GPL licenses are in conflict with the terms of the SRFI. Don Armstrong -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: SRFI copyright license
On Wed, Dec 24, 2003 at 02:16:45PM -0800, Don Armstrong wrote: On Wed, 24 Dec 2003, Brian T. Sniffen wrote: I strongly disagree: the license is just saying that you can't publish a derivative work of SRFI X as SRFI X, and are otherwise free to derive works. Could you step through your logic of that, without relying on the FAQ? IANAL, TINLA, this is academic debate only. I am not Mr. Sniffen, but here is my idea of how this *could* be interpreted as a free license. The main trick is to distinguish between the original full text SRFI (the document) and the free software (document that excerpts or derives from the document). Step 1: Someone includes (all or part of) the SRFI in an actual scheme implementation (buggy or not). Because this Scheme implementation (as a whole) is a document that assists in the implementation of the SRFI it can excerpt from the SRFI without limitation. Because the permission to do so is explicit and does not rely on fair use claims, a 100% excerpt is OK. Step 2: Someone (possibly the same person) modifies the part of the scheme implementation that came from the SRFI to fix an implementation bug or adapt to the interfaces of the rest of the implementation. This still assists in the implementation of the SRFI and is still permitted. The changed parts are either derived from the SRFI (which is explicitly permitted) or no longer derived from it (in which case that part of the SRFI is no longer excerpted into that implementation assisting document). Step 3: Someone (possibly the same person) modifies the part of the scheme implementation that came from the SRFI to deliberately no longer implement what the SRFI specifies. This case is more tricky. One way around it may be to add comments like // SRFI x specifies the following behavior ... which is not //as good as the following behavior, which this program //uses even though it is not in accordance with SRFI x. And claim that this makes the text an explanation of the SRFI. Another way is to claim that the SRFI license explicitly permits placing the derived document (the original implementation that copied the SRFI mostly verbatim) under a different, directly DFSG free license such as BSD or GPL, and that once this is done, the SRFI license cannot block further modification under the new license. Jakob -- This message is hastily written, please ignore any unpleasant wordings, do not consider it a binding commitment, even if its phrasing may indicate so. Its contents may be deliberately or accidentally untrue. Trademarks and other things belong to their owners, if any.
Re: SRFI copyright license
On Wed, 24 Dec 2003, Lionel Elie Mamane wrote: Every SRFI contains a reference implementation, and bears this copyright notice: Copyright (C) /author/ (/year/). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns. This document and the information contained herein is provided on an AS IS basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Is a scheme implementation that includes the reference implementation DFSG-free (providing the rest of the implementation is, obviously)? No, unfortunatly, because irregardless of the FAQ, the license is contradictory, and seemlingly violates DFSG #3. [Unless there is a provision which I am missing to license the actual implementation of a reference implementation separately... Could you provide reference to the procedures for copyrights defined in the SRFI process?] Doesn't the SRFI copyright notice contradict itself? You're probably thinking of the sentence However, this document itself may not be modified in any way [...] except as needed for the purpose of developing SRFIs [...] which might seem to contradict the answers to the previous questions. However, this sentence is only to prevent passing off a modified copy of the document as the document itself. So SRFI x is an inviolable entity (and once finalized, very close to cast in amber). But you can excerpt from it at will, with attribution. (We have actually consulted with several lawyers on this; it is what we intended, and it is what it means.) May I suggest that this particular text of the license actually be changed to say exactly what is meant, instead of relying on a lawyer's interpretation of its meaning? EG: Modifications must indicate the nature of any change and the date of such change. Additionally, modifications as made must explicitely indicate that they are not a SRFI Reference Implementation in a location routinely used for such notices, or in the very document itself. While there is no doubt in my mind that you could make a case for the statement in the FAQ, its also quite possible (and probably more likely) to claim the opposite, and still have an interesting and expensive legal slugfest. Moreover, there's nothing in this document that gives you the right to modify outside of creating derivative works that comment on or otherwise explain it or assist in its implementation. [You could argue, I suppose, that any dirivative work explains the work its derived from, but if that's the tack to take, why not just say it?] In the case of scsh, which includes some of these reference implementations, upstream's opinion is that what the license means is the copyright needs to remain intact, not the code cannot change. I'm personally not convinced of that, but it's possible I can be swayed. Don Armstrong -- People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: SRFI copyright license
Don Armstrong [EMAIL PROTECTED] writes: On Wed, 24 Dec 2003, Lionel Elie Mamane wrote: Every SRFI contains a reference implementation, and bears this copyright notice: Copyright (C) /author/ (/year/). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Scheme Request For Implementation process or editors, except as needed for the purpose of developing SRFIs in which case the procedures for copyrights defined in the SRFI process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the authors or their successors or assigns. This document and the information contained herein is provided on an AS IS basis and THE AUTHOR AND THE SRFI EDITORS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Is a scheme implementation that includes the reference implementation DFSG-free (providing the rest of the implementation is, obviously)? No, unfortunatly, because irregardless of the FAQ, the license is contradictory, and seemlingly violates DFSG #3. [Unless there is a provision which I am missing to license the actual implementation of a reference implementation separately... Could you provide reference to the procedures for copyrights defined in the SRFI process?] I strongly disagree: the license is just saying that you can't publish a derivative work of SRFI X as SRFI X, and are otherwise free to derive works. Looks like an ideal license for standards documents, really, which does everything this community has been asking for. Moreover, there's nothing in this document that gives you the right to modify outside of creating derivative works that comment on or otherwise explain it or assist in its implementation. [You could argue, I suppose, that any dirivative work explains the work its derived from, but if that's the tack to take, why not just say it?] I would think assist in its implementation would cover most software, but... yeah, it would be nicer if it were made more broad. In the case of scsh, which includes some of these reference implementations, upstream's opinion is that what the license means is the copyright needs to remain intact, not the code cannot change. I'm personally not convinced of that, but it's possible I can be swayed. Don Armstrong
Re: SRFI copyright license
On Wed, 24 Dec 2003, Brian T. Sniffen wrote: I strongly disagree: the license is just saying that you can't publish a derivative work of SRFI X as SRFI X, and are otherwise free to derive works. Could you step through your logic of that, without relying on the FAQ? As near as I can parse it, I'm seeing: this document itself may not be modified in any way, except as needed for the purpose of developing SRFIs. Now, if you want to claim that this document itself means merely the copy in front of you, that's possible, but then this statement is a no-op. It may be a flaw in my reasoning, but I can't reconcile this statement with the explanation given in the FAQ. Looks like an ideal license for standards documents, really, which does everything this community has been asking for. Not too bad, assuming you clear up the ambiguities we've hit on already. I would think assist in its implementation would cover most software, but... yeah, it would be nicer if it were made more broad. Yeah. Restrictions on modifications that don't cause an appreciable increase in freedom are generally not a good thing. Don Armstrong -- ...Yet terrible as UNIX addiction is, there are worse fates. If UNIX is the heroin of operating systems, then VMS is barbiturate addiction, the Mac is MDMA, and MS-DOS is sniffing glue. (Windows is filling your sinuses with lucite and letting it set.) You owe the Oracle a twelve-step program. --The Usenet Oracle http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: SRFI copyright license
On Wed, Dec 24, 2003 at 01:40:33PM -0800, Don Armstrong wrote: On Wed, 24 Dec 2003, Lionel Elie Mamane wrote: Every SRFI contains a reference implementation, and bears this copyright notice: Is a scheme implementation that includes the reference implementation DFSG-free (providing the rest of the implementation is, obviously)? No, unfortunatly, because irregardless of the FAQ, the license is contradictory, and seemlingly violates DFSG #3. [Unless there is a provision which I am missing to license the actual implementation of a reference implementation separately... Not that I know of. Could you provide reference to the procedures for copyrights defined in the SRFI process?] The SRFI process is at: http://srfi.schemers.org/srfi-process.html Doesn't the SRFI copyright notice contradict itself? You're probably thinking of the sentence However, this document itself may not be modified in any way [...] except as needed for the purpose of developing SRFIs [...] which might seem to contradict the answers to the previous questions. However, this sentence is only to prevent passing off a modified copy of the document as the document itself. So SRFI x is an inviolable entity (and once finalized, very close to cast in amber). But you can excerpt from it at will, with attribution. (We have actually consulted with several lawyers on this; it is what we intended, and it is what it means.) May I suggest that this particular text of the license actually be changed to say exactly what is meant, instead of relying on a lawyer's interpretation of its meaning? This would be too simple... More seriously, I'm running it through debian-legal first to confirm that I'm not the only one thinking in this direction, and we'll see from there. I don't have very high hopes of getting the SRFI editors (and all past authors) to change the license, but well, we can try. -- Lionel
Re: SRFI copyright license
Lionel Elie Mamane wrote: I wish to get your opinions on the case of the reference implementations in the SRFI's. An SRFI, Scheme Request For Implementation, is the process by which the Scheme community agrees on standard libraries and features for various scheme implementations. Every SRFI contains a reference implementation, and bears this copyright notice: It's clearly non-free as a software license. You aren't allowed to distribute code changes, which could be actually a very desirable property of the license in the eyes of its authors, but still is non-free according to the DFSG. As a documentation license, it seems to be modeled after the ISOC copyright statement on RFCs. I don't think this qualifies as a free documentation license in the strictest sense (and IIRC, this was the majority opinion in previous discussions on debian-legal, but I could be mistaken).
