[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Apr 2013 16:47:31 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Licensing.
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
