Martin Michlmayr
Martin Michlmayr

I'm a member of Debian and serve on the boards of Software Freedom Conservancy and Software in the Public Interest.

Subscribe to the RSS feed of this blog.

Debian on Jetson TX1

Debian is now working on the NVIDIA Jetson TX1 developer kit, a development board based on the Tegra X1 chip (Tegra 210), a 64-bit ARM chip.

We have a pre-built u-boot image in Debian as well as kernel and installer support. There are some minor kernel glitches but NVIDIA is very active upstream and I hope they'll get resolved soon.

The Jetson TX1 developer kit makes a pretty good 64-bit ARM development platform. The board is supported in mainline u-boot and the mainline kernel and NVIDIA are pretty responsive to bug reports. Unfortunately, a proprietary blob is required for USB (and Ethernet is connected via USB).

If you're interested in a good 64-bit ARM development platform, give Debian on the Jetson TX1 development kit a try.

2017-01-26 22:51:25 +0100 — debian/tegrapermanent link

Debian on Jetson TK1

Debian on Jetson TK1

I became interested in running Debian on NVIDIA's Tegra platform recently. NVIDIA is doing a great job getting support for Tegra upstream (u-boot, kernel, X.org and other projects). As part of ensuring good Debian support for Tegra, I wanted to install Debian on a Jetson TK1, a development board from NVIDIA based on the Tegra K1 chip (Tegra 124), a 32-bit ARM chip.

Ian Campbell enabled u-boot and Linux kernel support and added support in the installer for this device about a year ago. I updated some kernel options since there has been a lot of progress upstream in the meantime, performed a lot of tests and documented the installation process on the Debian wiki. Wookey made substantial improvements to the wiki as well.

If you're interested in a good 32-bit ARM development platform, give Debian on the Jetson TK1 a try.

There's also a 64-bit board. More on that later...

2016-07-25 03:31:28 +0200 — debian/tegrapermanent link

Debian on Seagate Personal Cloud and Seagate NAS

The majority of NAS devices supported in Debian are based on Marvell's Kirkwood platform. This platform is quite dated now and can only run Debian's armel port.

Debian now supports the Seagate Personal Cloud and Seagate NAS devices. They are based on Marvell's Armada 370, a platform which can run Debian's armhf port. Unfortunately, even the Armada 370 is a bit dated now, so I would not recommend these devices for new purchases. If you have one already, however, you now have the option to run native Debian.

There are some features I like about the Seagate NAS devices:

If you have a Seagate Personal Cloud and Seagate NAS, you can follow the instructions on the Debian wiki.

If Seagate releases more NAS devices on Marvell's Armada platform, I intend to add Debian support.

2016-07-22 04:50:27 +0200 — debian/marvellpermanent link

QNAP TS-x09 installer available again

Debian 8.3 came out today. As part of this update, Debian installer images for QNAP TS-109, TS-209 and TS-409 are available again. These devices are pretty old but there are still some users. We dropped installer support several years ago because the installer ramdisk was too large to fit in flash. Since then, users had to install Debian 6.0 (squeeze) and upgrade from there. When squeeze was removed from the Debian mirrors recently, I received mail from a number of users.

I investigated a bit and found out that we can bring back the installer thanks to XZ compression and some other changes. The installer is available for jessie and stretch.

2016-01-24 03:30:27 +0100 — debian/orion/qnappermanent link

Lessons learned from Munich's migration to Linux

I attended LinuxTag in Berlin last week and there was a very interesting presentation about the state of Munich's migration to Linux on the desktop. Andreas Heinrich explained that their goal is to migrate 80% of the 15000 desktops to Linux. At the moment, 6200 desktops have been migrated and they intend to have a total of 8500 Linux desktops by the end of the year.

Here are some of the key lessons they shared with the audience:

It seems that the city of Munich has learned a lot from their Linux migration. We can hope that other Linux migrations will make use of the lessons learned by the folks in Munich.

2011-05-19 16:15:09 +0200 — fossbazaarpermanent link

Open Source Contributor Agreements: Some Examples

The first part of this article explained the purpose and scope of Contributor Agreements in open source projects. This article presents an overview of some Contributor Agreements that are used in the community.

Contributor Agreements come in all shape and forms, ranging from full-fledged Contributor License Agreements (CLA) that have to be signed to informal consent to some set of rules. This article will take a look at a number of different agreements in order to show that community norms can vary widely.

Apache's Individual Contributor License Agreement

The Apache Software Foundation (ASF) maintains two formal Contributor License Agreements (CLA), one for individual contributors and one for corporate contributions. The Individual CLA covers the following points:

Fedora Project Contributor Agreement

Fedora is in the process of adopting the Fedora Project Contributor Agreement (FPCA), which covers the following points:

The Fedora Project Contributor Agreement does not require contributors to assign copyright to Fedora or Red Hat.

Linux kernel Developer's Certificate of Origin

The Linux kernel project has adopted the Developer's Certificate of Origin. Developers use it to assert the following points:

The way by which developers accept the Developer's Certificate of Origin for each contribution is to put a Signed-off-by line with their name between the description of their change and the actual change.

Debian's Social Contract

While Debian has no formal Contributor Agreement per se, all contributors who become official members of the project have to accept Debian's Social Contract for their Debian related activities. Among other things, the Social Contract states that "Debian will remain 100% free" (free according to the Debian Free Software Guidelines). Therefore, it can be implied that all contributions to Debian made by members of the project are open source. The license of contributions without explicit license statements is not clear since Debian does not define a default license like Fedora. However, Debian developers are encouraged to specify the copyright and license information for their submissions in the debian/copyright file of their software packages.

2010-08-18 17:10:16 +0200 — fossbazaarpermanent link

Open Source Contributor Agreements: Purpose and Scope

Contributor Agreements, also known as Contributor License Agreements (CLA), are increasingly being adopted by open source projects. This article explains the purpose of these Contributor Agreements.

When a contribution is made to an open source project, there is an implicit assumption (and sometimes explicit consent) that the contribution (code, translation, artwork, etc) may be incorporated into the project and distributed under the license the project is using. However, many conditions of the contribution are not explicitly called out. The purpose of Contributor Agreements is to make the terms under which contributions are made explicit, thereby protecting the project, the users of the software and often also the contributors.

Apache Software Foundation (ASF) describes the aim of their CLA in this way: "The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to the ASF and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time." Contributor Agreements also ensure that contributions cannot be withdrawn by the contributor, as the FAQ for the Django CLA explains: "The CLA also ensures that once you have provided a contribution, you cannot try to withdraw permission for its use at a later date. People and companies can therefore use Django, confident that they will not be asked to stop using pieces of the code at a later date."

Contributor Agreements therefore provide confidence that there likely won't be any legal issues in the future regarding the individual contributions that make up the project, such as disputes over origin and ownership. A downside of Contributor Agreements is that they pose a small overhead and barrier to contribution. This can particularly be a problem for minor contributors who may feel that getting their fixes accepted is not worth the hassle of filling out a Contributor Agreement.

Which points do Contributor Agreements generally cover? There is a lot of variation among Contributor Agreements but the following areas are often covered:

I'll give an overview of some Contributor Agreements in a future article.

2010-08-06 14:34:23 +0200 — fossbazaarpermanent link

Resources for Open Source Compliance

Open source is everywhere today and there is growing awareness that companies have to meet certain obligations when distributing open source software. Here are some useful resources to learn more about open source compliance.

2010-07-20 14:57:16 +0200 — fossbazaarpermanent link

Open source compliance: know your obligations

One key element of open source compliance is to know your obligations. There is a lot of confusion about what open source means exactly and some people believe that open source means you can do whatever you want. While open source grants users many freedoms, open source code comes under specific license terms which often include obligations that have to be followed by companies distributing open source software.

Because of recent lawsuits by the Software Freedom Law Center on behalf of the busybox project and the activities of the GPL-Violations project, awareness is growing that copyleft licenses such as the GPL come with obligations. For example, the GPL requires source code to be offered to those who receive binaries. The AGPL goes a step further and additionally requires that the source code be made available to users who interact with the software over the network.

But what about so called permissive licenses, such as BSD and MIT? Some people say that those licenses allow you to do anything, including putting the code into proprietary applications. And while you can do that, there are still obligations that have to be met. For example, the BSD class of licenses has this condition:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

If you want to distribute software that is under a BSD license, that's a condition you have to follow. The MIT license also has a very similar clause. That's the reason why you can often find license information in the "about" window of commercial applications or PDFs on CDs that come with hardware products.

The bottom line is simple: know your obligations!

2010-07-07 15:30:18 +0200 — fossbazaarpermanent link

Project management lessons from the FreeDOS Project

A lot of people seem to think that open source is a magic solution to project management and that open source projects will automatically attract a large and healthy community of contributors and users who will improve the software. This, of course, is not the case. In fact, creating a successful open source project is a really major and difficult effort. You have to deliver an initial promise that people find interesting, attract other people, then facilitate and lead the community, etc. You just have to look at all the failed projects on SourceForge that never delivered any code to see that "open source" is not a guarantee for success.

Even though project management is a key element of every open source project, there are only few resources about this topic. That's why I always enjoy reading about the experience from open source project leaders. Jim Hall, the founder of the FreeDOS project, recently posted a series of four articles which I find particularly interesting.

Here are links to the articles along with a quick summary:

I really like these articles from Jim Hall since they contain a lot of great insights that apply to other projects, so I suggest you check them out!

(Originally published on FOSSBazaar)

2009-11-10 18:12:18 +0100 — fossbazaarpermanent link

You can find older blog articles in my blog archive.