Excuse the long post. Ben Finney <[EMAIL PROTECTED]> writes:
>> I guess it's safe to assume that you are not opposed to using code >> based on more liberal license, right? :-) > > I'm less inclined to base work on, or contribute to, a work under a > non-copyleft license, because I have less assurance that the code will > remain free for all recipients. In practice, the probability of hijacking of source code by an evil corporation is very low for most projects. And even when it did happen, the evil corporation would likely submit patches. The more users an open source project has, the better. Also, you can do what Paul Boddie did - fork the project, or maintain patches that are under LGPL. With a liberal license, you have that privilege. > There's no single free-software license that won't displease some > segment of the free-software community. I think the Vellum project I don't think BSD/MIT like license really annoys anyone. Think python here ;-) I'm also answering some points by Zed here (assuming they were meant for mailing list): > Well, I'm also telling people that it's like the GNU toolchain in that > using it doesn't mean your stuff is GPLed. Just if you import it as > a library or write commands for it that you release. I realize this - there is a difference here between tools that you run and tools that you link to / import. However, Vellum could be in the middle ground, since the commands you create do link with Vellum. > Ok, so for you it's a religious thing more than a technical capability > or limitation thing? Does that mean you use a BSD alternative for > everything GNU, like GCC as well? Not at all, it's a very practical thing related to all the intellectual property lawyerage in corporate setting. With Vellum, it doesn't matter a lot because most of the tools are only used in-house, but it would still be nice if you could just grab the code from somewhere without having to think about license at all, or considering whether any of this would ever be needed for something that involves selling stuff under proprietary license. To stay on topic of Vellum, let's consider the scenario where someone digged Vellum's syntax, and would like to use the parser in a proprietary app - or create commands that include proprietary stuff (it's not the developer's call, but the corporate policy). Vellum parser would be only a small component in the whole system. Would you rather make the developer: - Find some other, inferior parser with more liberal license or reimplement Vellum syntax from spec (typical "nah, this is gpl, I can't use this, continue with the next google hit" scenario) - Just grab the Vellum implementation and use it without concern or management discussions, yielding yet another developer that saved some time, had more coffee breaks and possibly hit the deadline early, recommending Vellum code to his colleagues as a good starting point to whatever they are doing, and perhaps contributing some code or ideas back? Note that this applies mostly to small tools / libs. Big projects like Linux kernel, Gnome or KDE have to be seriously concerned about malicious use of their intellectual property, but a small open source tool is more likely to be (initially) picked up by an individual developer who thinks something is cool; and it will never be the money-making part of the product. Also, for some reason, GPL is used for evil (dual-licensing schemes - make money but still gain the open source mindshare, and possibly rack up free contributions to something that is your *commercial product*) more often than it's used for good (gcc, Linux kernel - prevent IP exploitation and ensure that all improvements are freely accessible). I must say that if I implemented something I want to make money on at some point, I would license it under GPL. If I'm just scratching my own itch, having fun or racking up open source feelgood karma, I would use MIT (or BSD, as we are doing w/ IPython). So I'm not opposed to GPL - just saying that it's not often the choice that will net you the most users. -- http://mail.python.org/mailman/listinfo/python-list
