Slashdot Log In
Answers from Harald Welte, "VIA's Open Source Representative"
Posted by
Roblimo
on Tue Sep 16, 2008 12:00 PM
from the taking-time-out-from-his-unbelievably-hectic-schedule dept.
from the taking-time-out-from-his-unbelievably-hectic-schedule dept.
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/
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/
Related Stories
[+]
Ask Harald Welte, "VIA's open source representative" 56 comments
In this recent Slashdot post kernel hacker Harald Welte was characterized as "VIA's open source representative," but that is just one of many irons he has in the fire, as a glance at his Wikipedia bio will show. You can obviously ask Harald about many interesting things besides VIA's open source strategy — and before you ask about VIA, you ought to read the last few entries on his blog, at least one of which mentions VIA questions he can't answer. But VIA aside, there's plenty to ask Harald about. For example, he won an award from the FSF earlier this year for his work on gpl-violations.org. In any case, Harald is a powerful force for GNU/Linux and Free Software, and we appreciate him taking time out of his undoubtedly hectic schedule to answer your questions. (Usual Slashdot interview rules apply.)
[+]
Mobile: Open Source GSM Network At Dutch Hacker Convention 141 comments
solevita writes "Harald Welte, who's been interviewed previously by Slashdot, has written on his blog about operating an Open Source GSM network at the recent HAR2009 conference. Photographs and a description of the setup, run under license of the Dutch regulatory authority, are provided; essentially the setup consisted of a pair of BTS' (Base Transceiver Stations) running at 100mW transmit power each and tied to a tree. In turn these provided access to the Base Station Controller (BSC), in this case a Linux server in a tent running OpenBSC. The system authenticated users with a token sent via SMS; in total 391 users subscribed to the service and were able to use their phones as if they were on any other network. Independent researchers are increasingly examining GSM networks and equipment, Welte's work proves that GSM is in the realm of the hackers now and that this realm of mobile networking could be set for a few surprises in the future."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Via Set Top Boxes (Score:3, Interesting)
I find it interesting how the lack of open source and "freedom" of their drivers becomes detrimental. In a project I just worked on, we would have deployed thousands of their set top boxes if drivers weren't an issue.
Can't sign the NDA? (Score:3, Informative)
If I understood the article correctly, VIA pays no royalties on patents covering their chipsets, as they are seen only as intermediate products. The onus in on the manufacturer that makes the final product to take care of those. In this case your company would be the manufacturer that markets to the public. By signing an NDA with VIA, a reference implementation could be had, so there would be some sort of driver support. If the conditions of the NDA allow for the driver to be open sourced subsequently and w
Re: (Score:2)
I think the GP poster was referring to a design miss/fail on VIA's part.
Without credible driver support (which they still don't have...) they don't get to have their foot in the door on a lot of designs. I suspect that the GP poster was referring to the fact that his company chose something else instead of an EPIA or similar design for set-top boxes because they don't have the right stuff with regards to Linux.
I wish I asked this differently... (Score:5, Interesting)
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.
I really wish I asked, "If the the entity you accused denied it at first and then "fessed" up so that the would avoid legal costs to fight in court."
Unfortunately, most of the time, it's cheaper to pay up than to fight in court. His answer doesn't address that nor does my question - I admit my own failing.
I have a real problem with this... (Score:2)
I have a concrete example and I'm afraid to mention it because it would violate my NDA with IBM. It's in regards to OS/2 for Windows and MS.
Re: (Score:2)
Obviously, if they've gone through some trouble to make code paths different, changed static strings and symbols around, then you don't necessarily know without spending a lot of time to see if the resulting code seems to do step-by-step what a compiled version of your original code does.
Re: (Score:2)
Obviously, if they've gone through some trouble to make code paths different, changed static strings and symbols around, then you don't necessarily know without spending a lot of time to see if the resulting code seems to do step-by-step what a compiled version of your original code does.
They've done what you've said? They reversed compiled it? They've compared entry points and everything?
If so, then they've got a case.
Re: (Score:2)
Indeed. I can't speak for gpl-violations' work. But without doing this I don't see how a case is possible from a technical perspective.
Re:I wish I asked this differently... (Score:4, Insightful)
Unfortunately, most of the time, it's cheaper to pay up than to fight in court. His answer doesn't address that nor does my question - I admit my own failing.
I don't follow you. How is 'fessing up' to a violation you didn't actually commit a way out here? There is no option to buy your way out of a GPL violation. If Harald accused someone of a violation, the accused can only avoid legal action by releasing the source code or removing the code from their product. They can't just pay a fine and continue on with no other change.
If they are in fact innocent, and Harald is still convinced they've pinched some GPL code, 'fessing up' makes no sense.
Besides which, in all cases of GPL violation I've every heard of, the use of the code in question was never in dispute, but rather it was the interpretation of the GPL itself that was at issue.
yankpop
Parent
Hardware Acceleration (Score:5, Interesting)
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.
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
Takes time too (Score:3, Interesting)
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
just properly document in a way that doesn't violate any agreement and doesn't piss off any licensor the hardware which probably was never documented in the first place, only reference code was used and everything needs to be written from scratch and less the FOSS crowd write their own.
Here, fixed for you.
The documentation will probably require lots of efforts, for which VIA doesn't have unlimited resources, and even after that, will require even more time as it goes through all the necessary legal checks.
Re:Takes time too (Score:4, Insightful)
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Cry me a river. If they don't consider the Linux/FOSS market big enough to worry about then say so and be done with it. Intel will gladly take their business [intellinuxgraphics.org].
If you're simply saying "this will take time", then fine. As long as they are interested in taking that path, patience is a virtue. However, it wasn't mentioned in the article and I was bringing it up as a possibility. The preferred one, from many perspectives.
Parent
Re: (Score:2)
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Hasn't MicroSoft had trouble complying with the EU rulings partly because they didn't have any real documentation, they could just look at the code when they needed to know something? I'd imagine the same situation would be possible here, although probably less likely unless everyone knows both C and VHDL/Verilog.
Documentation (Score:5, Interesting)
Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
(BTW: Pinouts are irrelevant to driver making, they come into play when making the PCB).
What the free software community needs is a really neatly done documentation. With nice exhaustive tables listing all internal registers, their meaning, along with pseudocode describing the effect and small snip showing usage examples.
Along this, also diagrams showing sequence for initialising stuff, sending stuff to some pipe line. Etc. All this in the kind of quality that you find in books about hardware available in libraries, or books that a company specialised in selling chip design will provide (i.e.: a company that will necessarily need to provide all the information to some 3rd party).
And that's probably what they *don't* have.
What they have is probably a huge mess. Of couple of things partially documented, some piece of documentation describing obsoleted designs (but that doesn't matter because hardware engineer responsible for it is just next door to the programmer making the driver and could verbally notify about the differences), things instead of being neatly organised, are neatly interwoven with other elements that are irrelevant or even licensing violations (say some generic demonstration code snip just next a some fragment of actual production code - a clear violation of the MPEG patent's licensing terms).
At no point was there initially any plan to release professional grade book documenting the programming of the hardware. Hence, at no time did anyone go through all the expense of writing a clear detailed and extensive one. Instead, as things were built in house, information could be quickly exchanged internally, in e-mails, verbally or scribbled on napkins.
I've already seen industrial applications (controlling lab instruments) which where initially designed only to pilot the equipement, and on which an SDK was only tackled as an after-though, with completely botched documentation, where only half of the symbols in the DLL are covered by the book (including crucial API calls which were just skipped), ambigously worded partial documentation (As in "FooBazor() - this function sets the new foobaz". Well thanks, but WTF is a foobaz ?)
That has never stopped them from producing a functional software because, well, they were doing it internally and they could always ask a colleague who knew.
And that a situation where :
- there's no licensing issue covering the software it self (the IP is the equipement itself), unlike the "patent minefield" of codecs, so the equipment manufacturer was much more free to release info.
- the company has at some point taken the decision to document their code to be able to cite "open to extension" as a selling point. Unlike VIA which only starts to document (as in write a documentation for external users) now.
The company I currently work at is even a bigger mess as most of the documentation is simply the source code's comments.
The available stand alone documentation is minimalistic at best. And nowhere is any diagram of the overall flow.
I really seriously thing that, what another /.er proposed - reading the VHDL/Verilog as a form of documentation - happens much more in such settings than we suspect. Specially in rather small teams, doing all the work internally. And a huge part of the rest is transmitted verbally or scribled.
Parent
Re: (Score:2)
It wouldn't be so bad if they had made an effort to partner with someone to make software with hardware acceleration available, even at a price. ATI and nVidia both went along that route, requiring you to buy the software to make use of h.264 acceleration. With VIA, there isn't even that option, there is literally zero support for a feature they are touting to sell their products.
Re: (Score:3, Insightful)
Aubrey de Grey (Score:2)
VIA and Mini/Pico-ITX (Score:3, Interesting)
I understand that's question to different department. But still.
Does VIA intends to promote and produce further Mini/Pico-ITX mainboards?
What I'm really missing is barebone PCs based on such mainboards. There is a whole zoo of component - but they are not always compatible. In my case, for example, I found a good case for Mini-ITX I wish to buy - now the problem is that I can't find Mini-ITX mobos which are as per spec are compatible with it. Apparently physical measurements of the Mini/Pico-ITX are not completely standardized or are not sufficient to cover all what other manufacturers want to throw into the mix.
Also, Mini/Pico-ITX lacks its own spec for power supplies. The ones shipped with cases are often of bad quality (or overhear or too noisy).
Does VIA intends to start selling complete Mini/Pico-ITX solutions? Something I need to throw in only hard drive/RAM/etc - and I have a ready system.
Just pay the license... (Score:2, Interesting)
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
Just pay the license and tell the system integrator that each machine comes with an MPEG2/H.264/... license. Yeah, you product will seem more expensive (to the stupid system integrator). :)
Re: (Score:2)
Why would you do this when not all of the systems integrators actually need the MPEG2/H.264 licenses?
Regarding 3D support answers... (Score:5, Insightful)
Shame. Easiest answer would be to divulge the programming info for the GPU cores in question. Something AMD managed to do.
I suspect you have a serious problem on your hands though, based on your response regarding S3, which still claims itself as being a VIA "joint venture". Typically, the parents of a joint venture has a bit more pull on the child company than you're implying. While they're autonomous, you would typically have enough pull to at least do things like dump programming info on the IGP lineup.
Time, really, is something VIA doesn't have a lot of on their side at this point. You have Intel breathing down your necks and while the Isiah CPU is an awesome product from the things you've been demoing, it doesn't do any good for you if the IGP you're relying upon in the netbook and baseline ITX board lineup hasn't any support for things like 3D or video acceleration in it's support on Linux. Something Intel's already got lined up- in spades compared to VIA. Power consumption or speed of the CPU doesn't buy you anything if you can't USE them.
Heh... It's funny that you should mention ATI. AMD had to do that, yes. But, you missed mention of the other thing AMD has done- give out technical documentation for most of the chipset's functionality. They're even working on divulging the 3D programming info on their latest offerings right now. Now, I'm not saying that VIA (or you for that matter) are in a position to fix that situation on the UniChrome/Chrome9 components. But to say that AMD's situation is even roughly analogous to yours and that it takes time is a bit disingenious, Harald, because of the other little detail.
VIA lost my business (Score:5, Interesting)
VIA would have had a lot of business from me had their drivers either worked, or their communication been good, or they'd opensourced all this stuff earlier.
In my last job we produced kiosk and signage displays, as well as multiple display units for bookmakers shops. Each shop ran up to 32 displays, and some customers had 4-5000 shops. That's a lot of hardware.
We first looked at VIA miniitx boards as they had everything we needed, technically speaking. But the drivers sucked, bore no resemblance to any documentation, were incapable of being accelerated, and couldn't be rotated (for portrait displays) no matter how much they were supposed to. If they supported opengl properly it wouldn't have been an issue. This is without going into the problems of the thousands of different revisions of VIA hardware, all of which failed in subtly different ways.
I left the company but they're now using NVidia boards which are more capable, but not as suitable for an embedded solution. Like me the rest of the techies got sick of fighting VIA stupidity.
If this new open methodology gives us proper opengl support and video decode in a mainline kernel they will win a lot of customers. As it is, it's still some way from that. A real shame.
Too many projects? (Score:2, Funny)
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.
Get back to work, you slacker, and stop spending so much time on Slashdot!
Re:Hey Fox News ... (Score:4, Interesting)
Parent
Re: (Score:3)