Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi Rune, On Thu, May 02, 2013 at 10:37:58AM +, u-tcc-u...@aetey.se 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. And if you always use the shared library, there is never a problem with LGPL. 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? Aside from some people not understanding how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had problems with shared libraries. Off the top of my head I remember three cases where shared libs were superior: - Libgcc for ARM once had a bug in the division routine. If all applications had linked to the shared library, it would have been enough to replace just a single file. - Libpng has multiple times been updated because a vulnerability had been found in the code. And guess what, Firefox per default links statically to its own copy of libpng, so you have to replace Firefox as well. - I once had to squeeze ISC DHCP into a little NOR flash but each of the applications was linked statically to several ISC libraries and it appeared like no code was discarded during linking. It all magically fit once I persuaded the build process to create and use shared libraries. 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? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Thu, May 02, 2013 at 01:02:19PM +0200, Thomas Preud'homme wrote: Do you know where big-endian is used and by who? There once was a port of Debian for ARM big endian but it never got much traction so it seems to me there is not much interest for such a port anyway. No, I don't think I've seen a big endian ARM running Linux or BSD. But I know that there are TMS570 Cortex-R4 hard wired to big endian. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Le jeudi 2 mai 2013 13:28:52, Daniel Glöckner a écrit : Hi Rune, On Thu, May 02, 2013 at 10:37:58AM +, u-tcc-u...@aetey.se 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. And if you always use the shared library, there is never a problem with LGPL. By the way, you might be interested in reading http://lwn.net/Articles/548216/ 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? Aside from some people not understanding how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had problems with shared libraries. Off the top of my head I remember three cases where shared libs were superior: Nicely summarized here: http://www.akkadia.org/drepper/no_static_linking.html Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi all, Do we really think we can convince one another that static is better then dynamic linking? My brother sent me this few days ago. Little did I know that it is true. :-) Arguing with an engineer is a lot like wrestling in the mud with a pig. After a few hours, you realize that he likes it. I think it is telling that the longest conversation tcc mailing list has seen in a long time is of a 'religious' nature. With the range of opinions and the types of arguments used, it seems to me that it is unlikely a unanimous agreement can be reached. And a unanimous agreement is necessary to change the license (unless we want to throw away some commits). The apparent situations I see is that while for most people BSD license is preferable and would be best choice for a new project, in practical terms switching is not feasible as the reasons are not strong enough to warrant the amount of work necessary, especially considering that tcc is not very active project. My $.02 Miki Jovanovic. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
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 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Thu, May 02, 2013 at 09:22:15AM -0400, Milutin Jovanović wrote: Do we really think we can convince one another that static is better then dynamic linking? That was not my point at all, sorry if it looked that way. the reasons are not strong enough to warrant the amount of work necessary This is the main question, are they or are they not. A license which attracts more users may attract more developers as well. Btw, everyone here - thanks for tcc. I am going silent now. Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
I wrote my email before yours, and example was chosen just to illustrate point. Miki. On 2 May 2013 11:52, u-tcc-u...@aetey.se wrote: On Thu, May 02, 2013 at 09:22:15AM -0400, Milutin Jovanović wrote: Do we really think we can convince one another that static is better then dynamic linking? That was not my point at all, sorry if it looked that way. the reasons are not strong enough to warrant the amount of work necessary This is the main question, are they or are they not. A license which attracts more users may attract more developers as well. Btw, everyone here - thanks for tcc. I am going silent now. Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi, I didn't read all messages in this lengthy thread, but I happened found my name mentioned. I'm OK with the change. Thanks! On Thu, May 2, 2013 at 8:55 AM, Milutin Jovanović jovanovic.milu...@gmail.com wrote: I wrote my email before yours, and example was chosen just to illustrate point. Miki. On 2 May 2013 11:52, u-tcc-u...@aetey.se wrote: On Thu, May 02, 2013 at 09:22:15AM -0400, Milutin Jovanović wrote: Do we really think we can convince one another that static is better then dynamic linking? That was not my point at all, sorry if it looked that way. the reasons are not strong enough to warrant the amount of work necessary This is the main question, are they or are they not. A license which attracts more users may attract more developers as well. Btw, everyone here - thanks for tcc. I am going silent now. Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Date: Wed, 01 May 2013 11:48:29 -0500 From: Rob Landley r...@landley.net To: tinycc-devel@nongnu.org Cc: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Do we want a BSD license for tinycc? Message-ID: 1367426909.18069.201@driftwood Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed I also plan to include an implementation of make, maybe some of the other low hanging posix fruit (lex, m4, maybe a micro-yacc) that I've considered writing a tiny-make before. I might provide some files updated hooks for tup-like functionality, too, and will almost-guaranteed provide a clean implementation flag to disable the obnoxious default behaviors that prevent make from being generic. If I do it, then I'll be posting a mention here. If I do and you want to use it, but the license isn't right, then point me to this and remind me to license it as MIT, BSD, or ZLIB. Date: Thu, 02 May 2013 10:55:42 +0200 From: grischka gris...@gmx.de To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Do we want a BSD license for tinycc? Message-ID: 51822a0e.9090...@gmx.de Content-Type: text/plain; charset=UTF-8; format=flowed Actually the fact that LGPL makes that legal nitpick from static vs. shared is clearly one point against it, for me. What do you think, Daniel? Unless you object we could then proceed with step 2: Is it possible? Well, why not. And then step 3: What would it take? I guess we would first ask all people who have contributed entire files, that is, beyond yourself and myself and Fabrice: Shinichiro Hamaji (x86_64-gen.c) and maybe Frederic Feret (x86_64-asm.c, which I eventually merged into i386-asm.c, which probably means that it wasn't soo different). You actually need to ask everyone that's committed as little as a one-liner that's still in TCC. I'd suggest that if this is taken seriously, that one of the requirements for committing to TCC BECOME that contributions have to be licensed to TCC royalty-free, and freely and infinitely redistributable under whatsoever license terms TCC chooses to redistibute them under. There's probably several better worded versions of that out there, and I'm not a lawyer so I don't know what I might have missed, but I trist my point is conveyed. This might force the mob branch to be moved to a separate project, and only be pulled from after all relevant commit authors agree to have their relevant commits placed under the the terms, but so be it. I'm personally of the opinion that any open project beyond a thousand or so lines of code should probably have such commit licensing requirements so that license (and whatever other) changes remain PRACTICAL over time. For what it's worth, while getting permission from all of those who've produced commits would be involved, I'd think that it would also be worth it's own release, just for paperwork reasons. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
