[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rob Landley
Subject: Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Date: Wed, 01 May 2013 11:48:29 -0500

On 04/30/2013 02:14:58 PM, Marc Andre Tanner wrote:
On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote:
> >... and since I got permission from Fabrice to use his original
> >tcc code under a BSD license ...
> Actually it's a long standing offer from Fabrice, also repeated
> lately on the occasion of the 0.9.26 release.

I don't know about "longstanding offer" but I did ask him about it a year ago:


Specifically I wanted to do a kickstarter to hire _him_ to glue tcc and tcg together, and asked him to name his price. He said he wasn't interested. The "PS" I didn't reproduce in that blog entry was (rummages in email...)

  Message-ID: <address@hidden>
  Date: Mon, 14 May 2012 11:14:23 +0200
  From: Fabrice Bellard <address@hidden>
  To: Rob Landley <address@hidden>
Subject: Re: Contract query: How much to glue tcg to tcc and update tccboot?


  I had the same idea when I was working on TCC and QEMU. The code
  generator of QEMU is not generic enough to do it, but at that time I
  began to modify it to handle the missing bits. Unfortunately it is a
  large project and I lost interest in it. Maybe someday I'll be
  interested again in compilers (perhaps to do a mix between C &
Javascript), but now I have other projects which have a higher priority,
  so I cannot help you now.

Regarding the licensing, I'd like to change the TCC license to BSD since a long time, so I see no problem with that. I would have to look at my
  old repository to see from which version it is safer to start.

  Best regards,


  On 05/11/12 20:55, Rob Landley wrote:
  > Hello Mr. Bellard, I'd like to run a kickstarter to hire you to:
> 1) Adapt qemu's Tiny Code Generator to work as the back-end for your old > Tiny C Compiler, to create a new qcc (QEMU C Compiler) that can produce
  > output for the various targets qemu supports.
> 2) Resurrect tccboot with the result, and get it to boot a current (3.x) > kernel to a shell prompt. (Another "modified subset" is fine, as long as
  > it boots to a shell prompt.)
  > 3) Release the result under a BSD license.
> Does this sound doable? If so, how much would you charge (so I know how > much to ask the kickstarter for), how long do you think it might take > (ballpark), and when might you be available to start (if we can get you
  > the money by then)?
> (I.E. "it would take me a dozen fortnights, cost my weight in canadian > 'toonie' coins, and the next open slot in my schedule is 37 years from
  > now.")
  > --- Optional details:
> My notes on this project, from when I tried to do it myself, are at:
  >    http://landley.net/code/tinycc/qcc/todo.txt
> I can maintain this after it works, I just don't know enough to make it > work in the first place, and have been trying to find time to learn for > years now but keep growing _other_ projects instead (toybox, aboriginal > linux, I accidentally became linux-kernel Documentation maintainer...)
> I have no particular interest in the current "no releases in 3 years" > tcc mob branch, and am just as happy for you to start with your old code > if you prefer. If you want anything out of my old tcc fork, I hereby
  > grant it to you under the same BSD license as tcc/tcg.
  > It doesn't need multilib, being able to build "arm-tcc" and similar
> would be fine, and probably the common case given the need for libc, > libtcc, crtbegin, and so on. (Being able to specify code generation with > the same granularity as qemu's -cpu option would be nice, but not a huge
  > deal in the absence of any real optimization.)
  > Eventually I'd like to "busyboxify" tcc/qcc, I.E. make it so the
  > front-end recognizes whether it's called as cc/cpp/ld/as/strip and
  > reacts accordingly.  But I can handle that part later, and make its
> command line parsing understand more gcc-isms if necessary. I wrote some
  > notes about that years ago here:
  >    http://landley.net/code/tinycc/qcc/commands.txt
  > I don't care about C++.  The missing C99 bits from your old tccboot
  > notes would be really nice, though.
> Simple dead code elimination would be really nice. (Busybox depends on > it to avoid linker calls to undefined functions.) Just detecting if (0)
  > constructs after constant propogation and suppressing output (or
> diverting output to a ram buffer that gets discarded) would be plenty. > But if that sounds out of scope, I could probably tackle that after the
  > fact too...
  > Thanks for your time,
  > Rob

This was the first public statement from him I could find on the matter. (If he mentioned this before then, could you point me at where?)

> So the questions is:  Do you people want, is it possible, what
> would it take - to change our tinycc code's license from LGPL
> to a BSD-like one (such as below).

I am interested in a quality C compiler which is implemented in
C. Therefore gcc and clang which both require C++ aren't an option.

I think Rob's idea of combining Fabrice's BSD licensed Tiny Code
Generator (TCG) with tinycc's frontend is great and could fit the
bill. Unfortunately I currently lack both the time and probably
also the knowledge to work on it myself.

I fully plan to do this thing: after Toybox 1.0 ships.

I also plan to turn it into a multicall binary supporting cpp, cc, as, ld, strip, readelf, objcopy, objdump, and so on. (Remember all that "useless" refactoring that Grishka refused to copy? I was working towards a multicall binary so "ln -s tinycc strip; ./strip filename" could work. Well _I_ thought it was obvious...)

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 doesn't quite fit in toybox, and possibly a very stripped down distcc equivalent since I use that in aboriginal linux and the upstream one doesn't fit my needs very well. (It provides horrible visibility into what it's _doing_, has a tendency to fall back to local builds way too easily which is not good when the objective is to move work outside the emulator to the cross compiler, I would much rather it call "cpp" instead of "gcc -E" so I can provide a faster tinycc based preprocessor and not have to repeatedly go through gcc startup in the emulator each time I want to preprocess a file...)

My goal for qcc is to get the smallest self-hosting Linux system capable of rebuilding itself _and_ building linux from scratch under the result down to four packages:

  linux, qcc, toybox, musl-libc.

I have extensive plans, which I'm not working on right now because Toybox needs a 1.0 release first, for reasons described in my talk at the Embedded Linux Conference in February:


That project is time-critical (for reasons described in the talk). QCC is _not_ time critical because LLVM is actively working to build a Linux kernel, so making Android self-hosting can be done with LLVM and overlaid with qcc later:


This legacy tcc project is _not_ working to build a Linux kernel. It's not working to build anything specific. The whole run-up to your recent release never had a single bug report about any existing package not building, because building existing packages with tinycc is not what you guys try to do with it. Even though tccboot was almost a decade ago, this project has not even expressed _interest_ in reproducing it. All it managed to do was overshadow my own efforts (through sheer seniority) until I gave up and went off to do other things.

A very important part of my planned qcc is that it has a distinct identity so I don't have to _care_ what this zombie project does. It can be more than a footnote in the wikipedia page of some _other_ project, I shouldn't get endless bug reports from users of the _other_ version about things I fixed a year and a half earlier in mine, watch Linux Weekly News cover the other thing's releases but not mine, and so on.

I only piped up at the start of this thread because "I don't have an arm test environment" was something _else_ I fixed years ago. (And mips, and sparc, and powerpc, and vaguely working on adding more targets but it's low priority.)

Independent of that I think a BSD licensed tinycc would probably
get more people interested.

This project has been stagnant for most of a decade, without even mustering the ambition to recreate tccboot from NINE YEARS AGO. At this point you're as likely to get people enthused about it as the pcc relaunch, and that's pretty much ground to a halt:


You don't attract new developers to a project and _then_ it becomes interesting. The way you make an interesting project is for some existing developer to do interesting work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]