[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190996839.18681.68.camel@chaos>
Date: Fri, 28 Sep 2007 18:27:19 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: David Miller <davem@...emloft.net>
Cc: urs@...ogud.escape.de, shemminger@...ux-foundation.org,
netdev@...r.kernel.org, kaber@...sh.net, joe@...ches.com,
oliver@...tkopp.net, oliver.hartkopp@...kswagen.de
Subject: Re: [PATCH 2/7] CAN: Add PF_CAN core module
On Tue, 2007-09-25 at 14:09 -0700, David Miller wrote:
> > > Then please make all exported symbols marked EXPORT_SYMBOL_GPL to make
> > > sure that the other CAN protocol can not reuse your infrastructure.
> >
> > We don't want to force other CAN protocol implementations to be GPL
> > also. AFAIR from discussions on LKML, it was mostly agreed upon that
> > this decision is up to the authors of code.
>
> To a certain extent, yes.
>
> However, the core issue is whether anyone who uses the symbol
> is creating a derivative work. If it is pretty clear that this
> is the case, you really should mark the exported symbols GPL.
>
> In my opinion, in this case it is pretty clear that any use of
> these new symbols would be a derivative work and therefore they
> all should be marked GPL.
Hmm, the code in question is dual licensed. So it's not that clear to
me.
But it's a legal grey area anyway if somebody loads non GPL code into
the kernel, though IANAL and we can spend years on this discussion.
I'm not inclined either way and we really should not make this a
religious question whether that code goes in or not, especially not when
we granted the mac80211 to export everything w/o _GPL suffix not too
long ago.
Thanks,
tglx
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists