Re: [alexb@ufl.edu: Re: support requirement]
I don't see any gotcha. I would probably not need Vendor X's documentation and/or output to reimplement the program. You might if they were sufficiently clever. I can think of several pieces of software where the vendor has managed to implement something in a non-obvious way that has significantly improved performance over the naive implementation and that there are no competitive free software clones of for that reason (at least none that I know of and I've looked in some cases). If you can't think of any non-free software for which there are no free alternatives, you are missing a lot of software (and perhaps you are lucky enough not to need it). The best example I can think of comes from the EDA industry. There are a handful of commmercial simulator vendors that dominate the market and charge big-bucks for their tools, and have done so for some time. As far as I can tell, there is no effective free software in that market--and that's despite the fact that there are standard documents describing the simulation languages, which should mean that someone could just "implement the spec" and come up with a free tool. I think part of the reason is that the obvious implementation performs too poorly (hours of simulation time versus minutes) and the vendors have carefully tied their customers hands with NDA's so that the customers can't go to a free software developer and say "we would like you to make a free version with the following optimization" since the knowledge of the optimization is covered by the NDA. -Chris
Re: support requirement
VAB writes: [...] 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? No. The idea is that the copyright law ordinarily prohibits people to do certain things, but licenses allow them to do these things. If the copyright owner grants you a particular license, you may then do the things which the license allows. This is true regardless of what other licenses have been granted to you or to other people. Nobody is allowed to grant licenses to other people's code. (The GPL alludes to this when it says "Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.") Issuing a program under one license never precludes you from issuing it under other licenses in the future, but this doesn't mean that you may ever issue other people's code under arbitrary licenses. I've seen many other people do dual licensing with supposedly "GPL" compatible licenses such as the artistic license as well. They are allowed to do that, if they are the authors. If they want to do that with other people's contributions, and those contributions were not also explicitly dual-licensed, they need to check with the contributors before dual-licensing the contributions. Am I mistaken and this type of dual licensing is only possible with an original work which contains no previously GPL'd code? It is only possible if all of the authors of the work have consented to it. Whether or not the authors have issued their work under the GPL in the past has nothing at all to do with whether it may be re-issued under other licenses. 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? Yes, certainly. (Remember that "it is not the intent of this section to claim rights or contest your rights to work written entirely by you".) But it will not satisfy _copyright_ to have the code licensed by multiple licenses without the consent of the copyright holders. 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? The GPL will do that. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
support requirement
Vendor X plans on releasing software as Open Source. X makes a number of very interesting and useful research-derived programs, and also runs an ISO-9000-certified software development shop. Their ISO certification requires that they run only supported programs, and thus the development shop is prohibited from running the output of their own research department. Thus, one of X's _main_goals_ in making the software Open Source is that commercial vendors pick it up and _provide_support_ for it. 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? Thanks Bruce
Re: support requirement
[EMAIL PROTECTED] writes: Vendor X plans on releasing software as Open Source. X makes a number of very interesting and useful research-derived programs, and also runs an ISO-9000-certified software development shop. Their ISO certification requires that they run only supported programs, and thus the development shop is prohibited from running the output of their own research department. Thus, one of X's _main_goals_ in making the software Open Source is that commercial vendors pick it up and _provide_support_ for it. 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? They could approach individual companies that might be interested in doing supported derived works and try to work something out in advance. For instance, they could tell their favorite ISV or consulting house that they will provide source code for something, and _promise_ to purchase a support contract on certain terms if that firm will offer one. Assuming that the contract is big enough, I imagine many companies could be interested in a proposition like that. It's still a really desirable goal to keep as much complexity as possible out of free software licenses. If a company has a particular business goal in releasing free software, it's much nicer if it can get the assurances it wants through side contracts rather than license provisions. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: support requirement
department. Thus, one of X's _main_goals_ in making the software Open Source is that commercial vendors pick it up and _provide_support_ for it. 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. Fix your ISO procedures to say that open source software doesn't need external vendor support. The whole point of open source is that you can write items into your ISO manuals that say "we can self support and audit this software, since we have the source code." I have a very hard time imagining any corporation large enough to sustain a research department that has not a single line of internally developed software as part of a critical ISO-9000 product path (not even a shell script!?). Their ISO manual must include some way that internally-written software that is internally-supported is considered "approved." It smells like personality politics to me. OpenSource can't solve every problem. They can require whatever they want in their license, but I doubt that condition will have the intended effect: Any "extra" requirements are going to reduce the likelihood of adoption of their software in general, and therefore reduce the market for companies considering providing support. If they really want to play the letter of the law, instead of the spirit of ISO (which is to ensure there are no shaky bridges), they could release it as open source without the extra clause, AND they should pay a retainer fee to a willing software developer, able and willing to offer a year's support at some pre-agreed hourly rate. Definition met. Letter of law obeyed. (Shaky bridge still in place, but hey, even MicroSoft is a shaky bridge for some products And Y2K is going to see a lot of other shaky support bridges exposed as well) Forrest J. Cavalier III, Mib Software Voice 570-992-8824 The Reuse RKT: Efficient awareness for software reuse: Free WWW site lists over 6000 of the most popular open source libraries, functions, and applications. http://www.mibsoftware.com/reuse/
Re: support requirement
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". That's real scary... especially after the previous discussion of selling the idea of open source code to corporate types. The threat of duplication here is emphasised for not opening up enough, and that's not going to encourage them to open up at all. What are the ethics of duplicating the functionality of an application? 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. Dj
Re: support requirement
"Forrest J. Cavalier III" wrote: department. Thus, one of X's _main_goals_ in making the software Open Source is that commercial vendors pick it up and _provide_support_ for it. 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. Fix your ISO procedures to say that open source software doesn't need external vendor support. The whole point of open source is that you can write items into your ISO manuals that say "we can self support and audit this software, since we have the source code." Except that the software customer may be ISO certified with no software development capability and no software development cycle. That I suggest is the problem. They can't say "we can self support this code"they have no developers within the ISO certified section of the company. Dj
Re: support requirement
It's true, though - not just a threat. If you don't go Open Source, someone else will do it for you, and there are lots of examples. While I'd not explain this to someone in terms of a threat, it is a _fact_ they must confront. Thanks Bruce From: Dj [EMAIL PROTECTED] That reads more like carefully couched GPL blackmail. "Release under GPL or we'll copy your product make it GPL ourselves". That's real scary... especially after the previous discussion of selling the idea of open source code to corporate types. The threat of duplication here is emphasised for not opening up enough, and that's not going to encourage them to open up at all. What are the ethics of duplicating the functionality of an application? 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.
Re: support requirement
Dj writes: 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". [...] What are the ethics of duplicating the functionality of an application? It's somewhat traditional. For instance, the GNU project duplicated the functionality of essentially _all_ of the standard Unix utilities. I can hardly count how many re-implementations of vi have been done. Most people in the free software world are willing to accept the idea of duplicating a proprietary program based on observing it (and reading its documentation) without access to its source code. In _many_ cases, proprietary libraries, kernels, or APIs have been re-implemented; this sort of happened in BSD because of the ATT lawsuit, and the WINE project is very consciously doing it with the Win32 API at the moment. Some people are willing to accept duplicating a program through disassembly, decompilation, and other reverse engineering techniques (assuming that no actual code is copied). That's much more controversial, ethically and legally. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: support requirement
Dj writes: DEVILSADVOCATE [...] So, I'm Vendor Q. I have a working product and I make money from it. "Hey, GPL your product" says a section of the community (not necessarily my customers). "Why?" ask I. "Well, if you don't do it then we'll do it for you" comes the response. "So why should I make it easier for you?"... "But we won't duplicate it by looking at your code, but by external reverse engineering". "So you don't need my code"? "Er, no, but it'd be nice if you went GPL". "Why?"... [...] /DEVILSADVOCATE This can be put a little less harshly. (1) Free software developers are always trying to produce software that they need or want. Sometimes they write things from scratch, sometimes they join on an existing project, sometimes they try to imitate someone else's program. (2) If a company is persuaded that free software or Open Source is a good idea, they have to consider how to go about it. This includes the choice of a license. (3) If a company chooses a good license that developers are willing to accept, more developers will release improvements. If it chooses an unfriendly license, or an extremely complex or unusual license, fewer developers will be willing to contribute under that license, and many will be more interested in reimplementing the software in order to get equivalents under licenses that they are willing to deal with. The canonical comment that I think of on this subject is Jamie Zawinski's phrase "magic pixie dust". http://www.jwz.org/gruntle/nomo.html Just because something is released under an Open Source license does not guarantee its the unconditional embrace by the community. Choosing a standard free license is one thing that could help on that score. -- Seth David Schoen [EMAIL PROTECTED] They said look at the light we're giving you, / And the darkness that we're saving you from. -- Dar Williams, "The Great Unknown" http://ishmael.geecs.org/~sigma/ (personal) http://www.loyalty.org/ (CAF)
Re: support requirement
Seth David Schoen wrote: This can be put a little less harshly. I did have my DEVILSADVOCATE tags on B) The canonical comment that I think of on this subject is Jamie Zawinski's phrase "magic pixie dust". http://www.jwz.org/gruntle/nomo.html Just because something is released under an Open Source license does not guarantee its the unconditional embrace by the community. Choosing a standard free license is one thing that could help on that score. But then, if the license is open source or a standard open source license, we still have the possibility that it will *still* get reimplemented. Remember that we started here with the suggestion that the GPL was "magic pixie dust" in terms of community acceptance. Dj
[alexb@ufl.edu: Re: support requirement]
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). -Chris * Chris ClarkInternet : [EMAIL PROTECTED] Compiler Resources, Inc. CompuServe : 74252,1375 3 Proctor Street voice : (508) 435-5016 Hopkinton, MA 01748 USA fax: (508) 435-4847 (24 hours) -- Web Site in Progress: Web Site : http://world.std.com/~compres --
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
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. Thanks Bruce From: Dj [EMAIL PROTECTED] So, I'm Vendor Q. I have a working product and I make money from it. "Hey, GPL your product" says a section of the community (not necessarily my customers). "Why?" ask I. "Well, if you don't do it then we'll do it for you" comes the response. "So why should I make it easier for you?"... "But we won't duplicate it by looking at your code, but by external reverse engineering". "So you don't need my code"? "Er, no, but it'd be nice if you went GPL". "Why?"... Substitute GPL with "Open Source" and you're still spinning in this problem zone, one which will keep Q from considering opening up. What's the purpose of "Open Source"? (The GPL purpose is transparently obvious) To bring software within "firing range" of the GPL/Clone route? (It's a lot easier to clone something if you have access to a full copy of what you are cloning)... Or to provide tangible benefits to software developers either alone or as a working group within an organisation?
