Re: [Tinycc-devel] Do we want a BSD license for tinycc?

[u-tcc-uepj]

Hello Daniel,

On Thu, May 02, 2013 at 01:28:52PM +0200, Daniel Glöckner wrote:
> > From my perspective I'd like to skip the additional worry about which
> > programs can be linked to which libraries and "how".
> 
> if you are a packager, why do you have to worry about that?
> I mean, if you still have the possibility to chose which library to
> link to, most of the time the program is already (L)GPL compatible.

That's the point, I am not happy with something that is true "most of
the time" and thus implies an extra constraint and a need for
using different approaches "sometimes". This is counterproductive.

> And if you always use the shared library, there is never a problem
> with LGPL.

No I do not [want to] always use dynamic linking.

> > I dislike dynamic linking for technical reasons (too much complexity,
> > artificial limitations and side effects, many times for no gain). Then,
> > I dislike licenses which force me to use inferior/inappropriate technical
> > means.
> 
> Can you elaborate on that?

This is almost off-topic but I'll try, concisely.

> Aside from some people not understanding
> how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had
> problems with shared libraries.

I did, more than once.

[BTW SONAMEs are totally useless in a global environment where all
libraries and their different versions/instances (say differing as
little as by optimization flags) do coexist and are to be used
simultaneously, arbitrarily and deterministically.]

> Off the top of my head I remember three
> cases where shared libs were superior:

I do not say dynamic linking is always worse, just that sometimes
it is a PITA.

We do use shared libraries and often they are very useful. Sometimes
it is more efficient to use static linking (instead of workarounds
like creating custom versions of general purpose libraries, to reduce the
totally unnecessary bloat).

On one hand I find it easier to be sure which symbols are resolved from
which library with static linking (may be this is always possible with
dynamic linking too but it looks more complicated and less certain as
it is done later in a possibly different situation). On the other hand
it is often easier to produce "a compact binary" compared to "a compact
filetree with all dependencies of this binary". On the third hand I do
not find it fun to check all the licenses of the concerned libraries
(possibly quite a lot) to know for sure it is ok to link statically -
or to discover that static linking is out of question.

> > BSD license makes the software easier to package / deliver, which
> > can make a big difference in certain cases.
> 
> Btw., how do you at Aetey manage to provide the source code for the
> (L)GPL software you host?

This looks offtopic :) but here you are:

You find the source available by the same means as the binaries,
i.e. in the file trees where the binaries reside. If you can access
the binary, then you can see the source.

Indeed, we save some disk space by not putting these source copies
there for BSD-licensed stuff - even though it is not the benefit I was
looking for :) Actually we try to make as much as possible of useful
stuff available as source, even our own production tools, as I said on
FSCONS last year.

Regards,
Rune