<div dir="ltr"><br><br><div class="gmail_quote">On Sun, Apr 10, 2011 at 2:26 PM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir@cohens.org.il">tzafrir@cohens.org.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><div class="im">
> IMHO in most of these cases the GPL license will be a deterrence<br>
> from even trying the thing.<br>
<br>
</div>But this is when the GPL is used in production. Not for evaluation.<br></blockquote></div><br>I think this last statement is wrong. On top of the "distribution" problem IP-conscious companies also worry about "contamination". So GPL as an evaluation license carries this additional concern. Overall, I'd say GPL has a larger "chilling factor" than a decent (and short) proprietary license.<br>
<br>Another point that I mentioned in an earlier post but not sure if it registered. Consider the following hypothetical case. <br><br>Vendor A (fits this case, huh) provides a library to Business B for evaluation, under GPL. Business B actually needs the library to work with their proprietary code and with code from Consultant C. Therefore, Consultant C's verdict is essential for evaluation.<br>
<br>GPL has no notion of evaluation (or, indeed, of any specific purpose). >From GPL's point of view, Consultant C is a "3rd party", therefore, if Business B gives Consultant C a copy of A's library (maybe together with their own stuff) it constitutes "distribution".<br>
Consultant C, on the other hand, is an independent entity as retains the rights for the stuff that he creates.<br><br>Altogether, this situation leads (or may lead) to the following:<br><br>* If B delivers their code linked to A's library to C then they may have to GPL their stuff. This may not be what they want.<br>
<br>* If C gives his code to B, linked to library A, even as a test, he may need to GPL his code. This may not be what he wants.<br><br>* Unlike B, Mr. C may be in a position to compete directly with Mr. A. Mr. A may not want to give his code to Mr. C without restrictions.<br>
<br>GPL has no mechanism that takes the B-C and C-A relationships into account, it is all about A-B.<br><br>All in all, it looks to me, without going into further detail, that a license that will not have some of the restrictions/freedoms of GPL, but will have some of the restrictions/freedoms relevant to evaluation (scope, duration, NDA-safety, etc.) will be more appropriate.<br>
<br>AFAIK, there is no mechanism in GPL that allows specifying something like "evaluation" or "limited distribution", and that's a key point. If a dual license fits the purpose then the library can be posted on some ftp site for *everybody* to download and use under GPL, and support/enhancements/etc. may be provided under a different license. There are numerous examples - some have been mentioned here. However, if the two versions become different then a potential customer will have to be satisfied by evaluating the GPL version rather than the version they will ultimately pay for. If this is not OK then there may be no need for a GPL version at all...<br clear="all">
<br>-- <br>Oleg Goldshmidt | <a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a><br>
</div>