Clarification, please
The first paragraph of http://www.opensource.org/licenses/index.html states: For your convenience, we have collected here copies of the licenses approved by OSI. If you distribute your software under one of these licenses, you are permitted to say that your software is OSI Certified Open Source Software. However, if I choose to distribute my software under the Apache license, I clearly don't want to use the verbatim license. How much leeway do I have in modifying the wording of a license derived from one of the canonical forms while still claiming to distribute my software under the terms of that license? For reference, I am attaching a copy of the derived license in question. Sorry, I know the question is a bit challenged, but there are no real guidelines for this on 'opensource.org' that I can see. Thanks in advance for your assistance, Bryan -- Bryan George Email: [EMAIL PROTECTED] 5 Butternut Way Web: http://www.mindspring.com/~lyricos Sterling, VA 20164 Phone: (703) 707-8578 (H), (801) 740-5156 (F) Copyright (c) 2001 by Bryan George. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Lyricos Project (http://www.lyricos.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names Lyricos and Lyricos Project must not be used to endorse or promote products derived from this software without prior written permission of Bryan George. For written permission, please contact [EMAIL PROTECTED] 5. Products derived from this software may not be called Multiple Data Type Matrix Library or MDTM, nor may Multiple Data Type Matrix Library or MDTM appear in their name, without prior written permission of Bryan George. THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BRYAN GEORGE OR THE LYRICOS PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: To the keepers of the holy grail of Open Source
David Johnson wrote: On Monday 22 January 2001 09:35 am, Bryan George wrote: Okay, I'm writing it down: "Audience = inflexible Unix bigots = document = brain dead ASCII text". Got it, thanks! Sigh... I don't have MS Office, and I am not about to pay for it. This has nothing to do with bigotry, but everything to do with my money, my harddrive space, etc... And when it comes to a choice between rebooting the system to run your document's native OS, or shelling out yet more money to get VMWare, I'll just abstain. I'm just busting your chops a little, really... :) You don't have to convince me of the need for a low-cost, accessible, open way to pass docs around - I just got a little tweaked with the "Real men use ASCII" crud. %b There are alternatives so use them. If the presentation you are sending is comprised solely of verbal content, then ASCII is sufficient. If you need some small amount of text formatting, try HTML. And if you need to control the document's appearance exactly, try PDF. I was going to suggest that - presumably anyone with pockets for Office can pick up a copy of Acrobat as well, and the reader's free and multi-platform. Cheers, Bryan -- David Johnson ___ http://www.usermode.org begin:vcard n:George;Bryan tel;fax:703-883-6708 tel;work:703-883-5458 x-mozilla-html:FALSE url:http://www.mitre.org org:The MITRE Corporation;Signal Processing Center adr:;;1820 Dolley Madison Blvd., M/S W622;McLean;VA;22102-3481;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Lead Signal Processing Engineer fn:Dr. Bryan George end:vcard S/MIME Cryptographic Signature
Re: To the keepers of the holy grail of Open Source
Ben Tilly wrote: ... Why not pick up TeX? The output looks about as good as you will get, it can be presented as PDF, the source is human-readable and small, and bit-rot is zero. Oh, and both software for reading and creating is free. Ah, TeX - that takes me back - wy back... :) DocBook would be my suggestion if you really want to go fancy and free. It's XML-based, the DTD and "db2*" tools are Open Source, and it fans out to PostScript, DVI, HTML, PDF, and RTF. Texinfo does a lot of the same, but doesn't have the XML cachet DocBook has. Cheers, Ben Over and out, Bryan begin:vcard n:George;Bryan tel;fax:703-883-6708 tel;work:703-883-5458 x-mozilla-html:FALSE url:http://www.mitre.org org:The MITRE Corporation;Signal Processing Center adr:;;1820 Dolley Madison Blvd., M/S W622;McLean;VA;22102-3481;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Lead Signal Processing Engineer fn:Dr. Bryan George end:vcard S/MIME Cryptographic Signature
Re: To the keepers of the holy grail of Open Source
News flash: A _lot_ of technical people are using Word docs and PowerPoint presentations these days - Linux/VMWare is my weapon of choice, but there are others. Bryan Ben Tilly wrote: Jorg Janke [EMAIL PROTECTED] wrote: I would like to raise three issues: a) License issues b) Compiere license b) Open Source Trademark a) General License issues --- - I am a bit frustrated about the process; I had to submit our suggestion three times before receiving the first feedback. It would help if you sent mails as regular ASCII rather than formatted HTML. This is a question of knowing your audience. HTML can be made to look nice, which means that it will go over well with suits. However it suffers from bit-rot, displays differently on different platforms, is more complex for standard text tools to process, etc. Therefore technical types tend to see HTML email in the same category as Word and Powerpoint attachments - a sign that the sender is not technical and does not have a clue about how the technical community works. So say it in ASCII. It may not look as pretty to you, but it will go over a lot better with us. begin:vcard n:George;Bryan tel;fax:703-883-6708 tel;work:703-883-5458 x-mozilla-html:FALSE url:http://www.mitre.org org:The MITRE Corporation;Signal Processing Center adr:;;1820 Dolley Madison Blvd., M/S W622;McLean;VA;22102-3481;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Lead Signal Processing Engineer x-mozilla-cpt:;-9184 fn:Dr. Bryan George end:vcard S/MIME Cryptographic Signature
Re: Open Source *Game* Programming License
Ken Arromdee wrote: On Thu, 18 Jan 2001, Henningsen wrote: If one were to strip off the basic user interface from GPL'd game software and keep that proprietary, that would indeed be a hole. But most game graphics is large world files, and you can run the game software with different versions of these files to visit different worlds/play different games. But those files make up a large portion of the game. The game is useless without them. Oh, you could make a new world file, but by that reasoning, couldn't I make a program that needs readline, distribute it without readline, and tell the user to make a new readline function? World files are at least as important to a game like Quake as readline is to a program that uses it. Yes - likewise, a Website is useless without its content, a CD is useless without songs, a cell phone is useless without a service contract. Shall I go on? This is actually a much better illustration of the "Free software vs. free beer" concept than the one Mr. Schmid spent a great deal of bandwidth trying to sell. That reminds me - can I get this list in digest form? My "delete" finger is pretty calloused by now... :) Bryan begin:vcard n:George;Bryan tel;fax:703-883-6708 tel;work:703-883-5458 x-mozilla-html:FALSE url:http://www.mitre.org org:The MITRE Corporation;Signal Processing Center adr:;;1820 Dolley Madison Blvd., M/S W622;McLean;VA;22102-3481;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Lead Signal Processing Engineer x-mozilla-cpt:;-9184 fn:Dr. Bryan George end:vcard S/MIME Cryptographic Signature
LGPL clarification
but not library) products using the library, and preserves GPL compatibility? - If it is intractable to modify the LGPL, would it be more reasonable to modify another OSS license to be more LGPL-like in the ways I've described? - Or should we just say to hell with it and develop our source under an X11 license? :) Thanks very much in advance for your feedback. Regards, Bryan -- Dr. Bryan George Phone: +1 (703) 883-5458 Lead Signal Processing Engineer FAX: +1 (703) 883-6708 The MITRE CorporationEmail: [EMAIL PROTECTED] 1820 Dolley Madison Blvd., M/S W622 Internet: http://www.mitre.org McLean, VA 22102-3481 USA Disclaimer: I speak for absolutely no one besides myself.
Re: LGPL clarification
Ian Lance Taylor wrote: Date: Wed, 01 Nov 2000 11:13:38 -0500 From: Bryan George [EMAIL PROTECTED] As I said, that is how the LGPL _appears_. However, a close reading of the license text reveals what again appears to be a poison pill where commercial interests are concerned. Sections 5 and 6, in particular, seem in fact to put strings on executables that a company might want to sell. Section 5 states: "... linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables." And Section 6 states: "... As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications." These statements are very unfortunate, because they cross the boundary that the LGPL intends to establish between the OSS and commercial worlds, and dictate terms on the distribution of executable programs using LGPL-covered libraries. The LGPL is basically designed to support shared libraries. If you can distribute your package as a shared library, then the LGPL does not put any restrictions on the program which uses the library. This is how you avoid the restriction in section 5--the work is linked with the library at run time, so there are restrictions on the end user (the end user effectively can not distribute the linked program), but not on the program which uses the library. Unfortunately, what you say doesn't seem to square with what the LGPL says on the subject of static vs. dynamic linking (from the Preamble): "When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library..." Since dynamically-linked executables are considered derivative works, Sections 5 and 6 apply. If you can not distribute your package as a shared library, then you will indeed have difficulties getting it adopted by proprietary interests. It is technically possible, because the proprietary code can be distributed in object code form, but I've never heard of anybody actually doing that, and I think that most companies would balk. Indeed. - Assuming I'm interpreting the LGPL text correctly, are there any reasonable circumstances under which a company might be able to develop and deploy a binary executable without being subject to the stated conditions? Distribute your package as a shared library. Sure, and all that has to happen then is for every company developing embedded systems to design a dynamic linker into their next-generation products. I'm sure they'd be happy to comply. %b - If not, would it be difficult to surgically alter the LGPL to remove the OMAREC and maintain GPL compatibility? No. All you have to do is retain section 3. Sounds like it may be the way to go. Ian Thanks! Bryan
Re: LGPL clarification
Ian Lance Taylor wrote: - Assuming I'm interpreting the LGPL text correctly, are there any reasonable circumstances under which a company might be able to develop and deploy a binary executable without being subject to the stated conditions? Distribute your package as a shared library. Sure, and all that has to happen then is for every company developing embedded systems to design a dynamic linker into their next-generation products. I'm sure they'd be happy to comply. %b I didn't realize that this was for an embedded system. The LGPL won't help you. I'm not thinking of any specific cases - not yet, anyway - but yes, embedded systems would come into the mix as well as desktop platforms. At any rate, I think this particular discussion thread is largely academic. In the .com world, you have to make a strong case to convince management that it's worth employing a library that places ANY restrictions on ANY proprietary program that uses it under ANY circumstances. Especially in large companies where existing infrastructure works just fine, thank you, that's more trouble and career risk than the average engineer is willing to accept. Ian Bryan
Re: LGPL clarification
Ken Arromdee wrote: On 1 Nov 2000, Ian Lance Taylor wrote: The LGPL puts restrictions on P when it is linked with L. But so what? That linking will only happen on the end user system. The typical effect is that the end user is not permitted to distribute the executable now found in memory, because it is impossible to satisfy both the conditions of the vendor of P and the conditions of the LGPL. But the LGPL puts no restrictions on the distribution of P, which is what the proprietary user cares about. That is not, however, what RMS believes. If there is only one shared library that exists, he considers P to be derivative of it even before it is linked; and this triggers all licensing conditions on L even if P is not distributed with L. Remember readline? Readline is GPL'd, not LGPL'd, though, so I'm not sure how that applies in the present discussion. The LGPL does seem to be remarkably vague about the definitions and implications of linking, yes? Bryan
Re: LGPL clarification
That's an interesting notion - let's follow it: If I create and distribute a license which is a "derivative work" based on the LGPL without permission from the FSF, I could be sued for copyright violation. I couldn't claim "fair use" exemption either, since the license would benefit commercial interests. Under current copyright law, reproducing a similar concept, even using different language, would be a violation once I've been exposed to the original work, so I couldn't write a license from scratch that resembled the LGPL either without FSF permission. Given that the probability that FSF would give that permission to someone outside FSF is roughly, oh, zero, that means that the LGPL is for practical purposes the only Open Source license that can ever exist to cover libraries. Sorry, but that sounds a little too much like giving FSF ownership of truth and beauty, if you ask me... :) Seriously, though, if there are copyright issues involved with license surgery, I'd like more information on what they are and how to avoid them. Bryan John Cowan wrote: Bryan George wrote: - If not, would it be difficult to surgically alter the LGPL to remove the OMAREC and maintain GPL compatibility? No. All you have to do is retain section 3. Sounds like it may be the way to go. Unfortunately, the very first line of the LGPL prevents this solution: variants of the LGPL may not be created. -- 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 -- Dr. Bryan George Phone: +1 (703) 883-5458 Lead Signal Processing Engineer FAX: +1 (703) 883-6708 The MITRE CorporationEmail: [EMAIL PROTECTED] 1820 Dolley Madison Blvd., M/S W622 Internet: http://www.mitre.org McLean, VA 22102-3481 USA
Re: LGPL clarification
Naturally, I thought about the CVW license, but since the alternatives are the MPL, which FSF specifically doesn't like, and GPL, which precludes binary distribution sans code under any circumstances, it doesn't quite hit the spot. I'm beginning to settle in on the notion of invoking GPL + special dispensation for linked executables, plus maybe CVW-like government contract rights (is that necessary if the license if GPL-derived?). Have I proposed any gotchas as far as OSI is concerned? I can't imagine FSF barking too loudly, since they have similar licenses for Guile, etc.. Thanks for the lively discussion - very enlightening! Bryan Frank Hecker wrote: Bryan George wrote: MITRE (and similar organizations) regularly develop infrastructure libraries that we would like to see used in both non-commercial and commercial contexts, and that we would like to be considered standards, de facto or otherwise. For these reasons, I have taken a very keen interest in OSS licensing in general, and the LGPL in particular. Incidentally, you may be aware of this already, but Mitre has already created its own open source license, for use with the publicly released version of the Collaborative Virtual Workspace (CVW) software: http://cvw.mitre.org/cvw/licenses/source/license.html The Mitre CVW license agreement is basically a dual license scheme involving the GPL and the Mozilla Public License, plus some Mitre-specific language relating to the fact that the software was developed under US government contract, plus a provision for copyright assignment of changes sent back to Mitre. You couldn't use the Mitre CVW license as is, because it is specific to CVW; also, to be up to date the license should refer to version 1.1 of the MPL, not version 1.0. However with changes it might be suitable for your purposes; as an MPL/GPL dual license scheme it has similar features to those Karsten Self mentioned in connection with his proposed GPL/BSD dual license scheme. Plus the Mitre CVW license has been certified as OSI-compliant, and also has been reviewed and approved by Mitre management and legal counsel, so I suspect a variant of it would be able to get similar approval relatively easily. Frank -- Frank Heckerwork: http://www.collab.net/ [EMAIL PROTECTED]home: http://www.hecker.org/ -- Dr. Bryan George Phone: +1 (703) 883-5458 Lead Signal Processing Engineer FAX: +1 (703) 883-6708 The MITRE CorporationEmail: [EMAIL PROTECTED] 1820 Dolley Madison Blvd., M/S W622 Internet: http://www.mitre.org McLean, VA 22102-3481 USA
Re: LGPL clarification
Ian Lance Taylor wrote: Date: Wed, 01 Nov 2000 13:19:57 -0500 From: Bryan George [EMAIL PROTECTED] At any rate, I think this particular discussion thread is largely academic. In the .com world, you have to make a strong case to convince management that it's worth employing a library that places ANY restrictions on ANY proprietary program that uses it under ANY circumstances. Especially in large companies where existing infrastructure works just fine, thank you, that's more trouble and career risk than the average engineer is willing to accept. Note that the C library on GNU/Linux is under the LGPL. People who believe as you describe should avoid GNU/Linux. Hey, it's not me - I'll use my Linux box, as they say, till they pry my cold, dead hands off it - I'm just playing the Devil's advocate. But you raise a good point - if I statically compile program P using gcc, and apply a harsh interpretation of LGPL, then I'd have to provide object files so users could relink against a modified glibc, allow reverse engineering of my app, etc.. That certainly can't be what LGPL was designed to do. Indeed, if RMS were to assert that it was, I think you _would_ see a mass exodus away from GNU software - it's one thing to act like you own the world, it's quite another to _say_ you own the world... :) Ian Bryan
Re: LGPL clarification
Ian Lance Taylor wrote: Date: Wed, 1 Nov 2000 11:52:01 -0800 (PST) From: Ken Arromdee [EMAIL PROTECTED] RMS's analysis is not directly about the GPL, but about what "derivative work" means. If he's correct, he's correct independently of the actual license; *any* license that restricts derivative works will be triggered, whether GPL (readline), LGPL, or otherwise. Ken, can you point to specific quotes from RMS making this analysis? I'd be very interested to read them. LGPL, section 5: 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. I read this as saying that the LGPL specifically defines a program designed to work with the library as not being a derivative work in the context of the LGPL. As do I, for dynamically linked executables. But the OMAREC still seems to apply to statically linked programs. Even if, as I suspect, any jury in the known universe would throw out such an arbitrary distinction between dynamic and statically linked executables, its mere presence in the license text is a damper. Ian Again, thanks for the input. Now comes the fun part - sending a message to '[EMAIL PROTECTED]' asking their opinion of a modified LGPL essentially without Sections 5 and 6. Flame-proof suit - on... :) Bryan
