<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 24, 2018 at 8:11 AM D. Joe <<a href="mailto:sugarlabs@etrumeus.com">sugarlabs@etrumeus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, May 24, 2018 at 07:25:25AM +0200, Bastien wrote:<br>
<br>
> IANAL but I seriously doubt that "porting" an idea from one language<br>
> to another language counts as a derivative work.  That would be very<br>
> bad for the whole free software world.  Every FLOSS clone out there<br>
> is porting ideas from a software (e.g. Microsoft Office) to another<br>
> one (LibreOffice).  I think "derivative" is about lines of code, not<br>
> about ideas.<br>
> <br>
> There might be ann issue about design sometimes, when it has been<br>
> separately copyrighted -- but copyright on code does not cover design<br>
> ideas.<br>
<br>
<br>
Ah, I was wondering if/when "IANAL" would finally pop up in this thread :)<br>
<br>
I'm not one, either.<br>
<br>
That said, I am aware that questions of porting and derivative work have caused sufficient concern in the past to drive people to use clean-room design in their approach to re-implementation:<br>
<br>
<a href="https://en.wikipedia.org/wiki/Clean_room_design" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Clean_room_design</a><br>
<br>
If people are using clean-room design for Sugar and adjacent projects, I haven't seen it yet. :-)<br>
<br>
In the case of free software re-implementations, the exposure to derivative work entanglements seems even greater, since the access isn't just to the binaries of the upstream implementation, but usually to the source code, as well.<br>
<br>
One might be aware there has been ongoing concern more generally about codebases being published publically on code-sharing sites, but without any license statements. This led, for instance, to the creation of <br>
<br>
<a href="https://choosealicense.com/" rel="noreferrer" target="_blank">https://choosealicense.com/</a><br>
<br>
Similar considerations apply here: If you have access to the source code, but no license to do what you're trying to do, you can paint yourself into a corner, sharply restricting what can be done with your work (eg, who is willing to use, distribute, work with, contribute back to, your code).<br>
<br>
-- <br>
Joe<br>
<br></blockquote><div><br></div><div>In the context of this thread, there was no instance of clean room design or binary-only access. And in every case, an existing license was available. </div><div><br></div><div>-walter</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
_______________________________________________<br>
Sugar-devel mailing list<br>
<a href="mailto:Sugar-devel@lists.sugarlabs.org" target="_blank">Sugar-devel@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/sugar-devel" rel="noreferrer" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font><font>Walter Bender</font></font><br><font><font>Sugar Labs</font></font></div><div><font><a href="http://www.sugarlabs.org" target="_blank"><font>http://www.sugarlabs.org</font></a></font><br><a href="http://www.sugarlabs.org" target="_blank"><font></font></a><br></div></div></div></div>