Slashdot Mirror

Earlier this month you asked Harald about VIA's open source strategy and his work with gpl-violations.org. Here are his well-thought-out, informative answers. 1) More interesting mobile developments? -- by radimvice
Your Wikipedia bio mentions that you left your position as Lead System Architect for the OpenMoko project in 2007 due to "internal friction and demotivation". What are your current thoughts on the OpenMoko platform, has it made significant improvements since your decision? What are the biggest hurdles it still needs to overcome before you would consider it a successful project? Are there any other upcoming mobile platforms that have you excited for the future of open source development on mobile phones, or is the industry/market perhaps still too premature for open-architecture Linux on the cell phone?

Harald:
Openmoko has made quite a number of improvements but at the same time has many internal problems to resolve. Only few of those are technical, and the least of them are software related.

The biggest hurdle I see is the creation of more competitive hardware, both from mechanical design as well as providing 3G / 3.5G cellular connectivity.

I am not too excited about other mobile platforms, since though some of them are Linux based, everyone expects them to be locked-down with signed bootloader/kernel images which completely circumvents the freedom to modify the code and run modified versions of it.

And yes, the traditional carrier-driven market is much too premature and stuck in their monopolistic and proprietary structures. But if they don't change at some point, I think the number of GSM phones sold independent of carriers will rise again. The subsidized-phone-sold-by-carrier-bundled-with-simcard model is extremely against an open market, fair competition and equal opportunities.

2) What's the situation with VIA drivers for Linux -- by glop
A friend just got a Wibrain b1 that came with Ubuntu. The drivers for all the VIA stuff are binary blobs which prevents him from upgrading the kernel. They also don't seem very reliable as he is seeing crashes.

Is there already Open Source drivers for that kind of hardware or is this part of your mission for VIA?

Harald:
I do not understand why there are any binary-only kernel drivers involved.

To the best of my knowledge, VIA does not have any binary-only drivers, and particularly not graphics related. The agpgart and DRI/DRM drivers are all GPL licensed open source. The chipset used in the Wibrain device is a unichrome based chipset, and those drivers are all part of the mainline kernel.

There are some other more recent VIA integrated graphics chipsets utilizing the Chrome9 graphics core. The DRI/DRM driver is not yet integrated into the mainline kernel, but it is available as GPL licensed source code from http://linux.via.com.tw/

Binary-only userspace drivers (like the 3D and TVout enabled Xorg driver as released by VIA) do not impose any restrictions on kernel updates, since the kernel ABI towards userspace is fixed.

3) v2 or v3 -- by larry bagina
Do you prefer the GPL version 2 or version 3?

Harald:
It's a hard question. I personally prefer GPLv2, but not for much rational reasons. Rather it's "the thing that I'm used to" and "the license that I've managed to enforce successfully". So it's like a proven, reliable and trustworthy legal tool.

On the other hand, v2 has some shortcomings. I like the fact that GPLv3 makes it explicit that you cannot use cryptographically signed code to circumvent the "freedom to run modified versions". In GPLv2 you can only argue for this by doing a license interpretation - i.e. not something that will have a certain outcome in court. If v2 was more explicit in this regard, we would not have seen the tivo-ization of products suhc as the Motorola Linux based phones on which you cannot change a single line of code. It is _sooooo_ much against the purpose, intention and spirit of the license. It hurts.

What I prefer about v2 is that there is a more explicit 'automatic termination' clause and no implicit way how an infringing entity can 'heal' their infringement within a certain deadline. The v3 part about this is creating an entirely new set of complexity for license enforcement which I believe is unjustified.

So for any new code that I write I usually put it under 'v3 only', unless it is a contribution to an existing v2-only project like the Linux kernel, or unless there are contractual obligations requiring the code to be v2-only.

I personally don't believe in the 'version X or any later version' idea, since I have a hard time to preemptively agree to something that neither I nor anyone else has ever seen.

4) VIA and Netbooks -- by Van Cutter Romney
My recent brush with VIA is when I bought a HP mini-note laptop which uses the VIA C7 processor. Unfortunately, I ended up picking the laptop with Windows Vista and I'm sorry to say that it is not the right operating system for this category of portable laptops. I am much more happier with Ubuntu loaded on the machine now.

My question to Mr. Welte is, how is VIA working with vendors like HP to promote Linux on this new and exciting range of netbooks that coming out?

Harald:
First of all: I can understand your pain, as I have bought the same vista-based HP mininote in order to illustrate the problems with VIA's old binary-driver strategy on Linux. Right now it is just impossible to install any mainline distribution on that system (or similar systems employing VIA's recent products), even if you're a very experienced Linux user, sysadmin or developer.

To the best of my knowledge, VIA is not promoting the use of any Operating System to their system integrators. It's rather the other way around, i.e. the system integrators / notebook manufacturers who want to create a Linux-based product ask or rather demand good Linux support from chip manufacturers like VIA.

5) Have you ever accused an innocent? -- by BitterOldGUy
From your Bio you started gpl-violations.org.

Have you ever accused anyone of violating the GPL and then found out that they didn't?

Harald:
No. The way we work at gpl-violations.org is to first do a test purchase and obtain evidence of the copyrigt (and GPL) violation. After that, we send a legal warning notice demanding the infringing entity to cease and desist from their doing.

6) 3D Support? More support than Unichrome series? -- by Svartalf
It's my understanding that VIA has recently provided a dump of new "cleaner" code to x.org that supports the Unichrome lineup more properly. (By the way, thanks...)

However, this doesn't help fully in the big-picture sense of things.

Right now, an Atom based netbook will have 3D capable of doing Compiz (I know, I've played with it on at least two differing eeePC models right now...) and some lower-end FOSS 3D games out of the box. With what has been given out so far, you still can't do this with VIA's offerings, which include the netbook designs and the EPIA boards. That, alone, isn't a good thing or selling point, really, for those designs right now. What is VIA planning to do in regards to fixing the 3D situation on the stuff that you have already released stuff for?

The aforementioned only talks to Unichrome/Unichrome Pro/Unichrome II. What's the story with the other Chrome lineup? Are we going to see FOSS support for those chips or are they even relevant going forward?

Harald:
I am sorry to say that there is no quick solution for FOSS support of Chrome9 products. It is one of the hottest topics of my work inside VIA, and everyone is trying their best to find a solution. I cannot disclose any details for the reasons for this difficulty, but any possible solution is likely going to take quite a significant amount of time.

For 3D FOSS support (Xorg/DRI/DRM/Mesa driver) for unichrome / unichrome pro the situation is much better and we will see that code disclosed at some not too distant point in the future.

Just think of what ATI has been going through some time ago. They were unable to release the source for their existing binary-only driver and had to start a new driver, which needs time.

7) S3 & Via -- by bill_mcgonigle
Can you illuminate the relationship between S3 and Via for us? I've tried in the past getting basic technical specs (e.g. textures per pass, triangle rates, pps, fill rates) on the video hardware that comes with Via boards. This kind of information is readily available from other manufacturers, and occasionally a whitepaper will show up from Via or S3 for a random chipset, but asking Via for this kind of information results in stacks of legal forms to be signed in duplicate, allegedly because of NDA's between Via and S3. Yet, S3 bills itself as "a VIA Technologies, Inc. joint venture company". Doing open source work, I've avoided the NDA entanglements, and ultimately went to ATI for video hardware because I could find specs reliably without 'buying one of each' (this was actually suggested to me). Mostly it's all very confusing for people who just want to develop stuff, and I wonder how this relationship affects the open source drivers and the stuff that's not currently available (3D, hardware media decoding) but is essential for some embedded work.

The related question would be does Via realize that we're out here and want to buy their hardware but are being forced to rule out Via due to secretiveness?

Harald:
I have just started working for VIA, so I am not as familiar with all of the corporate details, as you can imagine.

However, S3 Graphics is an entirely independent company and not a subsidiary of VIA. That basically means that VIA is holding some stock, but that's more or less all. They also promote their products together.

The S3 Graphics discrete GPU's are developed independently from the VIA integrated graphics, and they share no common hardware core or driver.

So since VIA has taken steps to become more supportive of Open Source and particularly Linux and Xorg, we will see improvement for the VIA integrated graphics products. This has no relationship to what S3 does for their products.

And I totally agree with your statement of VIAs [past] secretiveness and lack of open documentation and open source drivers is definitely hurting their ability to sell to the Linux based market, including the Linux based embedded market.

This is precisely why VIA is changing now, and has hired me as part of that process. Some of those changes are visible now, other changes will only be visible with future products. There is always a lead time involved in any R&D...

8) IP and moving forward with open-sourcing by TheModelEskimo
How much did IP (intellectual property) concerns weigh on the process of opening the driver code? We've been hearing from companies like nVidia that IP issues prevent them from opening their own code, so I'd be interested to hear just how it is that VIA were able to get to this point in the face of today's treacherous environment regarding IP.

Harald:
First of all, I dislike the use of 'IP', since it confuses trademarks, patents, copyright and other rights.

Yes, 3D graphics and video codecs are a minefield of patents. Those patents and the way their licensing works cause significant trouble and present legal risks for anyone involved with them.

So even if you assume the best case and assume that you can manage to build an open source solution that's still in compliance with the patent licenses, you will have to waste a lot of time on carefully analyzing the legal situation and possibly spend just as much time on it as on writing code.

This is why less contentious code like 2D drivers can usually be disclosed fairly quickly, and others cause quite a lot of headache :(

As far as copyright is concerned, to the best of my knowledge VIA wrote all parts of their drivers themselves and did not license parts of it from any other entity. This means they are the sole copyright holder and can therefore decide on whether to relicense existing code under a FOSS license.

9) Drivers Drivers Drivers (Score:5, Insightful by dan the person
VIA has a history of releasing chipsets packed full of great video acceleration, but no drivers to make use of that acceleration, sometimes there are even no windows drivers either.

Looking at the linux drivers for instance[1], there are big gaps, and it is disappointing to see no drivers to support the base MPEG4 acceleration let alone new features such as h.264 acceleration.

I have an EPIA SP8000E and the MPEG2 acceleration (XvMC) implemented by the openchrome drivers is awesome, such a shame more than that cannot be supported.

VIA has once again re-launched their linux drivers[2], and once again the support is very limited, only a small number of distributions, a small number of chipsets, and a small number of hardware features supported. Furthermore applications that can make use of these drivers features are almost non-existent

Wouldn't it be better to work with the the established driver teams such as openchrome, who have broad distribution support, broad chipset support, and are broadly supported by applications, to add the missing hardware support?

[1]http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=HardwareCaveats
[2]http://linux.via.com.tw

Harald:
The problem with hardware accelerated video playback is that the company creating a 'consumer product' sold to an 'end user' has to pay the royalties to the MPEG-LA.

So any chip maker like VIA is not required to pay the patent licensing royalties since they just produce an 'intermediate product' which somebody else can turn into a 'consumer product'.

This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator, who then sells a bundle of software and hardware to an end user. In that case the system integrator either pays the royalties and can sell that product, or doesn't pay the royalties and can just sell the hardware without the proprietary software drivers and programs to actually make use of those hardware features.

Now imagine the open source situation for this. If VIA was suddenly selling chips as intermediate products, but also disclosing free player software to make use of that acceleration features? Would that then be a 'consumer product'? Who knows. But it would definitely be distributed to an 'end user' since it's available to anyone who wants to download it.

So if any independent free software or proprietary software program implements those codec acceleration features, they might violate the patents on those video codecs. Just in the same way mplayer, xine and other FOSS programs do not pay the per-installation/copy/download royalties for MPEG2/H.264/... playback products. Maybe you can call a sourcecode implementation just a 'reference implementation for scientific purpose', but that's open to legal interpretation and as far as I know there is no precedent in this area. But it is their decision on what legal risk they take.

It's the very same reason why distirbutions generally refrain from shipping that player software. Because there is significant indication that they would have to pay per-unit royalties. And with free software, you never know how many units there are, so you don't even know how much to pay - and you also have no revenue from things that you don't sell...

10) GPL Violations by PingXao
You have stated that your ability to pursue claims against those who violate the GPL is hampered by lack of resources. What amount and type of resources, in your estimate, would be required to pursue all such claims? I'm thinking in terms of everything from vetting the claims to see if they're warranted all the way through the hiring of legal representation to file and pursue lawsuits against the violators.

Harald:
The limited resources basically come down to a lack of 'trustworthy time' for actually doing technical analysis of an alleged infringement. Since I am in the end the person who is personally liable with everything I own, I have to trust such an analysis.

And in order to have that trust, I usually have to do it on my own. Over recent years, my 'second-in-command' at gpl-violations.org (Armijn Hemel) has started to do this kind of work and I trust him to be able to do it correctly.

However, if such a person makes a mistake, and I obtained a preliminary injunction banning a company from sales of their products which later gets overruled since there actually was no [sufficient] evidence for copyright infringement, then I'm liable for the loss of revenue to that company. Now if you think of the kind of consumer products and the quantities that they are sold, you can quickly imagine that it is prohibitive to get into that position.

There is no shortage on finding qualified legal representation to handle all those cases. Though at some point there is an issue where my personal liability is multiplied by the number of cases that run in parallel.

One way to address this problem is to over time get more engineers involved who can earn that level of trust. But it will likely take quite a lot of time to get there (possibly years). The other point is to incorporate the project to get myself out of the personal liability. We have some plans for that, but their implementation is again hampered by the limited amount of time that I can spend on the project.

I'm involved in way too many projects, and all of them are suffering desparately to get some more time and love by me. But I'm constantly thrashed and just only have a limited number of timeslices available. OpenPCD and librfid are the prime candidates for urgent need of time. The u-boot s3c24xx code and mainline submission of all the Linux kernel code that I wrote for Openmoko are other really important tasks that need to get done soon. Some other projects like ulogd and OpenEZX have managed to attract enough interest and involvement from other people so I have to worry less about them.

So that's why gpl-violations.org can only deal with a few cases. At the moment, we are doing up to 10 cases in parallel, and I expect we will probably get to something like 50-75 cases per year. But more would be too much.

-- Harald Welte http://laforge.gnumonks.org/