From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3246 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Licensing. Date: Mon, 29 Apr 2013 16:47:31 -0400 Message-ID: <20130429204731.GZ20323@brightrain.aerifal.cx> References: <7DA8A203-CFF2-4559-AA2C-7CF38B5DD28E@palsenberg.com> <1367184878.18069.171@driftwood> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1367268466 22570 80.91.229.3 (29 Apr 2013 20:47:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 20:47:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3250-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 29 22:47:46 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UWuzA-0007Ud-Ox for gllmg-musl@plane.gmane.org; Mon, 29 Apr 2013 22:47:44 +0200 Original-Received: (qmail 7908 invoked by uid 550); 29 Apr 2013 20:47:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7898 invoked from network); 29 Apr 2013 20:47:43 -0000 Content-Disposition: inline In-Reply-To: <1367184878.18069.171@driftwood> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3246 Archived-At: On Sun, Apr 28, 2013 at 04:34:38PM -0500, Rob Landley wrote: > On 04/26/2013 01:11:07 AM, Igmar Palsenberg wrote: > > > >>>> incompatible licenses. The openssl library can't be used with > >a GNU > >>>> program unless there's a waiver for it because one of the > >clauses in the > >>>> openssl license goes against the GNU license principles. The > >gnutls > >>> Not _used_ but _distributed_. The GPL does not restrict use > .... > >> What about explicitly loading the library at run-time using > >uselib(2) in a plug-in like fashion? Is that also considered > >problematic from a GNU perspective? > > > >I consider this a grey area. I personally don't thing it is > >considered a problem, > >but there are a number of interesting (theoretical) scenario's : > > Um, back up: > > You know how cryptographers point and laugh at non-cryptographers > trying to figure out whether something's breakable? > > You know how professional security auditors find most programmers' > code appallingly insecure, and the best of us have to put out > regular updates to fix exploits that we didn't personally find? > > Now imagine what lawyers think of programmers' legal theories. Your analogy would hold more water if the majority of lawyers doing software licenses had any clue about the law, but they don't. Nearly everything ever written in a proprietary software license has no basis in law; legally, such documents are not even licenses (a license gives you permission to do something that would otherwise not be permitted under the law; it doesn't take away your rights) but one-sided contracts that are never signed and that offer the victim nothing of value in exchange for surrendering their rights. > Programming-side example: the /tmp dir has the sticky bit set other > users running inotify to spot new files being created don't > immediately delete them and replace with a symlink so your > mknod/open pair is now accessing the wrong file. What your code is > doing worked fine, but the context it was running in made it > insecure. I don't follow. Unless you do idiotic things (like omit O_EXCL) there is nothing unsafe about properly-configured public temp directories. > Now imagine telling a lawyer that your license usage is > unexploitable in all jurisdictions, and you know this because you > read the license text and you're sure you're using it ok. (The best > a lawyer or security professional can EVER say is "I can't spot > where you screwed up".) Even someone with no security skills at all can tell you there is no vulnerability *in your code* if your code is: int main() {} Similarly, a non-lawyer can tell you there's no vulnerability in a "0-clause" BSD license. The potential for vulnerability is only introduced with complexity. Anyway, this thread has gotten fairly off-topic. Legal theories and the merits of different licenses from legal standpoints are fairly out-of-scope here. The only place license is relevant to the library discussion is when it affects whether or not parties who want to use the functionality of the library are able to use it. Rich