Hi all,
Enough people have been asking me about this lately, that I thought I
would just bring it up publicly here.
It seems that the Infiniband group (IBTA) has changed their licensing
agrement of the basic Infiniband spec. See:
http://www.theinquirer.net/?article=18922
for more info about this.
The main point that affects Linux is the fact that now, no non-member of
the IBTA can implement any working Infiniband code, otherwise they might
run into legal problems. As an anonymous member of a IBTA company told
me:
If someone downloads the spec without joining the IBTA, and
proceeds to use the spec for an implementation of the IBTA spec,
that person (company) runs the risk of being a target of patent
infringement claims by IBTA members.
Another person, wanting to remain anonymous stated to me:
In justification for this position people say that they are just
trying to get more people to join the IBTA because they need the
dues, which by coincidence are $9500 per year, and point out
that some other commonly used specs are similarly made available
for steep prices. I don't know one way or the other about that
but this sounds a lot like the reason that we all gave ourselves
for NOT including SDP in the kernel[1].
So, even if a IBTA member company creates a Linux IB implementation, and
gets it into the kernel tree, any company who ships such a
implementation, who is not a IBTA member, could be the target of any
patent infringement claims[2].
So, OpenIB group, how to you plan to address this issue? Do you all
have a position as to how you think your code base can be accepted into
the main kernel tree given these recent events?
thanks,
greg k-h
[1] SDP, for those who do not know, is a part of the IB spec that
Microsoft has come out and stated they they currently own the patents
that cover that portion of the specification, and that anyone who wants
to implement it, needs to get a licensing agreement with them. Of
course, that license agreement does not allow for a GPLed version of the
implementation.
[2] Sure, any person who has a copy of the kernel source tree could be a
target for any of a zillion other potential claims, nothing new there,
but the point here is they are explicitly stating that they will go
after non-IBTA members who touch IB code[3].
[3] An insanely stupid position to take, given the fact that any normal
industry group would be very happy to actually have people use their
specification, but hey, the IB people have never been know for their
brilliance in the past...
On Fri, 8 Oct 2004, Greg KH wrote:
> If someone downloads the spec without joining the IBTA, and
> proceeds to use the spec for an implementation of the IBTA spec,
> that person (company) runs the risk of being a target of patent
> infringement claims by IBTA members.
Another solid reason to write infiniband off. I keep hoping that the IB
vendor crowd will stop shooting themselves in the head with such
regularity, and they just won't. They just keep increasing the size of the
bore.
Infiniband can now be spelled a few different ways, "I2O" and "ATM" come
to mind, except that "ATM" was less unsuccessful in its lifetime than IB
has been so far.
> In justification for this position people say that they are just
> trying to get more people to join the IBTA because they need the
> dues, which by coincidence are $9500 per year, and point out
> that some other commonly used specs are similarly made available
> for steep prices. I don't know one way or the other about that
> but this sounds a lot like the reason that we all gave ourselves
> for NOT including SDP in the kernel[1].
> So, OpenIB group, how to you plan to address this issue? Do you all
> have a position as to how you think your code base can be accepted into
> the main kernel tree given these recent events?
Well, we non-vendors have no power, and it appears the vendors are
determined to kill IB.
This is all very discouraging. A lot of people at the Labs put a lot of
work into the Infiniband openib effort, including getting money to support
the software development, and it looks like we're not going to get very
far if these rules stick. I am going to renew my search for non-IB
solutions, I guess. It's hard to recommend this interconnect when IBTA
takes this kind of action.
ron
Greg KH <[email protected]> writes:
> [2] Sure, any person who has a copy of the kernel source tree could be a
> target for any of a zillion other potential claims, nothing new there,
> but the point here is they are explicitly stating that they will go
> after non-IBTA members who touch IB code[3].
Greg I see nothing to back up the idea that IBTA intends to go after
non-members. I simply see a disclaimer of warranty, and I see wording
by your anonymous source that restates a disclaimer of warranty.
Until I see something more to back this up I do not see a problem. In
fact I see infiniband prices dropping, and competition increasing.
The drivers off of openib.org look like they are a good start at
making a sane linux implementation.
Even the PCI-SIG requires you to pay for the spec.
I agree it would be suicidally insane for the infiniband trade
association to go after a linux stack, as it appears that a large
portion of the infiniband users are currently running linux.
Given the vendors I have seen working on hardware and the vendors
who are a part of the infiniband trade association there does appear
to be a certain amount of disconnect between the two. So this
may be an attempt to bring all of the interested parties together.
Eric
Eric W. Biederman wrote:
> Greg KH <[email protected]> writes:
>
>
>>[2] Sure, any person who has a copy of the kernel source tree could be a
>>target for any of a zillion other potential claims, nothing new there,
>>but the point here is they are explicitly stating that they will go
>>after non-IBTA members who touch IB code[3].
>
>
> Greg I see nothing to back up the idea that IBTA intends to go after
> non-members. I simply see a disclaimer of warranty, and I see wording
> by your anonymous source that restates a disclaimer of warranty.
Well, let's not rely on anonymous sources and go straight to the web
site, shall we?
Ordering copies of the spec, for non-members:
http://www.infinibandta.org/specs/How_to_Order_IBTA_Specifications.pdf
Key note: use of spec is only granted for NON-COMMERCIAL use
Now, let's look at the membership agreement for IBTA:
http://www.infinibandta.org/meminfo/mem-agreement.pdf
Key note: The point is made repeatedly that there are no patent grants
simply by being a member.
On Fri, Oct 08, 2004 at 04:49:16PM -0600, Eric W. Biederman wrote:
> Greg KH <[email protected]> writes:
>
> > [2] Sure, any person who has a copy of the kernel source tree could be a
> > target for any of a zillion other potential claims, nothing new there,
> > but the point here is they are explicitly stating that they will go
> > after non-IBTA members who touch IB code[3].
>
> Greg I see nothing to back up the idea that IBTA intends to go after
> non-members. I simply see a disclaimer of warranty, and I see wording
> by your anonymous source that restates a disclaimer of warranty.
All I know is a number of different people, from different companies are
suddenly very worried about this. The fact that they don't want to
comment on it in public leads me to believe that there is something
behind their fears.
> Until I see something more to back this up I do not see a problem. In
> fact I see infiniband prices dropping, and competition increasing.
> The drivers off of openib.org look like they are a good start at
> making a sane linux implementation.
It is a good start. And as all OpenIB members are also IBTA members, I
am asking for the group's position as to this change.
> Even the PCI-SIG requires you to pay for the spec.
I know that, almost all groups do. Although $9500 does seem a bit steep
for spec prices :)
> I agree it would be suicidally insane for the infiniband trade
> association to go after a linux stack, as it appears that a large
> portion of the infiniband users are currently running linux.
One specific IBTA member has issues with the adaption of Linux, and has
already done one thing to restrict a full IB implementation that would
work on Linux. And as for insane, have you ever tried to actually read
that spec? :)
thanks,
greg k-h
On Fri, 2004-10-08 at 19:13, Greg KH wrote:
> All I know is a number of different people, from different companies are
> suddenly very worried about this. The fact that they don't want to
> comment on it in public leads me to believe that there is something
> behind their fears.
Sounds like our favorite software company's FUD squad has been busy.
Lee
On Fri, Oct 08, 2004 at 04:13:07PM -0700, Greg KH wrote:
> > Even the PCI-SIG requires you to pay for the spec.
>
> I know that, almost all groups do. Although $9500 does seem a bit steep
> for spec prices :)
Especially as (wrt PCISIG at least) the mindshare books contain almost
exactly the same information for around $50. In fact, I find those
books are much better presented than the actual specs.
Dave
The increase in cost for the spec is rather unfortunate but I think
it's orthogonal to any IP issues. Since the Linux kernel contains a
lot of code written to specs available only under NDA (and even
reverse-engineered code where specs are completely unavailable), I
don't think the expense should be an issue.
As for IP, as far as I know, there has been no change to any of the
bylaws or other members agreements. If there is some specific
provision that concerns you, please bring it to our attention -- the
IBTA in general and the IBTA steering committee in general have been
very supportive of the OpenIB effort. In fact, most of the IBTA
steering commitee companies (Agilent, HP, IBM, InfiniCon, Intel,
Mellanox, Sun, Topspin, and Voltaire) have been active participants in
OpenIB development. I would hope we can resolve any issues relating
to open source and the Linux kernel.
However, I would suspect that we'll find the USB, Firewire, Bluetooth,
etc., etc. standards bodies all have very similar IP language in their
bylaws and licenses.
Thanks,
Roland
Greg> All I know is a number of different people, from different
Greg> companies are suddenly very worried about this. The fact
Greg> that they don't want to comment on it in public leads me to
Greg> believe that there is something behind their fears.
Hmm, I haven't heard anything. I guess I'm out of the loop.
Greg> One specific IBTA member has issues with the adaption of
Greg> Linux, and has already done one thing to restrict a full IB
Greg> implementation that would work on Linux.
Microsoft is actually no longer an IBTA member.
Thanks,
Roland
On Fri, Oct 08, 2004 at 04:27:14PM -0700, Roland Dreier wrote:
> The increase in cost for the spec is rather unfortunate but I think
> it's orthogonal to any IP issues. Since the Linux kernel contains a
> lot of code written to specs available only under NDA (and even
> reverse-engineered code where specs are completely unavailable), I
> don't think the expense should be an issue.
It isn't at all, just an odd side point.
> As for IP, as far as I know, there has been no change to any of the
> bylaws or other members agreements.
The "purchase a spec" agreement has changed, right?
> If there is some specific
> provision that concerns you, please bring it to our attention -- the
> IBTA in general and the IBTA steering committee in general have been
> very supportive of the OpenIB effort. In fact, most of the IBTA
> steering commitee companies (Agilent, HP, IBM, InfiniCon, Intel,
> Mellanox, Sun, Topspin, and Voltaire) have been active participants in
> OpenIB development. I would hope we can resolve any issues relating
> to open source and the Linux kernel.
What about the issue of not being able to use the spec for "commercial"
applications? And doesn't the member agreement not cover anyone who
implements the spec, and then gives that implementation to someone who
is not a member?
> However, I would suspect that we'll find the USB, Firewire, Bluetooth,
> etc., etc. standards bodies all have very similar IP language in their
> bylaws and licenses.
No, the USB bylaws explicitly forbid any member company from putting in,
or trying to claim any IP that is in the USB specs. That is something
that makes USB quite different from IB.
I haven't had the misfortune to have to go read the PCI SIG bylaws and
member agreement...
thanks,
greg k-h
Roland Dreier wrote:
> As for IP, as far as I know, there has been no change to any of the
> bylaws or other members agreements. If there is some specific
> provision that concerns you, please bring it to our attention -- the
> IBTA in general and the IBTA steering committee in general have been
> very supportive of the OpenIB effort. In fact, most of the IBTA
> steering commitee companies (Agilent, HP, IBM, InfiniCon, Intel,
> Mellanox, Sun, Topspin, and Voltaire) have been active participants in
> OpenIB development. I would hope we can resolve any issues relating
> to open source and the Linux kernel.
Read the member agreement :) It -explicitly- does -not- require waiving
of patent claims related to any implementation of IB.
That's different from ATA, SCSI, USB, the list goes on...
Jeff
Jeff> Read the member agreement :) It -explicitly- does -not-
Jeff> require waiving of patent claims related to any
Jeff> implementation of IB.
Jeff> That's different from ATA, SCSI, USB, the list goes on...
Fair enough, but read the Bluetooth SIG patent agreement [1]. As far
as I can tell, all it requires is that other SIG members receive a
patent license. Do we need to do rm -rf net/bluetooth? IEEE only
requires that patents be licensed under RAND terms (it does not even
require royalty free licensing) [2]. Time for rm -rf drivers/ieee1394?
The code that we have written so far is pretty standard driver code,
so I have a hard time believing that the IB drivers are any more at
risk than any other Linux code. There may be good and valid reasons
not to merge IB drivers upstream, but I'd be very disappointed if this
FUD about patents is what keeps them out.
Thanks,
Roland
[1] https://www.bluetooth.org/foundry/sitecontent/document/Patent_and_Copyright_License_Agreement
[2] http://standards.ieee.org/guides/bylaws/sect6-7.html#6
Greg> The "purchase a spec" agreement has changed, right?
Good point. I think the right way to understand this is that the
purchase agreement and the $9500 cost is intended to discourage anyone
from actually buying the spec -- for the same money you can become a
full IBTA member so why shell out for the spec with more restrictions?
This might be counterproductive but I don't think there's anything
sinister behind it.
- Roland
Roland Dreier wrote:
> Jeff> Read the member agreement :) It -explicitly- does -not-
> Jeff> require waiving of patent claims related to any
> Jeff> implementation of IB.
>
> Jeff> That's different from ATA, SCSI, USB, the list goes on...
>
> Fair enough, but read the Bluetooth SIG patent agreement [1]. As far
> as I can tell, all it requires is that other SIG members receive a
> patent license. Do we need to do rm -rf net/bluetooth? IEEE only
> requires that patents be licensed under RAND terms (it does not even
> require royalty free licensing) [2]. Time for rm -rf drivers/ieee1394?
As my mother would ask, would you jump off a cliff just because your
friend did?
If there is questionable code, that is _not_ a justification to add more.
Jeff
Roland Dreier <[email protected]> :
> it's orthogonal to any IP issues. Since the Linux kernel contains a
> lot of code written to specs available only under NDA (and even
> reverse-engineered code where specs are completely unavailable), I
> don't think the expense should be an issue.
One can say good bye to peer review.
--
Ueimor
Roland> it's orthogonal to any IP issues. Since the Linux kernel
Roland> contains a lot of code written to specs available only
Roland> under NDA (and even reverse-engineered code where specs
Roland> are completely unavailable), I don't think the expense
Roland> should be an issue.
Francois> One can say good bye to peer review.
Yes and no. Certainly people without specs can't review spec
compliance, but review for coding style, locking bugs, etc. is if
anything more valuable.
Thanks,
Roland
Jeff> If there is questionable code, that is _not_ a justification
Jeff> to add more.
I guess my point was not that the bluetooth stack is somehow
questionable, but rather that the IP policies of a standards bodies
are really not a good reason to keep code out of the kernel. If
someone can name one patent that the IB driver stack looks like it
might possibly run into, then we would have to take that very
seriously. However, no one has done this here -- all we have is FUD
or guilt by association or whatever you want to call it.
The mere fact that the IBTA bylaws only require members license their
patents under RAND terms shouldn't be an issue. If nothing else, the
fact that there are hugely more non-IBTA member companies than member
companies who might have patents makes the IBTA bylaws almost a moot
point.
For what its worth, I know of at least five companies shipping IB
stacks and the only patent licensing that I know of is the Microsoft
SDP license, and even that is really just CYA: all Microsoft says is
that they _might_ have patents that cover SDP and that they will
license them at no cost to anyone who wants them; unfortunately this
license is not GPL-compatible, but for proprietary stacks the
zero-cost terms look fine. There are people who have looked at
Microsoft's patents and concluded that none of them actually apply to
SDP as specified by the IBTA.
Thanks,
Roland
On Sad, 2004-10-09 at 22:11, Roland Dreier wrote:
> I guess my point was not that the bluetooth stack is somehow
> questionable, but rather that the IP policies of a standards bodies
> are really not a good reason to keep code out of the kernel. If
> someone can name one patent that the IB driver stack looks like it
> might possibly run into, then we would have to take that very
> seriously. However, no one has done this here -- all we have is FUD
> or guilt by association or whatever you want to call it.
Its called "caution". It's why nobody does innovation in the USA any
more, its too dangerous to innovate. Far better to make it available as
before with a blue led and a beeper.
> The mere fact that the IBTA bylaws only require members license their
> patents under RAND terms shouldn't be an issue. If nothing else, the
> fact that there are hugely more non-IBTA member companies than member
> companies who might have patents makes the IBTA bylaws almost a moot
> point.
The big question seems to be about the standard itself. Are the items at
issue hardware or software ? We already deal with a lot of devices that
have hardware related patent pools and those by themselves don't seem to
cause problems.
In the mean time I guess the guys down in Bristol[1] will be feeling
happier and happier at the Infiniband self destruct sequence.
Alan
[1] Quadrics
Alan> The big question seems to be about the standard itself. Are
Alan> the items at issue hardware or software ? We already deal
Alan> with a lot of devices that have hardware related patent
Alan> pools and those by themselves don't seem to cause problems.
As far as I know there are no items at issue. No one has suggested
that there actually are any patents to worry about. The big complaint
is just that the IBTA member companies haven't made enough promises
about their patents.
The OpenIB subversion repository can be checked out by anyone
interested. Anyone who wants to can look the code over and look for
something patent encumbered.
Thanks,
Roland
Well, fortunately this has turned out to be a non-issue.
I just went to http://www.infinibandta.org and the 1.2 spec is available for
download.
http://www.infinibandta.org/specs/register/publicspec/vol1r1_2.zip
http://www.infinibandta.org/specs/register/publicspec/vol2r1_2.zip
Roland Dreier wrote:
> Roland> it's orthogonal to any IP issues. Since the Linux kernel
> Roland> contains a lot of code written to specs available only
> Roland> under NDA (and even reverse-engineered code where specs
> Roland> are completely unavailable), I don't think the expense
> Roland> should be an issue.
>
> Francois> One can say good bye to peer review.
>
>Yes and no. Certainly people without specs can't review spec
>compliance, but review for coding style, locking bugs, etc. is if
>anything more valuable.
>
>Thanks,
> Roland
>_______________________________________________
>openib-general mailing list
>[email protected]
>http://openib.org/mailman/listinfo/openib-general
>
>To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
>