public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Cleaning up new port
Date: Tue, 17 Mar 2009 09:49:51 -0400	[thread overview]
Message-ID: <49BFAA7F.9010802@ge.com> (raw)
In-Reply-To: <20090317130915.7D67F832E8B7@gemini.denx.de>

Hi Remco,

Wolfgang Denk wrote:
> Dear Remco Poelstra,
> 
> In message <49BF9EA5.5040805@duran-audio.com> you wrote:
>> I fully understand. The problem is that there is a special Ethernet PHY 
>> on the board which is under a NDA, so I cannot publish code surrounding 
>> it. I can publish the general part of the ethernet driver.
> 
> So you cannot ever give anybody else a binary of your code or a board
> whith this code installed. Keep in mind that U-Boot is under GPL, and
> GPL violations are not accepted.

You should check if the PHY is already supported under linux.  You 
should also see if it is really necessary to use the PHY's Sooper 
Seecrit IP Magic Registers(R) for basic functionality.  Theoretically, 
all the necessary functionality of the PHY is available through just the 
commonly known (standard and possibly "defacto standard") registers.

Even NDAs are (should be) realistic in that they don't try to restrict 
you from using publicly available information, and PHYs implement a 
publicly available standard.

If the PHY isn't already supported by a GPLed driver and using the 
Sooper Seecrit registers is necessary, I would suggest Remco's Lawyer 
Department work with the PHY provider's Lawyer Department.  Many 
component suppliers are getting clued in that strict NDAs that prevent 
use in GPLed programs is extremely counterproductive to selling their 
parts... limiting their market to just proprietary OSes is not in their 
best interests.

I understand many component manufacturers don't have a problem with 
releasing GPLed drivers for their parts as long as you don't replicate 
their user's manual as comments in the driver.  You need permission to 
have sufficient comments and sufficient definition that someone reading 
the code understands what is happening.  Magic numbers slammed into 
magic registers is not acceptable in GPLed drivers (IMHO).

>> I see, I will provide a working example.
> 
> Probably exclude the whole network support part from your code.

...or, preferably, get permission from the PHY supplier.

> Best regards,
> 
> Wolfgang Denk

Best regards,
gvb

      reply	other threads:[~2009-03-17 13:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17 12:04 [U-Boot] Cleaning up new port Remco Poelstra
2009-03-17 12:14 ` Wolfgang Denk
2009-03-17 12:59   ` Remco Poelstra
2009-03-17 13:09     ` Wolfgang Denk
2009-03-17 13:49       ` Jerry Van Baren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49BFAA7F.9010802@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox