Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
To sum it up: http://www.uwsg.iu.edu/hypermail/linux/kernel/0312.0/0670.html Please resume this discussion in private mail. EOT Thorsten ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher <[EMAIL PROTECTED]> wrote: > On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote: > > > or better or whatever. cool, no problem. what? you signed a NDA that > > does not allow you distribute the os in the first place? your bad. > > Once again, and now in capitals. > > IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN > FIDDLE WITH IT AS YOU LIKE. maybe i should just shut up and let you believe whatever you want and this is clearly my last mail to this thread. i guess others or even you are already bored to death by this topic anyway. but its summer slump, so who cares. i tried to explain multiple times why a binary module is not compatible with the gpl and why it is not relevant in any way that one can recompile or upgrade the kernel "sacrificing a fundamental feature of the hardware (speak HDMI)". maybe i'm just not capable to make myself clear and/or find the right words so let me quote mr. linus torvalds stating (many times) that binary kernel modules are "by default" a derived work of the kernel and thus must be licensed (at least additionally) under gpl: > [..] > In the binary kernel module case, a bug in the code corrupts random > data structures, or accesses kernel internals without holding the > proper locks, or does a million other things wrong, because a kernel > module is very intimately linked with the kernel. > > A kernel module is not a separate work, and can in no way be seen as > "part of the hardware". It's very much a part of the kernel. And the > kernel developers require that such code be GPLd so that it can be > fixed, or, if there's a valid argument that it's not a derived work > and not GPLd, then the kernel developers who have to support the end > result mess most definitely do need to know about the taint. > [..] so what is a "valid argument" that a module is NOT a "derived work"? [..] > Similarly, historically there was a much stronger argument for things > like AFS and some of the binary drivers (long forgotten now) for > having been developed totally independently of Linux: they literally > were developed before Linux even existed, by people who had zero > knowledge of Linux. That tends to strengthen the argument that they > clearly aren't derived. > > In contrast, these days it would be hard to argue that a new driver or > filesystem was developed without any thought of Linux. I think the > NVidia people can probably reasonably honestly say that the code they > ported had no Linux origin. But quite frankly, I'd be less inclined to > believe that for some other projects out there. > > Linus best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Simon schrieb: >Georg Acher wrote: > > > >>And quite frankly, the "dumb" consumer doesn't care about HDCP and its >>implications. Compared to DRM on music, HDCP is invisible to him, he has no >>visible disadvantage. So all the boycott stuff is for freaks only. The >>consumer buys a display with HDMI and it just works (with or without >>HDCP). BTW: HDMI doesn't mean you have to enable HDCP. >> >> > >I cannot let this pass. > >They don't know they need to care, but they will, down the line after >their money has been taken. > > That may be or they just recognize that this "computerstuff" again just not works as advertized and they will buy it again the next time. The "freaks" trying to fix their stuff as good as possible after having prayed why they should not have bought it in the first place. >I own a sony HD projector that is not permitted to display HD content! >this will happen to a lot more people and they will care. Especially >when the next DRM protocol comes along. Its already happening to both >protocols and DRM standards. I noticed that on the xine mailing >list there was a request to encode wma content because their phone >only supported that. With the rapidly growing green awareness there >is the potential for a backlash against manufacturers that force >consumers to dump working kit just because the hardware doesn't talk >the same protocol. open standards are the only way to prevent that kind >of waste and frustration. The problem with all DRM (and to some degree >the rapidly changing protocols) is that the problems appear long after >the initial purchase. They control the interface between equipment or >media and as such it costs significant resources to fix, repair, replace >or bypass etc and then only if its legal and purchasable. > > And you really think somebody will recognize that ? Its again just that computer stuff that does not work as advertised ... I really hope you are right and people are understanding what open standards and open protocols are good for. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On 01.07.2007 21:10, Georg Acher wrote:
> On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote:
>
> > If only the hardware vendors where as "united" as the movie-industry.
>
> HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and
> HDMI. As long as they can sell chips and licenses, they don't care about the
> consumer, looks quite united to me ;-)
That's the "back-stabbing"-part i meant.
You can be certain that there is someone to pick up a knife laying around.
Here is another example of such a "knife" thing from today:
http://hardware.slashdot.org/hardware/07/07/01/0221213.shtml
They invented it because they think that someone will want it (and most
probably someone will), just the same as Intel/Silicon Image.
Another word would be:
"anticipatory obedience" ("vorauseilender Gehorsam" (translated by
dict.leo.org))
Bis denn
--
Real Programmers consider "what you see is what you get" to be just as
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated,
cryptic, powerful, unforgiving, dangerous.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher wrote: > And quite frankly, the "dumb" consumer doesn't care about HDCP and its > implications. Compared to DRM on music, HDCP is invisible to him, he has no > visible disadvantage. So all the boycott stuff is for freaks only. The > consumer buys a display with HDMI and it just works (with or without > HDCP). BTW: HDMI doesn't mean you have to enable HDCP. I cannot let this pass. They don't know they need to care, but they will, down the line after their money has been taken. I own a sony HD projector that is not permitted to display HD content! this will happen to a lot more people and they will care. Especially when the next DRM protocol comes along. Its already happening to both protocols and DRM standards. I noticed that on the xine mailing list there was a request to encode wma content because their phone only supported that. With the rapidly growing green awareness there is the potential for a backlash against manufacturers that force consumers to dump working kit just because the hardware doesn't talk the same protocol. open standards are the only way to prevent that kind of waste and frustration. The problem with all DRM (and to some degree the rapidly changing protocols) is that the problems appear long after the initial purchase. They control the interface between equipment or media and as such it costs significant resources to fix, repair, replace or bypass etc and then only if its legal and purchasable. Simon ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
I demand that Georg Acher may or may not have written... [snip] > And quite frankly, the "dumb" consumer doesn't care about HDCP and its > implications. Compared to DRM on music, HDCP is invisible to him, he has no > visible disadvantage. That's as may be... however, it does seem to be ignoring those of us who happen to want video output in a window (as I do now with vdr & gxine). If there's any taintware involved in that, I for one don't want it. (And I couldn't care less about it right now, at least for my own use - there's no terrestrial HD broadcasting here and there won't be until 2012 at the earliest, that being when analogue transmission is switched off.) > So all the boycott stuff is for freaks only. Right... so consumers are either dumb or freaks... remember that you're one too :-รพ [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Travel less. Share transport more. PRODUCE LESS CARBON DIOXIDE. Since you're going to die anyway, can we use you as a shield? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 08:43:04PM +0200, Matthias Schniedermeyer wrote: > If only the hardware vendors where as "united" as the movie-industry. HDCP was invented by Intel, Silicon Image holds a lot of patents on DVI and HDMI. As long as they can sell chips and licenses, they don't care about the consumer, looks quite united to me ;-) In principle, HDMI is not that bad (ok, the mechanical part is ugly...). In contrast to DVI, it allows to encapsulate audio and additional information, which makes it much more universal. Unfortunately it is quite expensive to get into the club (and buy chips) and the legal stuff is -er- demanding... And quite frankly, the "dumb" consumer doesn't care about HDCP and its implications. Compared to DRM on music, HDCP is invisible to him, he has no visible disadvantage. So all the boycott stuff is for freaks only. The consumer buys a display with HDMI and it just works (with or without HDCP). BTW: HDMI doesn't mean you have to enable HDCP. But you can't tell the consumer "sorry, we think that HDMI is bad/crap/useless anyway, so we have only analog output". He will look for another product with a plug in the right form factor. And nobody spends a few hundred thousand $ on HW development just for a freak product... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On 01.07.2007 19:40, Georg Acher wrote: > On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote: > > > or better or whatever. cool, no problem. what? you signed a NDA that > > does not allow you distribute the os in the first place? your bad. > > Once again, and now in capitals. > > IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE > WITH IT AS YOU LIKE. > > You won't find any HDMI chip without NDA for the forseeable future. No NDA, > no chips, no HDMI. So there's simply no choice at all and analog inputs are > slowly dying. A card without HDMI is already dead in the market. If only the hardware vendors where as "united" as the movie-industry. The result would have been a clear "F*ck You". But with all that backstabing from the left/right/up/down/center, the only looser is the group between their chairs. (The consumer). It's the same with the current PNR and SWIFT data-transfers to the USA. If the EU would be united and say "F*ck You" the USA could happily close their borders. But i'd say the backlash from the economy would open up the borders faster than you can say 'Bad Idea'. According to Wikipedia (sorry german) http://de.wikipedia.org/wiki/Liste_der_L%C3%A4nder_nach_Bruttoinlandsprodukt the EU (in total) has a greater "gross domestic product" than the USA! And the EU has more citizens (about 300M USA, about 492M EU). But in all those cases the unity lacks and the "Power Player" wins. I'd say: Murphy's law proven right again. Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 06:47:18PM +0200, Clemens Kirchgatterer wrote: > or better or whatever. cool, no problem. what? you signed a NDA that > does not allow you distribute the os in the first place? your bad. Once again, and now in capitals. IT'S ONLY THE HDMI DRIVER. THE REST OF THE KERNEL IS GPL AND YOU CAN FIDDLE WITH IT AS YOU LIKE. You won't find any HDMI chip without NDA for the forseeable future. No NDA, no chips, no HDMI. So there's simply no choice at all and analog inputs are slowly dying. A card without HDMI is already dead in the market. If that security-by-obscurity is reasonable due to possible bus snooping, hacking, whatever: Surely not. Logitech also didn't gave me a datasheet for their Quickcam, so I reverse-engineered in in a few days with an USB analyzer. But this is not the point. If the vendor has the choice to sell cards or pay a multi million penalty, all these theoretical ideas get unimportant and the vendor cares about each single letter in the NDA. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
Georg Acher <[EMAIL PROTECTED]> wrote:
> No, it's not. Free is free, you can't make differences between
> hardware vendors using Linux as a basis for their HW and SW vendors
> using Linux as an OS for their SW. And that's exactly the intention
> of your wording ("zero cost").
strange interpretation of my words. where did i say, that there is any
difference from SW to HW vedors? "zero cost" implied, that some vendors
just try to get a free ride. otherwise there was no need for
http://gpl-violations.org/
> Oh, it helps a lot to tolerate opinions from people who don't know
> what's behind selling hardware with chips from others. There are
> things you can't change, eg. NDAs.
you can't change the GPL either.
> > free software does not care about how practical or profitable it is
> > for you to fulfill your distribution-license requirements.
>
> Until now, there's AFAIK no legal decision that you are not allowed to
> include binary only modules in the kernel. If it gets that far, we
> will put in user space. No real gain, but if it helps...
you are nitpicking. if you have read the kernel license and you
understood its intention you can not think binary modules would not
violate it. the GPL was never really challenged in court (at least to my
knownledge), does that mean it's invalid? the FSF itself clearly
stated, that binray only modules violate the GPL, who would know better?
[..]
> > it is not you who has to decide what i do with my hardware. THAT is
> > the whole point of free software. get real.
>
> Don't buy it and wait for a card with better Linux support.
>
> I'm beginning to understand why big consumer hardware vendors won't
> do Linux support at all, if they get always this friendly reception...
the usual ranting.
what does linux support have to do with wether you obey a certain
license or not? we are talking about the os "on" a pci card here. you
decided to use free software for your benefit, to make the card cheaper
or better or whatever. cool, no problem. what? you signed a NDA that
does not allow you distribute the os in the first place? your bad.
if it is so easy for you to change the offending software part, why not
from the beginning? your product specs sound really good and the fact
that there is linux running on top of the hardware seems to make it a
nice toy, at least at a first glance. the firmware of the ttpci cards
are a good example of why i would love to have a more open firmware on
it. how long did it take until it was stable? too long. 4MB ram support
could only be added by someone with access to the source code. did it
help anybody to keep the source locked up? did it prevent sc? no.
so i'm all for a DVB/video card that does not have these
limitations. people like to tinker with their harware. even if it's not
me personally who does something unusual with that thing, someone
will. the pure possiblillity of beeing "hackable" adds value to it.
the linux kernel, being monolithic, can be a showstopper if it can not
be changed/upgraded.
> > many people don't care about their freedom as users. either because
> > they don't have the knowledege to fiddle with the software
> > themselfs or they rather have binary drivers for their expensive /
> > high performance video card than free drivers for a cheep one.
> > fine. but at least vendors MUST respect the will of the countless
> > developers who release their work under the license of their choice
> > for a reason.
>
> Apropos "developers": How much do YOU already have developed for the
> Linux kernel, DVB-API or vdr? I've made the experience that the
> loudest people in this GPL issue have the least contributions...
regardless of wether this has something to do with the validity of my
arguments or not: i never contributet patches to the linux kernel
directly only some bugreports and patch-tests. i released one small
plugin and once or twice sent patches for vdr, but they got rejected
AFAICR, nevermind. besides from some small libraries and rather useless
tools from my early days i hope that i can convince my employer to
release my main project of the last 3 years under GPL3 [would be
hopefully rather useful for STB vendors or even xbmc]. nevertheless i
doubt i'm one of the loudest who endorses free software either. but i
truly believe that the one and only reason, why GNU/Linux is what it is
because of the GPL. otherwise it would be at best as "untot" as the
BSDs.
> But it's getting tedious. Take it or leave it, that's all I can say.
a decision i will make when time has come depending on the
circumstances.
best regards ...
clemens
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 03:55:04PM +0100, Darren Salt wrote: > I demand that Georg Acher may or may not have written... > > > On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote: > >> That doesn't matter. It's still Linux-based and you still need to release > >> the modified sources (I'd say enough to allow the building of a complete > >> filesystem image for the device). > > > To make it clear: This whole argument is *ONLY* about the HDMI chip driver, > > which is the only closed source part in the kernel. This part is *not* a > > modification of some existing code. > > That part may not be, but "you can't simply switch the kernel anyway, as it > has many additions for the V4L-stuff." That (to me) says 'modified kernel > source'... But that's included as source and released by Micronas as GPL. What I meant with "you can't simply" was that you need to do the all the diff'ing and porting the additions to a newer kernel version, which will not be actively supported. You can do it but I doubt the gain and RMM will stick to the "official" kernel version provided by Micronas anyway. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
I demand that Georg Acher may or may not have written... > On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote: >> That doesn't matter. It's still Linux-based and you still need to release >> the modified sources (I'd say enough to allow the building of a complete >> filesystem image for the device). > To make it clear: This whole argument is *ONLY* about the HDMI chip driver, > which is the only closed source part in the kernel. This part is *not* a > modification of some existing code. That part may not be, but "you can't simply switch the kernel anyway, as it has many additions for the V4L-stuff." That (to me) says 'modified kernel source'... [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Lobby friends, family, business, government.WE'RE KILLING THE PLANET. I am Zarniwoop of Borg. I've been waiting 900 years to assimilate you... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 02:33:21PM +0100, Darren Salt wrote: > That doesn't matter. It's still Linux-based and you still need to release the > modified sources (I'd say enough to allow the building of a complete > filesystem image for the device). To make it clear: This whole argument is *ONLY* about the HDMI chip driver, which is the only closed source part in the kernel. This part is *not* a modification of some existing code. You can build the whole image without it (or maybe with a dummy module) from source, and all the video decoding and analog output will still work, but you lose and HDMI/DVI output. Maybe there will be a better solution later, but for the moment that's it. There are enough real challenges in the project than thinking about how that module can be put into user space... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
I demand that Georg Acher may or may not have written... > On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote: [snip] > Until now, there's AFAIK no legal decision that you are not allowed to > include binary only modules in the kernel. If it gets that far, we will put > in user space. No real gain, but if it helps... As things stand, ISTM that if you distribute, you'll be in clear licence-violation territory in the view of at least some of the copyright holders. >>> The usual practical "anti-binary" arguments for a PC platform (new >>> mainboard requires new kernel) don't count here, it's an embedded >>> system. You can't simply switch the kernel anyway, as it has many >>> additions for the V4L-stuff. >> what if i wan't to put additional faetures into the card? what if i >> want to fix a bug in the firmware? benefit from performance improvments >> in later kernel releases? > IMO a theoretical question. This is not file server. It's a video decoding > card. That doesn't matter. It's still Linux-based and you still need to release the modified sources (I'd say enough to allow the building of a complete filesystem image for the device). And anyway, I think that the kernel-upgrade and bug-fix points are valid... and it'd probably help if you get as many of your changes upstream as you reasonably can (if you haven't already started on this). For a start, that's likely to make it easier for *you* to switch to a newer kernel :-) > Most of the important stuff is done in the (closed) co-processors > anyway. If you want it to be a file server, you don't need the HDMI output. No argument there. [snip] -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys) Steer clear of incorrect forms of verbs that have snuck in the language. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OT: issues about binary only code in GPLed programs [WAS] future VDR and Net??eiver OEM from Reelmultimedia
On Sun, Jul 01, 2007 at 12:33:39PM +0200, Clemens Kirchgatterer wrote:
> > > because that means they get an stable and well performing OS at zero
> > > cost for their embedded designes what makes these chips sell better.
> >
> > So what? Wasn't it idea of free Software to get it without paying for
> > it?
>
> no. and i'm a little bit shocked to read this from you. i hope this is
> just an unlucky wording.
No, it's not. Free is free, you can't make differences between hardware
vendors using Linux as a basis for their HW and SW vendors using Linux as an
OS for their SW. And that's exactly the intention of your wording ("zero
cost").
> > Or is there a newly inserted paragraph about hardware vendors to
> > pay something if they use free SW?
>
> sarcasm does not help here either.
Oh, it helps a lot to tolerate opinions from people who don't know what's
behind selling hardware with chips from others. There are things you can't
change, eg. NDAs.
> free software does not care about how practical or profitable it is for
> you to fulfill your distribution-license requirements.
Until now, there's AFAIK no legal decision that you are not allowed to
include binary only modules in the kernel. If it gets that far, we will put
in user space. No real gain, but if it helps...
> > The usual practical "anti-binary" arguments for a PC platform (new
> > mainboard requires new kernel) don't count here, it's an embedded
> > system. You can't simply switch the kernel anyway, as it has many
> > additions for the V4L-stuff.
>
> what if i wan't to put additional faetures into the card? what if i
> want to fix a bug in the firmware? benefit from performance improvments
> in later kernel releases?
IMO a theoretical question. This is not file server. It's a video decoding
card. Most of the important stuff is done in the (closed) co-processors
anyway. If you want it to be a file server, you don't need the HDMI output.
> it is not you who has to decide what i do with my hardware. THAT is the
> whole point of free software. get real.
Don't buy it and wait for a card with better Linux support.
I'm beginning to understand why big consumer hardware vendors won't do Linux
support at all, if they get always this friendly reception...
> [..]
>
> many people don't care about their freedom as users. either because
> they don't have the knowledege to fiddle with the software themselfs or
> they rather have binary drivers for their expensive / high performance
> video card than free drivers for a cheep one. fine. but at least
> vendors MUST respect the will of the countless developers who release
> their work under the license of their choice for a reason.
Apropos "developers": How much do YOU already have developed for the Linux
kernel, DVB-API or vdr? I've made the experience that the loudest people in
this GPL issue have the least contributions...
But it's getting tedious. Take it or leave it, that's all I can say.
--
Georg Acher, [EMAIL PROTECTED]
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
