Language Selection

English French German Italian Portuguese Spanish

Should You Release Your Code as Open Source?

Filed under
OSS

The first thing to keep in mind is that open source does not mean "free." You can open source your software without giving it away for free; how you do so depends on the license you choose, which I'll discuss in the section "Common Issues" later in this article.

Open source simply means that if the person can get the software (whether free download or buying it), they can also get the source code to work with in-house at minimum, which allows them to extend the product for their own use. Such a license also allowed them to examine the code for debugging purposes, whether for a problem with your software, or interaction between yours and theirs. Benefits include receiving detailed bug reports from your clients' programmers, and even potential bug fixes. Even better, you can often charge more for the option to receive the source code.

However, you may in fact decide to give the software away for free.

Full Story.

More in Tux Machines

Graphics: Mesa and More

Red Hat Leftovers

Kernel: CH341 and LWN Articles (Just Freed)

  • Linux Adds CH341 GPIO
    There was a time when USB to serial hardware meant one company: FTDI. But today there are quite a few to choose from and one of the most common ones is the WCH CH341. There’s been support for these chips in Linux for a while, but only for use as a communication port. The device actually has RS232, I2C, SPI, and 8 general purpose I/O (GPIO) pins. [ZooBaB] took an out-of-tree driver that exposes the GPIO, and got it working with some frightening-looking CH341 boards.
  • Shrinking the kernel with an axe
    This is the third article of a series discussing various methods of reducing the size of the Linux kernel to make it suitable for small environments. The first article provided a short rationale for this topic, and covered link-time garbage collection. The second article covered link-time optimization (LTO) and compared its results to link-time garbage collection. In this article we'll explore ways to make LTO more effective at optimizing kernel code away, as well as more assertive strategies to achieve our goal.
  • The rest of the 4.16 merge window
    At the close of the 4.16 merge window, 11,746 non-merge changesets had been merged; that is 5,000 since last week's summary. This merge window is thus a busy one, though not out of line with its predecessors — 4.14 had 11,500 changesets during its merge window, while 4.15 had 12,599. Quite a bit of that work is of the boring internal variety; over 600 of those changesets were device-tree updates, for example. But there was still a fair amount of interesting work merged in the second half of the 4.16 merge window; read on for the highlights.

Wine-Staging and Games