Slashdot Mirror

The people who make RTEMS, Online Applications Research Corporation are a very cool bunch who were early adopters in the real time operating system space. They have worked very closely with RMS on licensing in the mid 90's and were one of the first groups using GCC as a cross compiler. Their business model is support oriented plus government contracts.

(I have no financial stake in OAR or RTEMS, other than having good feelings about their involvement in OSS)

I would like to know what pieces of open source software you use, either personally or professionally, that you or your company have "funded".

Sure - RTEMS. It's an RTOS that my very-large-but-not-to-be-named company uses for one of our hardware products. We buy support from the vendor, contribute patches if we find a bug, etc. It's actually a pretty good deal for us. We don't want to have to write the OS ourselves, but at the same time we need access to the source if we need to make a change...

-jerdenn

RTEMS is maintained by Online Applications Research Corp. You can find more info at OARCorp or RTEMS.com. The first incarnation was Real-Time Executive for Missile Systems, then Real-Time Executive for Military Systems. That second name still applies to the Ada implementation, but the C implementation now goes by Real-Time Executive for Multiprocessor Systems. The current license is basically LGPL. -- Chris Caudle

RTEMS (see http://www.oarcorp.com/RTEMS is an embedded RTOS that uses this approach. We got the idea from other "run-time" libraries in the GNU software suite. This is very similar to the exception used by the GNAT (GNU Ada) run-time. I believe there should be a special version of the GPL called something like the "Run-Time GPL" to address cases like this. There is no point in every project writing their own exception paragraph and possibly creating loopholes.

The specific paragraph we add to the GPL is:

"As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."

Be aware that if your software is useable in non-embedded systems, you might want a more
pure version of the GPL. Someone mentioned allowing the exception on systems without dynamic linking.

We have tried very hard over the past 10 years to walk a fine line between being free software for embedded systems and placing undue restrictions on those using our software. It is a tough balancing act but we like this solution. Making your own strange license requires that you explain it which is no fun either. :)

Actually, I work on a team that is using Open Source (modified GPL) software for our RTOS that does run in a Hospital Point of Care device. The company that manufactures this device is a very big player in this market.

I think there were several concerns about going with Linux as our embedded OS - We were looking for something more along the lines of an RTOS, with guaranteed task handling. There were also concerns about having to GPL our software. While we don't mind giving back to the community any OS changes we make, our application code is what gives us a competitive advantage, and publishing it just doesn't make good business sense.

You've also mentioned that businesses wouldn't want to purchase Open Source software because there is no accountability. Actually, for the our project, we get the best of both worlds. OAR Corp provides support for the RTOS, and we get to look directly at their work, instead of getting a "black box" binary solution. Works very nicely. And we can make any changes we need directly. Very cool.

So, yes, companies are starting to use Open Source in places that you may never hear of, or realize.

-jerdenn

Actually, I work on a team that is using Open Source (modified GPL) software for our RTOS that does run in a Hospital Point of Care device. The company that manufactures this device is a very big player in this market.

I think there were several concerns about going with Linux as our embedded OS - We were looking for something more along the lines of an RTOS, with guaranteed task handling. There were also concerns about having to GPL our software. While we don't mind giving back to the community any OS changes we make, our application code is what gives us a competitive advantage, and publishing it just doesn't make good business sense.

You've also mentioned that businesses wouldn't want to purchase Open Source software because there is no accountability. Actually, for the our project, we get the best of both worlds. OAR Corp provides support for the RTOS, and we get to look directly at their work, instead of getting a "black box" binary solution. Works very nicely. And we can make any changes we need directly. Very cool.

So, yes, companies are starting to use Open Source in places that you may never hear of, or realize.

-jerdenn

Mundie and MSoft have directed the public discussions pretty effectively, they just keep poking at that fanatical GPL nerve; impressive that they've made the GPL the absolute center of discussion, equating GPL and open source. Controversy of the GPL makes it a weak point for open source, by equating the two Mundie/MSoft have assigned to open source all of the restrictions of GPL.

As long as we're stuck on GPL, at least mention some of its variants -- LGPL, special-case GPLs, whatever.

Somebody help me out here, try to think of a commercial product using maybe RTEMS and Microwindows/Nano-X and the GNU MultiPrecision library? Or some other not-necessarily GPL combination of open source libraries that doesn't require derivative software to be all open-source?

A commercial product can use software libraries like these; the developers of such a product comply with the library licenses by publishing changes to the libraries, etc., so forth, to contribute to open source. But the commercial product remains proprietary.

Could do some effective MundieBashing, saying "RTEMS Nano-X GMP LGPL proprietary derivative software," proving the man wrong and derailing his agenda by focusing on open source strengths.

There are a number of other free/open source RTOSes for the embedded community. RTEMS (http://www.oarcorp.com/RTEMS) is probably the oldest of these. Other alternatives include eCos (http://sources.redhat.com/ecos) and uCOS (no URL handy).

Disclaimer: I am one of the original authors and current maintainer of RTEMS. :)

and it's really quite simple. Ignoring Linux completely, there are a LOT of really really good RTOS and non real time embedded OSes out there. For free. And they are already mature.

Take OAR's RTEMS for example. It's small. It's quick. It has an IP stack. It runs on everything. It supports Ada. It supports multiple procs of different types. It's been around a long time.

CE has only 1 "feature" to make it stand out from the pack (IMHO) and that's the fact that the API tracks another non-RT os. Big deal. I don't think this has been enough to really launch it into it's target market yet.

I mean, good grief, look at the number of COMMERCIAL real time OSes out on the market right now that have been around for longer than CE. They picked a super competitive market, no wonder they are worried.

speaking of embedded ... back to work. argh.
dv

Unlike Linux advocates, FreeBSD advocates do not believe FreeBSD should be running on every microchip.

I don't really want to shoot holes in the article but a large chunk of FreeBSD does run on a large number of embedded systems... RTEMS 4.0, the Open Source real time operating system, uses the FreeBSD networking infrastructure and TCP/IP stack. This runs in very little memory(for a full TCP/IP stack) on a wide range of 32 and 64bit microcontrollers (e.g. x86, 680x0, 683xx, ColdFire, i960, sh, MIPS, ppc, sparc)

The reason we chose the stack was because of the FreeBSD licencing which matched the GPL+exception licence that RTEMS uses. That and the speed and efficiency of the stack which is important for many applications.

More info on RTEMS can be found at OARCorp's web page.