Re: mysql
On Fri, 2003-11-21 at 23:54, Rodrigo Barbosa wrote: Actually, what limits your hability to distribute your application is not MySQL AB, but the GPL itself. Indeed. It's the 'viral' nature of GPL that makes dual licencing economically feasible. See my essay Open Source Business Found Parasitic archived in this list and in www.SoftDevelCoop.org. (I just now realised that my recent postings we're not getting into the list because I changed email address and I forgot to resubscribe and the list server is silent about failed postings. Just for the record my failed postings we're mainly replies to people looking for a commercial open source licence, pointing them to SDC.) -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: OFF-TOPIC - The SCO suit
True, the potential impacts of U.S. litigation -expense- and -duration- shouldn't be ignored, if one wants to speculate re. the outcome and/or re. the interim tactical aspects of SCO v. IBM (and the IBM v. SCO counterclaims). (Those factors can be huge. I often use documentation of U.S. lawsuit duration, costs, and granularity to educate clients about the potential long war they might find, versus the fast battle they assume, when they inquire re. initiating a lawsuit.) As a former litigator (I moved away from that side in '83!), I can assure you that many experienced U.S. lawyers and businesspeople see some U.S. litigations wrapped up (with varying outcomes) due to huge costs in cash and effort (without even considering other possible adverse decision-driving factors, like possible negative impacts on customer, partner, and supplier confidence, regulatory impacts in some situations, etc.). In that regard, many folks marveled re. the massive costs and years involved in the U.S. (Dept. of Justice) v. IBM antitrust litigation of earlier times. (Insert here caveat re. antitrust litigation perhaps being inherently more abstract and hence protracted and expensive than i.p. litigation - but that's debatable here, given the particular nuances of the SCO v. IBM situtation.) And, yes, one task (tactic?) sometimes seen in U.S. commercial/i.p./etc. litigation is trying to kick out an initially involved key individual, for various reasons. (E.g., in the now settled Canopy Group [of Utah] v. Computer Associates contract litigation, C.A. moved to exclude the C.G. General Counsel from access to materials disclosed under the litigation document-sharing [discovery] process.) Those desiring a fast outcome in SCO v. IBM (a) should research the durations of big-league U.S. litigation, particularly in issues of first impression (new legal questions) and (b) might be disappointed, given the pace of such processes. Henry W. (Hank) Jones, III Intersect Technology Consulting -and- Law Office of Henry W. Jones, III Austin, TX [EMAIL PROTECTED] -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
Marius Amado Alves wrote: On Fri, 2003-11-21 at 23:54, Rodrigo Barbosa wrote: Actually, what limits your hability to distribute your application is not MySQL AB, but the GPL itself. Indeed. It's the 'viral' nature of GPL that makes dual licencing economically feasible. See my essay Open Source Business Found Parasitic archived in this list and in www.SoftDevelCoop.org. No, it's the FUD that the GPL is 'viral' and therefore must be avoided in business environments. It is very well possible to combine GPL-licensed software with proprietary applications. You just have to make the right architectural decisions. Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
On Sat, 2003-11-22 at 16:19, Arnoud Engelfriet wrote: No, it's the FUD that the GPL is 'viral' and therefore must be avoided in business environments. No. Read my paper. It is very well possible to combine GPL-licensed software with proprietary applications. You just have to make the right architectural decisions. Sure. But there is still a big class of cases where the GPL's viral nature imposes itself. The original poster's problem was situated there, I believe. There is a great range of business environments: some deal well with GPL, some don't. Dual licensing is a great way to explore the viral nature of GPL. When I say 'viral' I do so without any prejudice whatsoever. My own organization's flagship license Conditions of Use of SDC Artifacts has also viral elements, namely item 18: The modified artifact is still an SDC artifact subject to the current Conditions of Use of SDC Artifacts. (www.softdevelcoop.org) ***And I really resent being called a FUDer.*** GPL's viral nature is right there on clause 2b for everyone to see: You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. It's clear how this can be a problem to a lot of businesses, and experience (even in this list) shows beyond doubt that it really is a problem to many real businesses. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
Mitchell Baker wrote: Arnoud Engelfriet wrote: No, it's the FUD that the GPL is 'viral' and therefore must be avoided in business environments. It is very well possible to combine GPL-licensed software with proprietary applications. You just have to make the right architectural decisions. Yes, but just making the right architectural decisions is not easy. Sometimes almost impossible if the code is already written. And sub-optimal in far more situations. It takes nothing away from the GPL to admit that it can be very awkward for use it in business settings. True. I didn't want to create the impression that it's easy. You have to think through what will happen and what parts subsequently will be open sourced, and whether that is acceptable from a business (and legal) point of view. And in large complex environments, making the right architectural decisions is difficult enough on purely technical grounds. Adding another lawyer adds yet more complexity and increases the chance of failure all around. Adding another _lawyer_? Surely you meant 'layer'? :-) Arnoud -- Arnoud Engelfriet, Dutch patent attorney - Speaking only for myself Patents, copyright and IPR explained for techies: http://www.iusmentis.com/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
Marius Amado Alves [EMAIL PROTECTED] writes: When I say 'viral' I do so without any prejudice whatsoever. The word itself is somewhat prejudicial, though, as rather few people have positive connotations for the word ``virus.'' I think a better word here is ``sticky.'' The GPL is a sticky license; once it is attached to code, it can't be removed. The BSD license is not sticky; it can be removed (or at least the most important provisions can). Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
On Sat, 22 Nov 2003, Ian Lance Taylor wrote: I think a better word here is ``sticky.'' The GPL is a sticky license; once it is attached to code, it can't be removed. The BSD license is not sticky; it can be removed (or at least the most important provisions can). No, the terms in the BSD license can not be removed by someone redistributing the work, or even a derived work from a BSD-licensed work that is under a different license. One can *add* new terms, though, which the GPL forbids. Brian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
Brian Behlendorf [EMAIL PROTECTED] writes: On Sat, 22 Nov 2003, Ian Lance Taylor wrote: I think a better word here is ``sticky.'' The GPL is a sticky license; once it is attached to code, it can't be removed. The BSD license is not sticky; it can be removed (or at least the most important provisions can). No, the terms in the BSD license can not be removed by someone redistributing the work, or even a derived work from a BSD-licensed work that is under a different license. One can *add* new terms, though, which the GPL forbids. Fair enough. I still think ``sticky'' is a reasonable word to describe the effects of the GPL. What the GPL does is make it difficult to add further encumbrances to the code. ``Viral'' isn't a particularly good word even apart from the negative connotations. The GPL doesn't ``infect'' non-GPL code; GPL code resists being linked with non-GPL code, but it's a strictly passive process. Using a military metaphor, a GPL program is a fortress; anybody can come inside the fortress, but nobody can take it over. Under that metaphor, the GPL is a ``fortifying'' license. Ian -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: mysql
Viral, fortifying, both have unwarranted connotations (in opposing directions). What about: black hole? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Searching clarification on OSI and libraries
Hello .*. I stumbled over the GPL as license used for a library today. You guess it... no linking or dlopening allowed. I have been reading some few of the licenses published on OSI. Tough material if english is not your native language. Finally i am completely confused and whish for someone brave enough to add a section named Human readable library diff or something to the FAQ section of the website. Context first... 1. Someone asked me if i was interested to help adding support for some protocol to a product that is sold commercially. There are a few libraries providing an interface for that protocol. One implementation i favor is plublished under the GPL. That means that i can only support it using some sort of wrapper that communicates using pipes or sockets. Problem is that a wrapper approach is not acceptable for the party that asked for help. Conclusion is that this special library will not be supported. That means an option for testing and spreading it is wasted here. 2. I have a personal project i work on and i want to publish it as open source. It will consist of a library and one or two example programs that make use of the library. I am searching for a license for my project now. - I want the code to be usable for as many people as possible - I definitly want to allow comercial products to use the library - I want that people can write modules that the library dlopens at runtime and those shall have whatever license the owner thinks is apropriate. - I want the library core to stay a working little changable thing and publically available - I want to allow people to copy parts of the example application and use them as a starting point for whatever they are working - I want to avoid that someone copies the whole example, adds a 10 line gui and sells it as his Root Of All Evil.exe I first thought about GPL for the example and LGPL for the library. But then noone can copy files from there and start their own project with them. The point is that I want to make it as easy as possible to start using the library in order to have a good chance to spread it. If I put the library part under the OSL, is it allowed to link it to comercial programms then? What are the differences between GPL and OSL? What is the intention of OSL? Is it ment as a replacement for GPL for people that are not as drastic as RMS? The last and most confusing issue is the documentation: You generate API documentation from comments in libfoo.c and add it to bar.xml. Then you add intentions.xml to bar.xml. Finally you extract some random code as an example from appfoo.c and add it to bar.xml. Q: What license has bar.xml now? A: LSL (License Soup License) Is LSL OSI certified? ;) Thanks in advance, sorry for the length, peter. -- PGP Key: 0x3DF861E7 -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
