Date:	Fri, 2 Jul 2010 08:52:04 +0200 (CEST)
From:	Piotr Gluszenia Slawinski <curious@...190.internetdsl.tpnet.pl>
To:	Howard Chu <hyc@...as.com>
cc:	Dave Airlie <airlied@...hat.com>,
	Timothy Meade <zt.tmzt@...il.com>,
	linux-arm-msm@...r.kernel.org,
	Saravana Kannan <skannan@...eaurora.org>,
	LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: Closed source userspace graphics drivers with an open source 
 kernel component

> Piotr Gluszenia Slawinski wrote:
>> >  There is no point supporting companies that give you a little bit of
>> >  information in exchange they want the support that being in a mainline
>> >  kernel gives. Its an unfair exchange of knowledge and time, and if they
>> >  claim they have to make a profit then its even more unfair.
>>
>>  also, they seem to do it quite wrong way. i.e. much simpler would be to
>>  just implement regular, open driver , and implement additional crypto
>>  mechanism in chipset itself, allowing to use simple userspace program
>>  sending certified keys allowing GPU to operate.
>>  if key is not available and device/driver not paid/registered, then
>>  GPU would simply lock itself , similiar to pre-paid designs from
>>  company whose name should not be spoken aloud.
>>
>>  also certain functionality could be ordered with same chip structure,
>>  i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
>>  with user buying proper 'entry level' pre-paid code set from manufacturer.
>>
>>  this would provide quite same functionality (profit), without impacting
>>  open-source projects like Xorg with unnessesary complications.
>
> Pardon me for intruding in this discussion, but I'm astonished that you 
> actually find what you posted to be acceptable. If I pay for a piece of 
> hardware, I have the right to use it. Requiring certified keys before it 
> performs the function for which it was purchased is pure nonsense.

in this context it is more lease than purhase, similiar to situation
when you buy cellphone, but you are limited by the sim card to access
networks, and sometimes even own adress book (when your account is 
drained, your adress book stored on sim data card is locked).

i do not claim such practices are convient for users, yet they are
very convient for hardware vendors, and it seems more 'open cards' play
which seems more clear to user than situation in which you need binary 
blobs which can contain everything from rootkit to actual crypto routine
(i.e. to prevent driver running on 'non original' clone video cards made
by competitor company) running with ROOT privileges on the computers of 
users being told it is Only Way (tm) to make given company profit and 
survive, while providing some functionality as a trade.

so to resume such solution - one gets fair information about to which 
extent company allows usage of hardware sold to user (without messy 'end 
user license' implied on binary drivers) , and can perform clear
decision - either buying 'secure' and 'genuinely original' video card
with options one needs and is able to pay for (which includes
software development price) , or goes for more 'open' solutions.

mind you most of hardware vendors do NOT want you to purhase
hardware, at best they want LICENSE you to use it for specific
purpose, and specific period. the wish of yours to freely use
hardware does not represent accurate wish of casual users ,
which do not care about freedom as long as hardware allows them
to perform specific task.

either way imho mixing those two attitudes is erroneus,
as it creates confusion and beliefs that some hardware is intended
for free use, and in same time that some software should provide
infrastructure to limit safety and freedom of users.
also it leads to development of BOTH. the sooner those two will
be separated, the sooner alternatives will be created,
and most importantly RECOGNIZED by market.

-- 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists