<div dir="ltr">On Mon, Oct 14, 2013 at 4:06 PM, Karl Fogel <span dir="ltr"><<a href="mailto:kfogel@opensource.org" target="_blank">kfogel@opensource.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Oct 14, 2013 at 5:32 PM, Luis Villa <<a href="mailto:luis@lu.is">luis@lu.is</a>> wrote:<br>

> Might be a good idea to finally start the list of non-open licenses someone<br>
> suggested a few months ago ;)<br>
<br>
</div>Oh, that is *such* a good idea.<br>
<br>
This is the "list of licenses that people often mistake for being open<br>
source, or whose authors claim are open source, but are actually not<br>
or at least have not been evaluated by the OSI", right?<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Slightly more broad than that: a list of licenses that we have rejected, including the rationales for rejection. Your list would presumably be a subset, as some licenses might have been submitted and rejected without a later, false claim to being open source.<br>
<br>Luis<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
-K<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Oct 14, 2013 2:28 PM, "Tom Callaway" <<a href="mailto:tcallawa@redhat.com">tcallawa@redhat.com</a>> wrote:<br>
>><br>
>> On 10/14/2013 09:32 PM, Karl Fogel wrote:<br>
>> > Obviously, I'd like to see TrueCrypt be truly open source.  The ideal<br>
>> > solution is not to have them remove the words "open source" from their<br>
>> > self-description, but rather for their software to be under an<br>
>> > OSI-approved open source license<br>
>><br>
>> I have not looked at the TrueCrypt license (in depth) in quite some<br>
>> time, but when Fedora and Red Hat reviewed it in 2008, not only was it<br>
>> non-free, it was actually dangerous.<br>
>><br>
>> (from 2008):<br>
>><br>
>> <a href="http://lists.freedesktop.org/archives/distributions/2008-October/000273.html" target="_blank">http://lists.freedesktop.org/archives/distributions/2008-October/000273.html</a><br>
>><br>
>> <a href="http://lists.freedesktop.org/archives/distributions/2008-October/000276.html" target="_blank">http://lists.freedesktop.org/archives/distributions/2008-October/000276.html</a><br>
>><br>
>> They appear to have reworded some concerning parts of that license,<br>
>> however, when we pointed out these concerns to them directly in 2008,<br>
>> their response was to forcefully (and rather rudely) reply that the<br>
>> problems caused by their license wording were not problems, but<br>
>> intentional. That alone gave us serious concern as to the intentions of<br>
>> the upstream, especially given the nature of the software under that<br>
>> license.<br>
>><br>
>> Notable is that Section VI.3 appears to be the same in the TrueCrypt<br>
>> license as it was in 2008. It is arguably necessary for any Free or Open<br>
>> Source license to waive some "intellectual property rights" in order to<br>
>> share those rights (which default to being exclusive to the copyright<br>
>> holder) with others. This section was noted to the TrueCrypt upstream<br>
>> (in 2008) as potentially conflicting with the rest of the license, and<br>
>> again, they pointed out that they were aware of the potential conflict<br>
>> and that it was _intentional_.<br>
>><br>
>> In short, we were forced to conclude the license was worded the way that<br>
>> it was (with clever wording traps) as a sort of sham license.<br>
>><br>
>> For what it is worth, I'm not sure the OSI should voluntarily spend any<br>
>> time or effort on the TrueCrypt license unless the TrueCrypt copyright<br>
>> holder brings it forward themselves with a willingness to address these<br>
>> issues in a serious and reasonable fashion.<br>
>><br>
>> The fact that there are other FOSS implementations for TrueCrypt (most<br>
>> notably tc-play (<a href="https://github.com/bwalex/tc-play" target="_blank">https://github.com/bwalex/tc-play</a>) minimizes the need<br>
>> to resolve these issues with the upstream, which is why Fedora stopped<br>
>> attempting to do so quite some years ago.<br>
>><br>
>> ~tom<br>
>><br>
>> ==<br>
>> Fedora Project<br>
>> _______________________________________________<br>
>> License-discuss mailing list<br>
>> <a href="mailto:License-discuss@opensource.org">License-discuss@opensource.org</a><br>
>> <a href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss" target="_blank">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss</a><br>
</div></div></blockquote></div><br></div></div>