> Well, depending if they've started from 2.0 onwards, then they can of > course combine GPL code - subject to the whole then inheriting the full > GPL terms/obligations. I have to qualify that statement as it is > surprising the number of times that code turns out to have come from > pre-2.0 which was not "full GPL" compatible (and had onerous assignment > terms to a previous copyright holder).
It's 3.0'ish timeframe. > "But I thought eCos was dead". Naaah.... I'm sure patch such as the one below will be committed in no time! ;-) http://sourceware.org/ml/ecos-patches/2009-10/msg00006.html > I expect those in the know may continue to prefer to work directly with > a development repository or certified base, and may even consider an > eCos "tag, tar & compress" minor release bump each Spring & Autumn as a > distraction. However, showing the lights are on to the as-yet > uninitiated is an important part of continuing to build upon eCos' > growth. Actually switching to DVCS here(git/mercurial) is going to be a HUGE boost here. The solution to this just falls out very naturally.... I have yet to work on an eCos project where I didn't fix a handful of bugs in eCos and where unmodified eCos releases(even quarterly ones) would have been non-starters.... I think very highly of the quality of the eCos code, I'm just not a believer in the model where developers don't tinker with the eCos source... -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
