On Fri, Apr 06, 2007 at 11:50:15AM -0400, Marcus Watts wrote:
> Writes darren kirby <[EMAIL PROTECTED]>:
> ...
> > From: Joseph Jezak:
> > >>As one of the reverse engineers, the reason for the openness of
> > >>writing the specification was to ensure that the Chinese Wall method
> > >>was maintained.

> > >>To date, I have not been contacted by any of the bcw programmers
> > >>regarding clarification of the specification, but I would welcome
> > >>any questions they might have.

> > So how were they not trying to work with the OpenBSD folks?

> In order for the OpenBSD folks to have worked this out, they would have
> had to go through function by function and ask for approval to use that
> function.  If refused, they would have had to devise a workaround that
> was sufficiently different as to qualify as "new and original" --
> without documentation.  The example function quoted sounded like it was
> actually a macro - probably a small enough chunk of code that there may
> not be any logical "new and original" alternative.  So, even if we stop
> here, we have a cumbersome process that (a) wastes a lot of time, and
> (b) is not guaranteed to result in anything that works.  But wait,
> there's worse!  The FSF contract standard generally requires a release
> *in writing*.  (See documents like "Legal Issues about Contributing
> Code to GNU").  Assuming the gnu bcw programmers are serious about
> protecting their interests (and they sure sound like they are), and
> assuming the openBSD folks are even willing to tolerate this level of
> nonsense, then to get the same level of protection each of these
> exceptions would then need a separate written release.  So, what we're
> talking about here is a momumental amount of work that is easily an
> order of magnitude more complicated than the actual driver, with no
> appreciable benefit to anybody except perhaps the lawyers drafting up
> all those releases.  No part of this process produces better code,
> and no part of this process produces a more secure operating system,
> so all this work we're talking about here is way out of scope for OpenBSD.

> There isn't really any alternative for Marcus Glocker here either.  Now
> that he's clearly seen the GPL code, it would be very difficult for him
> to produce any code for this hardware a clever lawyer couldn't argue
> was "derivative".  He's on the "dirty side" of the Chinese Wall now.
> Unless he wants to spend 90% of his time working out function by
> function copyright releases, the only real alternative he has is to
> delete his code & find something completely different of actual value
> to work on.
>
> I think the really valuable lesson out of all this is that this shows,
> for once & for all, that a GPL licensed driver is *not* an acceptable
> substitute for proper documentation released by the maker without undo
> intellectual or financial burden (ie, no NDA's, excessive licensing
> fees or restrictions.)

> It's a shame the gnu folks didn't release their reversed engineered
> specifications separately.  I can understand why though; DMCA would
> make that a much more risky affair today than when the Phoenix folks
> pioneered the Chinese Wall approach.

>                                       -Marcus Watts
Part of this is nonsense and I dont mean to pick on you in particular
but I have seen it repeated a few times now and its getting annoying.

If licenses were as viral as some of you people imagine that one cannot
look at a source file copyrighted with a dumb license interpert what the
code does and create your own version parts of the LINUX KERNEL WOULD BE
 SUBJECT TO THE APSL and imagine the CDDL as well but I dont mess around
with sun hardware... Seriously you can go look at some of their recent
mac powerpc drivers and you can see plenty of references to where bits
of information were taken from darwin, they have done nothing wrong.

Reply via email to