LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "David Schwartz" <davids@webmaster.com>
To: <khc@pm.waw.pl>
Cc: <Valdis.Kletnieks@vt.edu>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Ingo Molnar" <mingo@elte.hu>,
	"Arnaldo Carvalho de Melo" <acme@ghostprotocols.net>,
	<linux-kernel@vger.kernel.org>, "Alan Cox" <alan@redhat.com>
Subject: RE: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.
Date: Tue, 26 Feb 2008 15:35:21 -0800	[thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKGEBIKLAC.davids@webmaster.com> (raw)
In-Reply-To: <m3ir0bcnvo.fsf@maximus.localdomain>


> "David Schwartz" <davids@webmaster.com> writes:

> > The agreement made when the feature was added was that
> > EXPORT_GPL was not a
> > license enforcement mechanism but was an indication that
> > someone believed
> > that any use of the symbol was possible only a derivative work
> > that would
> > need to be distributed under the GPL.

> But the above gives us nothing.
> *If* any use of non-GPL symbols only by a binary module was ok then it
> would make sense.

I don't buy your argument. It's essentially saying that a scheme that can't
detect all possible problems is useless, even if it can detect some
problems.

> >> Actually I think the _GPL exports are really harmful - somebody
> >> distributing a binary module may claim he/she doesn't violate the GPL
> >> because the module uses only non-GPL exports.

> > Anyone can argue anything. That would be an obviously stupid argument.
> > Perhaps clearer documentation might be helpful, but the GPL speaks for
> > itself.

> Not sure if the court would share this opinion.
> Defendant: my module doesn't use any GPL-only export!
> Plaintiff: but using XXX normal symbol is a violation too!
> D: so why have you created that _GPL thing exactly?

This is akin to "Maybe I was swerving, but I must have been driving safely
because I wasn't drunk". Everyone who drives drunk isn't safe, but it
doesn't follow that you're safe just because you're not drunk.

This is an obviously-wrong argument, and the fact that someone can make it
isn't interesting. People can make all kinds of obviously-wrong arguments.

Maybe this is a documentation issue.

The GPL exports mark symbols that someone felt could not be used in a
non-derivative work, "intimate details" if you like. But whether or not
something is a derivative work is a pure question of copyright law and the
nature of what was taken. (One could make an argument that not marking
symbols acts as some kind of estoppel against later arguing that just
minimally using that symbol can't make your work a derivative. It's possible
a judge might by that argument, but if so, how is that unreasonable?)

> Additionally:
> D: top of the COPYING file explicity states binary modules are ok.

I don't think anybody really knows what legal effect that will have. I can
speculate, but I don't know that my speculations are particularly
interesting. If anyone wants my analysis of that, feel free to email me
off-list.

> This is of course fine if we consider normal use of non-GPL-only
> symbols ok.

It's fine either way. Whatever you feel about non-GPL-only symbols, there's
nothing wrong with marking some symbols that, in the opinion of their
copyright holders, cannot be used by non-derivative works. If this is what
the GPL symbol marking does (which is what was agreed to when it was added)
then there's no harm.

> > They serve as a warning and, as a practical matter, may make it
> > a bit more
> > difficult to violate the license.

> Technically only.

All you can do in code is implement technical things. You cannot enforce or
implement the license because the GPL prohibits that.

> I have to agree with Alan that the list of non-GPL modules only is
> quite tiny nowadays. Madwifi is in terminal state, ATI is opening the
> docs and working on GPL driver, modem drivers are mostly thing of
> the past, NVidias will probably be supported by the open source driver
> soon even if they don't open their code.
>
> Embedded devices have full Linux, not just modules.

If you're arguing that GPL symbol export has outlived its usefulness, that
might be true. I don't really have an opinion one way or the other.

DS



  reply	other threads:[~2008-02-26 23:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 17:59 Valdis.Kletnieks
2008-02-25 18:23 ` Steven Rostedt
2008-02-25 18:19   ` Alan Cox
2008-02-25 19:27     ` Adrian Bunk
2008-02-25 19:48       ` Alan Cox
2008-02-25 20:09         ` Adrian Bunk
2008-02-25 20:38           ` Alan Cox
2008-02-25 21:17       ` Valdis.Kletnieks
2008-02-26  1:30   ` David Schwartz
2008-02-26 12:29     ` Alan Cox
2008-02-26 15:43     ` Krzysztof Halasa
2008-02-26 17:04       ` Krzysztof Halasa
2008-02-26 17:21         ` Alan Cox
2008-02-26 17:44           ` Krzysztof Halasa
2008-02-26 18:04             ` Alan Cox
2008-02-26 18:19       ` David Schwartz
2008-02-26 23:13         ` Krzysztof Halasa
2008-02-26 23:35           ` David Schwartz [this message]
2008-02-27  0:05             ` Krzysztof Halasa
2008-02-27  0:28               ` David Schwartz
2008-02-27 10:31           ` Alan Cox
2008-02-27 10:55             ` Krzysztof Halasa

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=MDEHLPKNGKAHNMBLJOLKGEBIKLAC.davids@webmaster.com \
    --to=davids@webmaster.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=acme@ghostprotocols.net \
    --cc=akpm@linux-foundation.org \
    --cc=alan@redhat.com \
    --cc=khc@pm.waw.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --subject='RE: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).