All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Mike Snitzer <snitzer@redhat.com>
Cc: James.Bottomley@hansenpartnership.com,
	linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
	Chandra Seetharaman <sekharan@us.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL
Date: Sun, 22 Apr 2012 23:34:54 +0100	[thread overview]
Message-ID: <20120422233454.7cdd0f35@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <20120422221329.GB24109@redhat.com>

> The author and maintainers of the scsi_dh code agreed that relaxing
> scsi_dh_detach's export was fine and they acked the change.  Their
> rights are important too.

They can only grant rights beyond the GPL providing they remove everyone
elses code. But that isn't the big issue. I wish you'd go talk to your
legal team, then you might understand the real problem here. But you
won't, so I'll hopefully be talking to them tomorrow.

> And I understand what you're saying about you and others being rights
> holders that have a say.  But communication has broken down because
> you've been unwilling to concede that those who have acked this
> relaxation _know_ that what scsi_dh provides is _not_ unique
> functionality to Linux or Linux SCSI multipathing.

"Unwilling to concede". There is nothing to concede. The GPL spells out
the rules. Also if you'd have talked to Red Hat legal you'd have
understood there are other issues here.

> Allowing a proprietary driver to use scsi_dh_detach to unload scsh_dh*'s
> associated additional SCSI sense and error processing doesn't implicitly
> mean said driver is using derived work to achieve it's comparable
> processing.  It simply means their offering reasonably conflicts with
> what Linux is providing:

Can I suggest you don't make legal statements from a Red Hat address
without talking to your legal team. It's not a good idea and tends to get
people into trouble.

> All SCSI multipathing drivers are expected to interpret and react to
> SCSI sense information.  Doing so is not an innovation unique to Linux.
> Because it is not unique it collides with a long established proprietary
> driver's offering.

That's their problem. They chose not to play ball, and they are going to
have to run after us and sort their own mess out. They'll cope as they've
had a lot of practice at it.

> Yes, secretly switching channels to google+ and lobbing questions about
> Red Hat's commitment to free software at one of Red Hat's OSS community
> leaders probably isn't the preferred way to handle such things.

I didn't do anything secret. How is posting publically "secret". Also I
made very sure the people who needed to see it in Red Hat did, so they
can do something about it and rein you in. It's had the right effect and
it means the right folks in Red Hat can look at the issue itself.

> You capture the hearts and minds of many Linux and GPL stakeholders and
> are well respected -- and believe it or not I'm not some naive or
> reckless individual.  I am a professional Linux developer who works for
> the most respected name in Open Source development.

I spent ten years at Red Hat, I'd like them to keep that reputation which
is one of the reasons this bothers me a lot. The other being the legal
issues.

> And I now do _not_ have concerns of legal issues associated with this
> change.  I genuinely do appreciate your concern though.

Well that's for Red Hat management and legal to determine, unless you are
also a practicing IP lawyer as well ?

> With that said, I'm leaving the decision of whether or not to relax
> scsi_dh_detach's export in the very capable hands of James Bottomley.
> 
> I'll be fine with whatever James decides but do hope that this outcry
> will not serve to establish precedent that ties our hands in the future
> when comparable decisions need to be made about the improvement of
> Linux's interfaces and overall function.

This isn't tying your hands. There are two things which tie your hands
here - the GPL (intentionally) and certain properties of US law - which
I'll discuss with the appropriate Red Hat people in an appropriate forum.
You clearly are not that appropriate person.

Perhaps after that they can explain to you in the proper manner internally

- Why legal matters should be referred to lawyers for checking.
- Why your patch may raise a particularly nasty potential problem if it
  were merged

Alan

  reply	other threads:[~2012-04-22 22:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-15 21:44 [RFC PATCH] scsi_dh: allow 3rd party multipath drivers to scsi_dh_detach Mike Snitzer
2011-12-20  7:31 ` Hannes Reinecke
2012-01-05 15:24   ` Mike Snitzer
2012-04-05 14:47   ` Mike Snitzer
2012-04-20 14:45     ` [RESEND][PATCH] [SCSI] scsi_dh: allow 3rd party multipath drivers to use scsi_dh_detach Mike Snitzer
2012-04-20 15:17       ` James Bottomley
2012-04-20 15:46         ` Mike Snitzer
2012-04-20 15:49         ` Chandra Seetharaman
2012-04-20 17:34       ` [PATCH v2] [SCSI] scsi_dh: change scsi_dh_detach export to EXPORT_SYMBOL Mike Snitzer
2012-04-20 20:41         ` Alan Cox
2012-04-20 21:58           ` Mike Snitzer
2012-04-20 22:20             ` Alan Cox
2012-04-20 22:58               ` Mike Snitzer
2012-04-20 23:14                 ` Alan Cox
2012-04-20 23:34                   ` Mike Snitzer
2012-04-22 22:13                   ` Mike Snitzer
2012-04-22 22:34                     ` Alan Cox [this message]
2012-04-22 23:01                       ` Mike Snitzer
2012-04-22 23:13                         ` Alan Cox

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=20120422233454.7cdd0f35@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=hare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=sekharan@us.ibm.com \
    --cc=snitzer@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.