[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7DA8A203-CFF2-4559-AA2C-7CF38B5DD28E@palsenberg.com>
Date: Fri, 26 Apr 2013 08:11:07 +0200
From: Igmar Palsenberg <igmar@...senberg.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
>>> 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
>> whatsoever (and takes the position that it legally can't do so) so
>> it's fine to use OpenSSL with GPL programs as long as you don't
>> distribute the resulting binary. This is of course a problem for
>> package maintainers/distributions, and distributing both openssl and
>> the GNU program and a script to link them together might even be seen
>> as an infringing activity.
>
> 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 :
- You have a a.so that dynamically links GPL library b.so. Program C loads a.so, and uses it's API, does it need to be GPL ? a.so can alternatively also load d.so instead of b.so, which is BSD licensed.
Using / linking a GPL lib, and making the whole work as such GPL is a clear violation. I personally avoid GPL libs where I can.
>>> pkg-config has a nice replacement in pkgconf. (If a list is
>>> created, might be helpful to list possible replacements already out
>>> there.) Would like to see some of the pieces that are essential parts of
>>> the GNU build system/autotools replaced with some more efficient
>>> [...]
>>> of unnecessary work to port applications. Would rather see the current
>>> build systems already used (autotools, cmake, etc.) streamlined or see drop
>>> in replacements that are better designed.
>> I seem to recall an effort somewhere to do exactly this, but I can't
>> remember where I saw it..
>
> Here too, one option would be to have all of a library's options, dependencies, and build steps represented in a real database (my preference would be PostgreSql), and then have the actual build script(s) generated using command-line utilities. This is something that I have been doing in a rather miniature scale in a few research-related projects, and found to be both effective and expandable. Arguably, for all projects beyond a certain degree of complexity, using a database to manage the build is the most feasible path to follow (no need to name projects that demonstrate what happens if you don't...), yet switching an existing build system to one that is database-driven could become quite a challenge.
I've done nice stuff with SQLIte. Make it also easy to transfer stuff to a different system.
Igmar
Content of type "text/html" skipped
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.
