<div dir="ltr"><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div>Hi there Yutaka,</div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 7, 2015 at 8:37 PM, Yutaka MATSUBARA <span dir="ltr"><<a href="mailto:yutaka@ertl.jp" target="_blank">yutaka@ertl.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Carlo,<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    (a) The above copyright notice, this use conditions, and the<br>
        disclaimer shown below must be shown without modification in<br>
        the document provided with the redistributed software, such as<br>
        the user manual.<br>
</blockquote>
<br>
The example is clear, but why is it not sufficient to accompany any<br>
distribution in such a form with a copy of the license itself?<br>
</blockquote>
<br></span>
The form with a copy of the license itself meets (a) clearly.<br>
Do you have a concern?<span class=""><br>
        <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    (b) How the software is to be redistributed must be reported to the<br>
        TOPPERS Project according to the procedure described<br>
        separately.<br>
</blockquote>
<br>
If this was the only option available, this would make the entire<br>
license strikingly non-compliant, IMHO. In addition, reference to a<br>
specific project ought to be omitted, otherwise the license would<br>
practically be limited to a single use -- a one-way free ticket to<br>
proliferation.<br>
</blockquote>
> I would advocate that, because the condition under b) is non-compliant,<br>
> it should be removed for the license to be approved.<br>
<br></span>
I think that if a user can do (b), then the user can do (a) as well.<br>
What kinds of situations do you imagine?<br></blockquote><div><br></div><div>I am still concerned that the license could result in situations where a developer is unable to ensure a document is included with the software they are distributing (imagine a portion of the code is excerpted and used in an embedded function in a hardware component used for constructing other products). In this event, (b) would be the only option and it is clearly not OSD compliant. As such I don't believe the license as a whole can be OSD compliant.</div><div><br></div><div>Remember, open source code is frequently excerpted outside the scope of the original project, even if you are not aiming for that. In addition, OSI approves licenses for general use not just for your use. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Several licences including names of specific projects/companies have been already approved. I think that these licences seem to be limited to use cases. What differences between these licenses and TOPPERS license do you see?<br></blockquote><div><br></div><div>Indeed, licenses were historically approved with specific names in them. Since the anti-proliferation discussions OSI hosted nearly a decade ago, we have been avoiding new licenses that refer to specific projects. The license should be genericised for anyone to use before being approved.</div><div><br></div><div>S.</div></div></div></div>