linux-kernel - Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120421001433.2955abd4@pyramind.ukuu.org.uk>
Date:	Sat, 21 Apr 2012 00:14:33 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Mike Snitzer <snitzer@...hat.com>
Cc:	James.Bottomley@...senpartnership.com, linux-scsi@...r.kernel.org,
	Hannes Reinecke <hare@...e.de>,
	Chandra Seetharaman <sekharan@...ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to
 EXPORT_SYMBOL

> Sure Alan, seize on "proprietary" and "EXPORT_SYMBOL_GPL".. and gloss
> right over the fact that what is being proposed is reasonable.

I suggest you read the licence document.

> Any multipath driver should be able to detach a scsi_dh module.  As is
> evidenced by the fact that they can already make use of sysfs to do so.

They can call the _GPL version if they are GPL, so there is no problem.

> Relaxing the scsi_dh_detach interface makes it easier for a long
> standing proprietary driver to get out of Linux's way.

So we are back to this being for a proprietary driver trying to link with
GPL code.

> _Upstream_ has kept it that way because we've been concerned about
> breaking PowerPath in enterprises where Linux is deployed.  Upstream has
> been good citizens to the fault of Linux.

Not from where I am standing. It sounds like upstream has suffered for
the benefit of a dubious proprietary module.

> > I'm a rights holder. Domain expertise isn't relevant here. The code I
> > provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL
> > or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the
> > kernel be modified to match it) cannot call it.
> 
> Remind me again when you ever developed anything to do with scsi_dh?

It's part of the same kernel. It's GPL code. You can take your own code
and relicense it to be non GPL if you wish, but not mine nor Greg's nor
anyone elses.

> To be clear: PowerPath doesn't _need_ this.  Not even close.

Then we don't need to apply it ? Thank you for clarifying that.

> Linux is improved by not having to walk on egg shells that attaching a
> helpful linux-only layer in kernel will somehow screw up some 3rd party
> software that a customer values.

That's a problem for Red Hat. Don't dump it on upstream. If the kernel
would work better with scsi_dh always attached we should always attach
it. It's the problem of the out of tree people how they cope. They'll
figure something out.

And you still have the same confusion

There is no "Linux only" magic in _GPL. Any derivative work of a GPL work
must be distributed under the GPL.

> You still don't get it... yet you'll saber rattle behind generic GPL
> lawyer-up nonsense.

This has gone far enough but it seems your management has already jumped
on it. Not my preferred way of handling such matters but Red Hat legal and
PR need to rein you in before you cause some serious damage.

Alan
--
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/