<div dir="ltr"><div><div>According to the FAQ at gnu .org<br>(<a href="http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary">http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary</a>):<br><dl><dt id="UnchangedJustBinary">I
    downloaded just the binary from the net.  If I distribute copies,
    do I have to get the source and distribute that too?<span class=""></span></dt><dd><p>
Yes.  The general rule is, if you distribute binaries, you must distribute
the complete corresponding source code too.  The exception for the case
where you received a written offer for source code is quite limited.</p></dd></dl><br></div>...doesn't this imply that deken should also provide the source code itself, at least as an option?<br><br></div>Martin<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 22, 2015 at 8:07 AM, Roman Haefeli <span dir="ltr"><<a href="mailto:reduzent@gmail.com" target="_blank">reduzent@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2015-12-17 at 19:20 +0100, Fred Jan Kraan wrote:<br>
<br>
> ><br>
> > I would rather propose adding some mandatory meta information to deken<br>
> > uploads. A package that can be downloaded from <a href="http://puredata.info" rel="noreferrer" target="_blank">puredata.info</a> should at<br>
> > least contain the information which sources it was built from.<br>
><br>
> The <a href="http://puredata.info" rel="noreferrer" target="_blank">puredata.info</a> could host such a list in the public wiki.<br>
><br>
> It is not very convenient to download several packages just to find out<br>
> the most recent/bug free.<br>
<br>
Exactly. This is why there is a version field in deken packages.<br>
<br>
I don't see how something like a fork map helps the end user, i. e. the<br>
one using Pure Data and installing an external through deken. When you<br>
install something with deken, you primarily want to know what sources<br>
have been used to build that package. Once you know that, you might also<br>
want to know where those sources are forked from. Currently, you only<br>
know _who_ as uploaded a package, but you do not know _where_ the<br>
sources of a package are hosted.<br>
<br>
I'm not opposing the idea of a fork map, but there is more important<br>
information missing before that.<br>
<span class="HOEnZb"><font color="#888888"><br>
Roman<br>
</font></span><br>_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at">Pd-dev@lists.iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-dev</a><br>
<br></blockquote></div><br></div>