linux-kernel - Re: scsi target, likely GPL violation

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 9 Nov 2012 11:03:36 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	nab@...ingtidesystems.com
Cc:	Andy Grover <agrover@...hat.com>,
	Chris Friesen <chris.friesen@...band.com>,
	Jon Mason <jdmason@...zu.us>,
	target-devel <target-devel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Marc Fleischmann <mwf@...ingtidesystems.com>
Subject: Re: scsi target, likely GPL violation

> For our commercial target core, we only use Linux kernel symbols that
> are not marked as GPL. In addition, we define the API between the target

And this has what meaning ?

The Linux kernel is a GPL work, any derivative work is a GPL work. The
symbol tags are just a guidance.

You do not have permission to build a non GPL derivative work of any code
I own. The licensing determination is *derivative work* not symbols
marked with _GPL. This has been stated publically by many developers many
times.

So either your work is truely not derivative of the kernel (which I find
wildly improbable) or you have a problem and since you are aware of the
complaints publically I guess probably a triple damages sized problem. But
that's one for your lawyers and whatever opinion they have on the subject.

You do btw have a second thing to consider - there are US patent grants
for some functions in the kernel that only extend to GPL code so utilising
some of the subsystems in the USA may give you other problems even if you
can somehow manage to demonstrate your work is not derivative.

> RTS OS is based on a stock Linux enterprise kernel. This Linux kernel
> has naturally the ability to load either one of our standalone
> self-contained target module versions without any modifications.

That's not the usual test for derivative work I've heard applied.

I fail to understand the maintainer question however. If you were trying
to block people adding target features that competed that would be a
different thing.

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/