I sent a response to Greg. I didn't push the BIOS issue. He seems to have
strong feelings about it. So I talked about the SD Associations
restrictions.
Greg Kroah-Hartman's response:
-----------------------------------------------------------------
On Wed, Mar 21, 2007 at 11:13:03PM -0400, Curtis Monroe wrote:
>
>
> On March 20, 2007 02:06 pm, you wrote:
> > On Tue, Mar 20, 2007 at 12:51:19AM -0400, Curtis Monroe wrote:
> > > In other words...Can embedded linux developers hide their close source
> divers
> > > in a custom close source BIOS, that is called from an open source
"wrapper
> > > module"?
> >
> > No.
> >
> > > PCs have close source BIOSes.
> >
> > Some do, some do not.
> >
> > > My problem is the SD flash card interface is patented and its governing
> body
> > > doesn't allow release of open source drivers for the SD interface.
> >
> > That's not true, we have SD drivers in the Linux kernel now.
>
> My understanding is that the SD Association makes you sign an agreement when
> you pay your membership fees. This agreement prevents you from releasing
open
> source code based on the SD specifications they provide. You also can't
> release any information about their specs. This is how they encourage
> developers to join their association.
>
> I haven't joined yet because I'm not sure I want to sign this agreement.
>
> If you don't join the SD Association you can market your product as an "SD"
> compatible product. You can't mention "SD" in any online or user
> documentation. You can't use "SD" in any advertising, packaging or marketing
> material.
>
> Since the SD interface has features related to digital rights managment. The
> association also hoped the closed specs will prevent piracy and make the
> music industry happy. (oh, the wonders of DRM infected hardware).
Yes, I am aware of the SD association issues. But as the Linux kernel
code is reverse engineered, it's not an issue for us at all.
> > > I know this violates the spirit of the GPL. But there doesn't seem to be
> any
> > > other solution. Besides abandoning the SD card interface.
> > >
> > > Researching the question on line did not turn up any conclusive results.
> >
> > Why not use the SD code that is already in the kernel, my devices work
> > just fine with it now...
>
> I'm not sure if using the open source SD driver in the kernel would violate
> the SD Associations license agreement?
>
> Since the SD interface is backwards compatible with the MMC standard and MMC
> allows open drivers, any open SD driver would be legal if it just followed
> the MMC interface.
>
> I'm not sure if an MMC only open source SD driver would violate a product's
> right to advertise as an "SD Card" enabled device?
I don't know, but as the kernel doesn't do any advertising, I don't
think it really matters for us :):)
> This is why I questioned the custom BIOS solution. Sometimes there are third
> party licensing restrictions like this that prevent open source drivers.
>
> Maybe increased legal enforcement of the GPL would put pressure on the SD
> Association to allow open source SD drivers. (and very few people use the
> security features the SD Association is trying to protect).
It doesn't really matter, as again, we never used their material to
provide support to our users.
> P.S. I'm sharing your feedback the the TS-7200 Users Group:
> http://tech.groups.yahoo.com/group/ts-7000/
Sure, not a problem at all.
thanks,
greg k-h
-----------------------------------------------------------------
-Curtis.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|