Re: support requirement
[EMAIL PROTECTED] wrote: > > For the vendor it's really a choice of "go Open Source or lose _everything_". > If you GPL your product, you can probably still make money from it using > commercial licenses. If someone else clones your product, it's GPL-ed > anyway, plus you have a new competitor who wouldn't have been there > otherwise. Could you explain this to me bruce? I find it confusing. I've been wondering about dual licensing for some time now. The example that brought it to my attention was the PHP licensing. PHP consists of an interpreted programming languages (much like perl), and a run time for that interpreter. When you download PHP from www.php.net you are allowed to choose between the GPL and a less restrictive license written by the PHP programmers which allows commercial forking. What position does this put the PHP programmers in? Are they allowed to pick up code from the community (GPL'd code) and include it in PHP from which it can then propagate to commercial forks of PHP? I've seen many other people do dual licensing with supposedly "GPL" compatible licenses such as the artistic license as well. Am I mistaken and this type of dual licensing is only possible with an original work which contains no previously GPL'd code? I had thought that this would be the case based on my reading of the GPL, but I have a hard time believing that all of the code dual licensed out there is original code. Will it satisfy the GPL's viral clause (Paragraph 2b) to have the code licensed by multiple licenses and at least one of those licenses be the GPL? Is there a way I can prevent this from happening to my software? Is it legally possible for me to write a license that restricts any one at any time in the future from dual licensing any of the code that I write and taking it away from the community? - VAB --- V. Alex Brennen[[EMAIL PROTECTED]] [http://www.metanet.org/people/vab/] Systems Administrator/Sys. Prgr Pediatric Oncology Group [http://www.pog.ufl.edu/] Statistical Office University Of Florida 352.392.5198 x303 352.392.8162 Fax
Re: [alexb@ufl.edu: Re: support requirement]
Chris F Clark wrote: > > > In a perfect world I would get to work with all free software. I > > don't want to work with code unless it's free. If I need code and > > the only code out there is available under Vendor X's license and I > > have the time and ability to reimplement that code and place it > > under the GPL, I will do it. > > There is one gotcha in that. The current Vendor X license may > prohibit you from using it (including its documentation and/or output) > to implement a competing version. They could put such a stipulation > in a closed-source license. It is a simple variation on an NDA. If > Vendor X has something they consider unique enough, they may attempt > to protect their "ip" that way. This does not appear to be this > vendor's motivation, since it sounds like they are actively > considering distributing their software in an open source form (and > hoping that their software will become the default in its niche). I don't see any gotcha. I would probably not need Vendor X's documentation and/or output to reimplement the program. The possible exception to that statement is that I would be seeking compatibility with Vendor X's protocol or file format. If the license prohibited me from achieving that compatibility with a GPL'd work, I would write my own competing file format or protocol. In the past such open protocols and open file formats have either succeeded in replacing the closed format or in pressuring the owner of the closed format to open it. Even if Vendor X tied itself to proprietary hardware, people would just reimplement the hardware. A good example to site here is the GNU/Linux user boycott on the Logitech QuickCams and that community's migration to the Panasonic Egg Cam and other alternative open hardware. The GPL is a very unique animal in that it has grown beyond just a license into the embodiment of a community (a small subset of what most people consider the free software community - but a very significant subset none the less). The GPL has in fact become "magic pixie dust" as it was termed. - VAB --- V. Alex Brennen[[EMAIL PROTECTED]] [http://www.metanet.org/people/vab/] Systems Administrator/Sys. Prgr Pediatric Oncology Group [http://www.pog.ufl.edu/] Statistical Office University Of Florida 352.392.5198 x303 352.392.8162 Fax
Re: support requirement
Dj wrote: > > VAB wrote: > > > A fact rarely mentioned on the list is that release under a > > license other than the GPL brings with it the danger that > > the software product will be reimplemented under the GPL. > > This is likely if Vendor X releases under a license which > > is unattractive due to say, required support terms. > > That reads more like carefully couched GPL blackmail. > > "Release under GPL or we'll copy your product make it GPL ourselves". I have no intent to blackmail anyone. Please don't take this as a threat to reimplement the software if they don't release under the GPL. It was my intent to express that I didn't feel the license being proposed was "free" enough. I was expressing my believe that upon being presented with such a license (one which did not guarantee freedoms in the same way as the GPL) the community would write their own free software to perform what ever tasks they would have needed Vendor X's application for. I think of my self as part of the Free Software Community. I think of that community as consisting of the developers and users of free software and of the codebase of free software (most of which happens to be under the GPL.) I don't think of myself as part of the opensource community. Many opensource licenses don't meet the qualifications of my definition of free software. I therefor avoid those licenses and source code licensed under those license. I avoid that code because even though it may fit the definition of opensource, it's not really free software - it's not part of the community. In a perfect world I would get to work with all free software. I don't want to work with code unless it's free. If I need code and the only code out there is available under Vendor X's license and I have the time and ability to reimplement that code and place it under the GPL, I will do it. The Free Software Community has a long history of duplicating the functionality of software in order to produce a totally free version of that software. I could list scores of examples, but I'm sure everyone here is familiar with many if not most of them. > What are the ethics of duplicating the functionality of an application? I'm surprised to hear you ask that. Are you suggesting that GNU/Linux never should have been written because Microsoft Windows and AT&T Unix existed first? Or suggesting that gnumeric never should have been written because Microsoft Excel existed first? I feel that I should be free to write what ever software I choose as long as I don't infringe upon the copyright of another developer. I am strongly against software patents and laws such as the cryptography export restrictions which restrict my rights (of free speech) to write software. While it still cannot compare to the personal beliefs of many of the community developers, the GPL codebase is now driving a significant amount of such reimplementation. Let's say for example that I have GPL'd app G and I want to take Vendor's X's app H and combine some of the functionality of H into G. I can't do it unless H is also under the GPL. There's is allot of GPL'd code out there. Most software has gotten so complex that it's difficult for a single person to write it. Many community developers re-use vast amounts of GPL'd code, hence their application must be GPL'd. They must reimplement the parts which are not GPL'd, if they seek to derive their application from the GPL'd code. > Oh, and there's an assumption that Vendor X's application will be > sufficently compelling as to take up a position of standardness in > it's niche yet there's no assurance of that. > > I suspect to sell the open sourcing idea within Vendor X, someone's > going to need a bit more than a faith that the product will be picked up > by the community. This, of course, can't be given. Facts are facts, if it's not GPL'd someone will likely reimplement. The FSF has had numerous projects going on for many years to reimplement non-GPL'd (non-free) software. A very large portion of GNU/Linux consists of that software. As an example take the Mozilla project. There are many browser projects progressing under the GPL even though the Netscape released much of their source code under the MPL. Even though the MPL qualifies under the terms of the OSD as an opensource license, the MPL licensing terms discouraged people from working on that project and from working with that code. The terms of the MPL were sufficiently unattractive enough to some developers that they started their own browser projects rather than contribute to the Mozilla project. To write a web browser is a massive project. Some alternative projects would exist even if Mozilla was
Re: support requirement
[EMAIL PROTECTED] wrote: > > Thus, their license requires that if you distribute a derived work of their > program _and_ you provide support on reasonably comparable programs, > that you provide support for their program too. The provision has no effect > on organizations like Debian that don't provide support. > > This is currently the stumbling block for X's license being Open Source. > Any ideas, folks? I don't see any way for this to occur under the OSD. The requirement of providing support for product X if you derive product Y from product X violates paragraph 1 of the OSD - Free Redistribution. I would also argue that it violates paragraph 5 as well, by requiring that one group of developers incur monetary costs providing support (which possibly prohibit their development efforts) while other developers are free from that restriction. While it may be possible to interpret the OSD as allowing this type of licensing, in my opinion something like this violates the most important aspects of free software. It violates the right of a third party to fork the project by placing demands on third parties who do. In the very least it discourages forking by this requirement. The ability to fork is critical to the development of cutting edge, lean, stable software. The ability to fork has played a large part in the development of opensource software's reputation for stability. I think Vendor X's methods are misguided. If Vendor X is interested in the benefits of opensource and feels the their current course of action is critical, they could continue and release the source code with a non opensource license that contains the suggested terms. If Vender X is interested in contributing to the community and in reaping the benefits that are incurred through that action, Vender X should release their code under the GPL. Release under the GPL ensures that the code is available to everyone, available as opensource, and that the code remain available for refinement and improvement. A fact rarely mentioned on the list is that release under a license other than the GPL brings with it the danger that the software product will be reimplemented under the GPL. This is likely if Vendor X releases under a license which is unattractive due to say, required support terms. If a GPL'd application defeats Vendor X's OpenSource (or Non OpenSource/Source Available) application in the battle for market share, Vendor X looses many of the benefits the focus of community developers could have provided to it, and Vendor X really looses out if people pick up the standard app (the GPL app) and provide support for it. In summation, release under the GPL (even though it does not have the support guarantee Vendor X is looking for) nearly ensures (as long as Vendor X is receptive to patches and suggestions) that Vendor X's app becomes the standard app for it's nitch with in the community, encouraging it to be picked up and supported. Release under a license other than the GPL encourages reimplementation, especially if that license is for some reason unattractive (if for example it would be cheaper for Vendor Z to reimplement or base on an alternative GPL'd project than provide support). - VAB --- V. Alex Brennen[[EMAIL PROTECTED]] [http://www.metanet.org/people/vab/] Systems Administrator/Sys. Prgr Pediatric Oncology Group [http://www.pog.ufl.edu/] Statistical Office University Of Florida 352.392.5198 x303 352.392.8162 Fax
