<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi John,</div><div><br></div>On 13 Apr 2014, at 15:26 , John Layt <<a href="mailto:jlayt@kde.org">jlayt@kde.org</a>> wrote:<br><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I was just about to ask on the other thread what the licensing issues are, so is it just OpenSSL causing problems?</div></div></div></div></blockquote>Mostly yes.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We do have a special KDE list for licensing issues
<a href="https://mail.kde.org/mailman/listinfo/kde-licensing">https://mail.kde.org/mailman/listinfo/kde-licensing</a> that it may be worth
asking things on. Another option is to ask Sune Vuorela, a core KDE
hacker and Debian packager who is usually very clued-up on such issues, or better yet ask on the <br></div></div></div></div></blockquote>I think we should address that on that list. But since I am not specialised in that field I leave that to Nicos, Ian, or Brad.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm not sure the exception is an option for MacPorts though.<br></div></div></div></div></blockquote>Neither am I. [1]</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>the apps affected just need to use an LGPL wrapper (like Qt), or find an alternative library to use for their needs GnuTSL, or something that supports just the bits they need. </div></div></div></div></blockquote><div>Yes, that was also discussed on MacPorts. </div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Perhaps you need to open bugs against each of the affected apps to find out why they need to depend on things that use OpenSSL</div></div></div></div></blockquote>That could be a way to go.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> (e.g. I really don't see why KMyMoney needs git-core or gtk-doc, or is that a MacPorts packaging problem?). </div></div></div></div></blockquote><div>No, it’s not neither a MacPorts nor a KMyMoney problem! git-core I simply need because I pull the latest master from KMyMoney’s git repo, at least for kmymoney4-devel.</div><div><br></div><div>However, gtk-doc puzzled me now, since it doesn’t seem to have dependent ports.</div><div>—</div><div><div>$ port rdependents gtk-doc</div><div>gtk-doc has no dependents.</div></div><div></div><div><div>$ port rdeps kmymoney4-devel</div><div>...</div><div> kde4-runtime</div><div> kdelibs4</div><div> soprano</div><div> libiodbc</div><div> gtk2</div><div> gtk-doc</div><div>…</div><div>—</div><div>But as one can see it is again soprano, which will go away soon. :-)</div><div><br></div></div><div><br></div></div><div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If they can't stop using it then they could try make it a plugin that can be built and shipped separately.</div></div></div></div></blockquote><div>Yes, one could use an opt-in variant for that once upstream has implemented it.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>From that list, the big problems for KDE are Poppler and MySQL and perhaps GnuPG for PIM (as Ian notes, Virtuoso and Soprano are going away in 4.14).</div></div></div></div></blockquote>Yup!</div><br><div>Greets,</div><div>Marko</div><div><br></div><div><br></div><div>[1] <a href="https://lists.macosforge.org/pipermail/macports-dev/2013-October/024710.html">https://lists.macosforge.org/pipermail/macports-dev/2013-October/024710.html</a></div></body></html>