After reading the posts about the MODULE_LICENSE macro, I am in disbelief. I
was under the impression that one could write a "closed-source" module and
distribute it in binary form, and be in compliance. Please tell me I am
wrong? We use Linux as a platform for some data acquisition, and we are
currently distributing ( in very limited quantity to people who would already
have signed an NDA ) modules that currently have no official license as yet.
We are researching which license to use, but according to these post's we
have almost no choice, Open Source or not at all!
-kw
"Kevin D. Wooten" wrote:
>
> After reading the posts about the MODULE_LICENSE macro, I am in disbelief. I
> was under the impression that one could write a "closed-source" module and
> distribute it in binary form, and be in compliance. Please tell me I am
> wrong? We use Linux as a platform for some data acquisition, and we are
> currently distributing ( in very limited quantity to people who would already
> have signed an NDA ) modules that currently have no official license as yet.
> We are researching which license to use, but according to these post's we
> have almost no choice, Open Source or not at all!
No, you just can't use certain symbols if you're not GPL. If your
code already works, then you're fine, as previously existing symbols
will not be thus restricted... You can just make your MODULE_LICENSE == "mine-all-mine...including-all-my-bugs"
Ben
>
> -kw
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
Ben Greear wrote:
>
> "Kevin D. Wooten" wrote:
> >
> > After reading the posts about the MODULE_LICENSE macro, I am in disbelief. I
> > was under the impression that one could write a "closed-source" module and
> > distribute it in binary form, and be in compliance. Please tell me I am
> > wrong? We use Linux as a platform for some data acquisition, and we are
> > currently distributing ( in very limited quantity to people who would already
> > have signed an NDA ) modules that currently have no official license as yet.
> > We are researching which license to use, but according to these post's we
> > have almost no choice, Open Source or not at all!
>
> No, you just can't use certain symbols if you're not GPL. If your
> code already works, then you're fine, as previously existing symbols
> will not be thus restricted... You can just make your MODULE_LICENSE == "mine-all-mine...including-all-my-bugs"
Ugghh! Don't confuse/equate MODULE_LICENSE with EXPORT_SYMBOL_GPL_ONLY;
two different animals, two differnet goals. See archives for more info.
>
> Ben
>
> >
> > -kw
> > -
--
===============
-- TimO
--------------------==============++==============--------------------
No Cool .sig
TimO wrote:
>
> Ben Greear wrote:
> >
> > "Kevin D. Wooten" wrote:
> > >
> > > After reading the posts about the MODULE_LICENSE macro, I am in disbelief. I
> > > was under the impression that one could write a "closed-source" module and
> > > distribute it in binary form, and be in compliance. Please tell me I am
> > > wrong? We use Linux as a platform for some data acquisition, and we are
> > > currently distributing ( in very limited quantity to people who would already
> > > have signed an NDA ) modules that currently have no official license as yet.
> > > We are researching which license to use, but according to these post's we
> > > have almost no choice, Open Source or not at all!
> >
> > No, you just can't use certain symbols if you're not GPL. If your
> > code already works, then you're fine, as previously existing symbols
> > will not be thus restricted... You can just make your MODULE_LICENSE == "mine-all-mine...including-all-my-bugs"
>
> Ugghh! Don't confuse/equate MODULE_LICENSE with EXPORT_SYMBOL_GPL_ONLY;
> two different animals, two differnet goals. See archives for more info.
Ok, but regardless of the politics, if you're not GPL as was the original
poster's issued, then you will not be able to use the GPL_ONLY symbols,
right? They aren't the same, but they are inter-related, unless I completely
mis-understand....
Ben
--
Ben Greear <[email protected]> <Ben_Greear AT excite.com>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
> After reading the posts about the MODULE_LICENSE macro, I am in disbelief. I
> was under the impression that one could write a "closed-source" module and
> distribute it in binary form, and be in compliance. Please tell me I am
Providing your work constitutes a seperate work that isn't a derivative
work. Thats a lawyer definition and one for lawyers
> wrong? We use Linux as a platform for some data acquisition, and we are
> currently distributing ( in very limited quantity to people who would already
> have signed an NDA ) modules that currently have no official license as yet.
> We are researching which license to use, but according to these post's we
> have almost no choice, Open Source or not at all!
The tag is purely so we can tell free stuff apart. If you tag a module
MODULE_LICENSE("(c) Copyright EvilCorp, All rights wronged");
it will still load but the user will be advised not to report bugs to the
kernel lists and the like. The oops data will similarly be marked "tainted"
so that we can discard it.
It's a filter so we don't have to handle bugs in your driver, nothing more.
On Monday 29 October 2001 21:58, TimO wrote:
> Ben Greear wrote:
> > "Kevin D. Wooten" wrote:
> > > After reading the posts about the MODULE_LICENSE macro, I am in
> > > disbelief. I was under the impression that one could write a
> > > "closed-source" module and distribute it in binary form, and be in
> > > compliance. Please tell me I am wrong? We use Linux as a platform for
> > > some data acquisition, and we are currently distributing ( in very
> > > limited quantity to people who would already have signed an NDA )
> > > modules that currently have no official license as yet. We are
> > > researching which license to use, but according to these post's we have
> > > almost no choice, Open Source or not at all!
> >
> > No, you just can't use certain symbols if you're not GPL. If your
> > code already works, then you're fine, as previously existing symbols
> > will not be thus restricted... You can just make your MODULE_LICENSE ==
> > "mine-all-mine...including-all-my-bugs"
>
> Ugghh! Don't confuse/equate MODULE_LICENSE with EXPORT_SYMBOL_GPL_ONLY;
> two different animals, two differnet goals. See archives for more info.
>
My apologies for the misinterpretation.
This scheme seems fine as long as driver related symbols are not "GPL" only.
> > Ben
> >
> > > -kw
> > > -
TimO wrote:
> Ugghh! Don't confuse/equate MODULE_LICENSE with EXPORT_SYMBOL_GPL_ONLY;
> two different animals, two differnet goals. See archives for more info.
What happens is a module is distributed as a combination of open-source .c
files and closed-source .o files. That is, it's "mixed source" - part of the
driver is open-source and part is closed-source. What happens if the
open-source version of the driver is the only code that uses GPL-only symbols.
How is that handled?
> files and closed-source .o files. That is, it's "mixed source" - part of the
> driver is open-source and part is closed-source. What happens if the
> open-source version of the driver is the only code that uses GPL-only symbols.
> How is that handled?
Well then the open source bit would be GPL which would mean you can;t link
it with the binary bit.
Alan
Alan Cox wrote:
>>files and closed-source .o files. That is, it's "mixed source" - part of the
>>driver is open-source and part is closed-source. What happens if the
>>open-source version of the driver is the only code that uses GPL-only symbols.
>> How is that handled?
>>
>
> Well then the open source bit would be GPL which would mean you can;t link
> it with the binary bit.
Ah, but what happens if I distribute the source code, the closed-source .o
files, and a makefile, and tell people that they should link it? Am I
violating the GPL, or is the end-user?
> Ah, but what happens if I distribute the source code, the closed-source .o
> files, and a makefile, and tell people that they should link it? Am I
> violating the GPL, or is the end-user?
I am told by legal people you are, because you provided the code soley with
the intent that it was used that way. Whether an imaginative lawyer can
also get you locked away under the DMCA for distributing a device for
violating copyright I dont know 8)
It is actually all very simple in legal terms. The legal terminology is
"derivative work" and basically if its a derivative work of a GPL work its
GPL if not it isnt. Thats what "linking" is about - not /bin/ld.
If you wanted to provide a mixed source/binary driver that wasnt derivative
of the kernel (and there are lots of reasons for it) - don't GPL your
open source bit use something like MPL or BSD
[I am not a laywer ...]
Alan
Alan Cox wrote:
>>Ah, but what happens if I distribute the source code, the closed-source .o
>>files, and a makefile, and tell people that they should link it? Am I
>>violating the GPL, or is the end-user?
>>
>
> I am told by legal people you are, because you provided the code soley with
> the intent that it was used that way. Whether an imaginative lawyer can
> also get you locked away under the DMCA for distributing a device for
> violating copyright I dont know 8)
But the GPL only covers distribution, not use. Just because I distribute GPL
source code, doesn't mean that it actually has to work or do something. The
open source portions of the driver conform to the GPL, because they #include
kernel header files and, in some case, cut-and-paste from the kernel source
itself. The closed source portions do not #include any kernel header files or
use any source code from anyone else.
The fact that the open source portions and the closed source portions can't
function on their own is irrelevant, IMHO.
Please show me where in the GPL text it says that the act of compiling a
module and loading it into memory is subject to the GPL.
> If you wanted to provide a mixed source/binary driver that wasnt derivative
> of the kernel (and there are lots of reasons for it) - don't GPL your
> open source bit use something like MPL or BSD
Our open source bits are GPL because they are "derived" from the kernel
source, which is also GPL.
FYI, I don't consider including a header file basis for calling the module
"derived" from that header file, but that's just my personal opinion and
doesn't really affect this discussion.
> Our open source bits are GPL because they are "derived" from the kernel
> source, which is also GPL.
Thanks I've filed that statement should it ever be useful.
> FYI, I don't consider including a header file basis for calling the module
> "derived" from that header file, but that's just my personal opinion and
> doesn't really affect this discussion.
Interface definitions tend to be treated a little differently to "code". But
as I keep trying to beat into people - if you are going to mix GPL and non
GPL code see a lawyer - thats what they are there for
On Wed, 31 Oct 2001, Timur Tabi wrote:
> The fact that the open source portions and the closed source portions
> can't function on their own is irrelevant, IMHO.
>
> Please show me where in the GPL text it says that the act of compiling a
> module and loading it into memory is subject to the GPL.
That'd be paragraph 2 b)
b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.
... These requirements apply to the modified work as a whole.
Since your program, which happens to consist of one open
source part and one proprietary part, is partly a derived
work from the kernel source (by using kernel header files
and the inline functions in it) your whole work must be
distributed under the GPL.
> > If you wanted to provide a mixed source/binary driver that wasnt derivative
> > of the kernel (and there are lots of reasons for it) - don't GPL your
> > open source bit use something like MPL or BSD
>
> Our open source bits are GPL because they are "derived" from the kernel
> source, which is also GPL.
"open source bits" ... from "the work as a whole" ?
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
> Since your program, which happens to consist of one open
> source part and one proprietary part, is partly a derived
> work from the kernel source (by using kernel header files
> and the inline functions in it) your whole work must be
> distributed under the GPL.
This is obviously incorrect, that would say that
#include <sys/types.h>
means my app is now GPLed. Good luck enforcing that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 31 Oct 2001, Larry McVoy wrote:
> > Since your program, which happens to consist of one open
> > source part and one proprietary part, is partly a derived
> > work from the kernel source (by using kernel header files
> > and the inline functions in it) your whole work must be
> > distributed under the GPL.
>
> This is obviously incorrect, that would say that
>
> #include <sys/types.h>
>
> means my app is now GPLed. Good luck enforcing that.
You're right, just including <sys/types.h> won't do that,
but either of:
1) using inline functions from a .h file or
2) linking to the library/kernel later on
might mean your stuff is GPLed.
Be careful which definitions you get from the
header file, inline functions are a very grey
area ;)
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
Rik van Riel wrote:
> Since your program, which happens to consist of one open
> source part and one proprietary part, is partly a derived
> work from the kernel source (by using kernel header files
> and the inline functions in it) your whole work must be
> distributed under the GPL.
I contest your meaning of the word "work". The open source portion of my
module is one "work", and the closed source portion is another "work". I
could deliver these two works as separate tarballs, if I wanted.
Not only that, but the closed-source portion of my driver is not derived from
any GPL program, so the phrase "contains or is derived from the Program" does
not apply to it, because it:
1. Does not contain any part of any GPL Program
2. Is not derived from any GPL Program
>>Our open source bits are GPL because they are "derived" from the kernel
>>source, which is also GPL.
>
> "open source bits" ... from "the work as a whole" ?
The point I'm trying to make is that I can play the semantics game very
easily, and still not be forced to open-source the closed-source portions of
my driver. Because of the way Linux loads modules, I could take all the
open-source portions and link them into one .o file, and then insmod that .o
file without any problems. Then the closed-source portion would also be
insmod'ed. The only issue is that closed-source portion would fail to load if
the open-source portion is not already loaded.
On Wed, 31 Oct 2001, Larry McVoy wrote:
> > Since your program, which happens to consist of one open
> > source part and one proprietary part, is partly a derived
> > work from the kernel source (by using kernel header files
> > and the inline functions in it) your whole work must be
> > distributed under the GPL.
>
> This is obviously incorrect, that would say that
>
> #include <sys/types.h>
>
> means my app is now GPLed. Good luck enforcing that.
glibc is GLPL ... not GPL ...
-dean
On Wed, 31 Oct 2001, Timur Tabi wrote:
> Rik van Riel wrote:
>
> > Since your program, which happens to consist of one open
> > source part and one proprietary part, is partly a derived
> > work from the kernel source (by using kernel header files
> > and the inline functions in it) your whole work must be
> > distributed under the GPL.
>
> I contest your meaning of the word "work". The open source portion of
> my module is one "work", and the closed source portion is another
> "work". I could deliver these two works as separate tarballs, if I
> wanted.
Let me quote you, from 2 emails back in the thread:
"The fact that the open source portions and the closed source portions
can't function on their own is irrelevant, IMHO."
The irrelevance here is IYHO ... it may well be judged that
since these two portions of the work need each other in order
to function, the thing really is one work.
You're well into the danger zone here...
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
> The irrelevance here is IYHO ... it may well be judged that
> since these two portions of the work need each other in order
> to function, the thing really is one work.
a)
vmware for linux needs a linux kernel to work. does that meen
you whant to gpl it?
b)
you can write abstraction modules for different os's. and the
non-gpl module works with all of them. so my module does not
need the linux abstraction module it also works with the free-
BSD module. the only #ifdef in my module will be around the
module registration code. or i write a propriatary loader,
so that even the same binary works for different os's
--
****** It's nice to be important, but it's more important to be nice ! ******
On Wed, Oct 31, 2001 at 03:27:31PM -0200, Rik van Riel wrote:
> You're right, just including <sys/types.h> won't do that,
> but either of:
>
> 1) using inline functions from a .h file or
> 2) linking to the library/kernel later on
>
> might mean your stuff is GPLed.
>
> Be careful which definitions you get from the
> header file, inline functions are a very grey
> area ;)
[Please: read the whole message before flaming, OK? Thanks]
The reason they are not gray areas is this:
virus licenses such as the GPL can't cross over well defined boundaries.
If they could, then the fact that the kernel is GPLed would make any
application that is run on top of the kernel also GPLed. The commonly
held belief that userland is somehow different than the kernel is just
that, a belief. In the eyes of the law it's all a big pile of code
running together. We draw the distinction between running and linking
but that is arbitrary, and while it makes sense to us, I challenge
someone to prove that it makes sense to the courts.
Noone believes that just running an application makes it GPLed, not
even Stallman. In fact, he acknowledges the boundary issue when he says:
"These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections..."
While some people might like you to believe that the FSF gets to
interpret what "can be reasonably considered independent", they don't.
Remember, just because you write something in a contract doesn't mean it
is enforceable. For example, you could sign a contract that says that
you belong to me and I can do whatever I want with you, but that's never
going to be enforceable, for the obvious reasons. There are all sorts
of laws, in pretty much all societies, which override anything too wacky
put into a contract. A good example of how much this is ignored is the
typical employment agreement that everyone makes you sign in California.
It's not worth the paper it is written on, California has laws on the
books which make that clear, yet companies use the fact that people
are ignorant to get away with it. But if those same companies are
challenged in court, as they frequently are, they will lose. And they
know it, they are just playing the odds.
Getting back to the GPL, the point is that neither the FSF nor the
copyright holders get to arbitrarily decide what is and is not separable.
One could certainly try, for example, to say that running a program on
GPLed kernel makes the program GPLed. It's not going to work though.
Keep that in mind when thinking about what is or is not GPLed.
I think another way to look at it might be: if you extend a GPLed program
using well defined interfaces, you can probably get away with not GPLing
your code. You may have to fight for it and it generally isn't worth
the fight, but you could win and it is likely that you'd win.
On the other hand, if you're in there changing how an existing GPLed
program works, and there isn't any way to pull your stuff out cleanly,
then you are definitely stuck with the GPL. And that's as it should be,
you are in GPLed code. And even if you could get away with winning a
court battle, you have to ask yourself if it is worth it. In my opinion,
it's relatively rare that changes to the kernel are really worth the fuss.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 31 Oct 2001, Larry McVoy wrote:
> I think another way to look at it might be: if you extend a GPLed
> program using well defined interfaces, you can probably get away with
> not GPLing your code.
> On the other hand, if you're in there changing how an existing GPLed
> program works, and there isn't any way to pull your stuff out cleanly,
> then you are definitely stuck with the GPL. And that's as it should
> be, you are in GPLed code.
Fully agreed. From what I read, Timur is somewhere halfway
between these points and I'm not sure he can get away with
not GPLing his work the way he does things now...
regards,
Rik
--
DMCA, SSSCA, W3C? Who cares? http://thefreeworld.net/
http://www.surriel.com/ http://distro.conectiva.com/
On Wed, 31 Oct 2001, Larry McVoy wrote:
> I think another way to look at it might be: if you extend a GPLed
> program using well defined interfaces, you can probably get away with
> not GPLing your code.
I imagine the question then arises to whether even the "EXPORT_SYMBOL_GPL"
interfaces fall under the definition of a well-defined interface. I
suppose (IANAL) that the "intent" of the author in marking this interface
as GPL-only has some impact on the discussion?
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
>> The fact that the open source portions and the closed source portions
>> can't function on their own is irrelevant, IMHO.
>>
>> Please show me where in the GPL text it says that the act of compiling a
>> module and loading it into memory is subject to the GPL.
>
>That'd be paragraph 2 b)
>
> b) You must cause any work that you distribute or publish, that in
> whole or in part contains or is derived from the Program or any
> part thereof, to be licensed as a whole at no charge to all third
> parties under the terms of this License.
>
>... These requirements apply to the modified work as a whole.
>
>Since your program, which happens to consist of one open
>source part and one proprietary part, is partly a derived
>work from the kernel source (by using kernel header files
>and the inline functions in it) your whole work must be
>distributed under the GPL.
False. Please cite the section of the GPL version 2 that you
think means that the derived work, once created, *must be
distributed*. If you read closely, I think you will find that it says
that *if* you distribute the mixed work, then then it must be
distributed under the the terms of the GPL. If you do *not*
distribute the mixed work, then the GPL does not place any
restrictions on your use of the derived work. In other words, the
restrictions imposed by the GPL are conditional upon the derived
work's actual distribution: no distribution, no restrictions.
Furthermore, "loading into memory" is (arguably) considered an
essential part of running a program, and section 0 of the GPL version
2 says:
The act of running the Program is not restricted,
I should insert the usual disclaimer: I am not a lawyer.
Craig Milo Rogers
>> Since your program, which happens to consist of one open
>> source part and one proprietary part, is partly a derived
>> work from the kernel source (by using kernel header files
>> and the inline functions in it) your whole work must be
>> distributed under the GPL.
>
>This is obviously incorrect, that would say that
>
> #include <sys/types.h>
>
>means my app is now GPLed. Good luck enforcing that.
Your compiled object module might be a derived work, hence its
distribution would be restricted by the terms of the GPL version 2.
Your source code file would not be a derived work (under certain
currently widely-held assumptions about interface copyrights), and
hence could be distributed without restriction by the GPL.
Usual disclaimer: I am not a lawyer.
Craig Milo Rogers
>> This is obviously incorrect, that would say that
>>
>> #include <sys/types.h>
>>
>> means my app is now GPLed. Good luck enforcing that.
>
>You're right, just including <sys/types.h> won't do that,
>but either of:
>
>1) using inline functions from a .h file or
>2) linking to the library/kernel later on
>
>might mean your stuff is GPLed.
>
>Be careful which definitions you get from the
>header file, inline functions are a very grey
>area ;)
I think discussions of copyright issues need more precision
than "your stuff", please.
The object module resulting from compiling the code fragment
above ("#include ...") might be a derived work of both the code
fragment and the (GPL'd) header file, thus subject to the restrictions
of the GPLv2. The original source code itself would not be subject to
the GPLv2, because "<sys/types.h>" is not itself a copyrightable
string (although it could be trademarked, of course, which might lead
to the same effect).
Using, in the non-GPLv2-compliant source file, any symbol name
included from the GPL'd header file, has been commonly assumed not to
taint the source file itself with the restrictions of the GPLv2. This
is more of a grey area, because the use of these symbols over a block
of code could easily construct a derivation of a usage pattern that
was copyrighted in the interface definition document.
Usual disclaimer: I am not a lawyer.
Craig Milo Rogers
>The irrelevance here is IYHO ... it may well be judged that
>since these two portions of the work need each other in order
>to function, the thing really is one work.
>
>You're well into the danger zone here...
All of the licensing terms in the GPL are subject to change by
a court of law, or by legislative action. Nonethless, Copyright law
is generally agreed (IMHO, and based on past discussions of this topic
on this and other inappropriate forums) to be based on textual
derivation rather than functional dependency.
Usual disclaimer: I am not a lawyer.
Craig Milo Rogers
The GPL 2.0 uses language that makes it pretty clear that it was meant to
describe the source code, not the object module. It uses "source code" to
refer to what is licensed under the GPL several times.
The GPL has been a great source for nebulous debates without much in the
way of solid ground to stand on. It's not remarkable that it has a history
in academia.
Too bad those who drafted the GPL were not (competent) lawyers, either.
} Your compiled object module might be a derived work, hence its
} distribution would be restricted by the terms of the GPL version 2.
} Your source code file would not be a derived work (under certain
} currently widely-held assumptions about interface copyrights), and
} hence could be distributed without restriction by the GPL.
}
} Usual disclaimer: I am not a lawyer.
}
} Craig Milo Rogers
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at http://www.tux.org/lkml/
Cort Dougan wrote:
> The GPL 2.0 uses language that makes it pretty clear that it was meant to
> describe the source code, not the object module.
The GPL describes _both_ the source and object code forms of the program.
See section 3, "You may copy and distribute the Program (...) in _object
code or executable form_ under the terms of sections 1 and 2 above
provided that you _also do one of the following:_ ..."
The terms to be followed for object code and executable form are given
explicitly in section 3.
> It uses "source code" to refer to what is licensed under the GPL
> several times.
Actually, section 0 defines what is licensed: "This License applies to
any _program_ or other work which contains a notice placed by the
copyright holder saying it may be distributed under the terms of this
General Public License.
If we are picky, you are right that this does not appear to refer to an
object module _if_ the object module doesn't contain the license notice.
(This may perhaps be unfortunate wording in the GPL (IANAL either)).
(Lucky that newer kernel modules _do_ contain a license notice, isn't it?)
But if you take that strict interpretation, you have _no_ right to copy
or distribute the object module anyway, except as granted by the license
on the accompanying source code.
In other words, the GPL doesn't have to "apply" to the object module to
deny you the right to copy it. You start with no right to copy the
object module _at all_, except as granted by the copyright owners.
-- Jamie
On Wed, Oct 31, 2001 at 11:47:07PM +0000, Jamie Lokier wrote:
> But if you take that strict interpretation, you have _no_ right to copy
> or distribute the object module anyway, except as granted by the license
> on the accompanying source code.
Right you are, but this is trivial to circumvent if you are trying to ship
a binary driver. The binary doesn't have GPLed code, you are shipping two
things which are not combined when they were shipped, the end user combines
them when running them.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
> On Wed, Oct 31, 2001 at 11:47:07PM +0000, Jamie Lokier wrote:
> > But if you take that strict interpretation, you have _no_ right to copy
> > or distribute the object module anyway, except as granted by the license
> > on the accompanying source code.
>
> Right you are, but this is trivial to circumvent if you are trying to ship
> a binary driver. The binary doesn't have GPLed code, you are shipping two
> things which are not combined when they were shipped, the end user combines
> them when running them.
Indeed, the very old, never resolved, "user does the link" argument again.
I honestly don't know what a court of law would decide on that. It may
well be different in different jurisdictions.
-- Jamie
> Too bad those who drafted the GPL were not (competent) lawyers, either.
Actually the GPL was drafted by lawyers. Any license when you dig at the
edges of how to exploit it gets just as nebulous, as horribly enough does
copyright law.
The merging one is analogous to other fun things like in the US if a java
applet violates a patent when executed is it the web site or the browser
user who broke the rules...
Alan-
Come on, this is the US. You sue BOTH the web site AND the browser
user (and the browser, the browser maker, the ISP that provided access,
Sun for designing Java with this capability, ...) :-)
On Thu, Nov 01, 2001 at 12:43:28AM +0000, Alan Cox wrote:
> > Too bad those who drafted the GPL were not (competent) lawyers, either.
>
> Actually the GPL was drafted by lawyers. Any license when you dig at the
> edges of how to exploit it gets just as nebulous, as horribly enough does
> copyright law.
>
> The merging one is analogous to other fun things like in the US if a java
> applet violates a patent when executed is it the web site or the browser
> user who broke the rules...
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/652-0870x117
Rik van Riel writes:
> On Wed, 31 Oct 2001, Timur Tabi wrote:
>> The fact that the open source portions and the closed source
>> portions can't function on their own is irrelevant, IMHO.
...
> Since your program, which happens to consist of one open
> source part and one proprietary part, is partly a derived
> work from the kernel source (by using kernel header files
> and the inline functions in it) your whole work must be
> distributed under the GPL.
You could define a generic device driver interface.
Let's call it UDI. Now you implement a GPL version of
this for Linux, a 2-clause BSD version for FreeBSD,
and a proprietary version for Windows. You then write a
few drivers using this interface, under a half-dozen
different licenses.
One of those drivers is proprietary. It can run in the
Linux kernel. It sure isn't derived from Linux though.
There isn't any Linux code in it, and the driver works
in the Windows and FreeBSD kernels as well as in Linux.
There you go: use of GPL symbols from a non-GPL driver.
(usual disclaimer applies: not legal advice, see a lawyer)
On Tuesday 30 October 2001 18:27, Timur Tabi wrote:
> TimO wrote:
> > Ugghh! Don't confuse/equate MODULE_LICENSE with EXPORT_SYMBOL_GPL_ONLY;
> > two different animals, two differnet goals. See archives for more info.
>
> What happens is a module is distributed as a combination of open-source .c
> files and closed-source .o files. That is, it's "mixed source" - part of
> the driver is open-source and part is closed-source. What happens if the
> open-source version of the driver is the only code that uses GPL-only
> symbols. How is that handled?
>
This is the approach I would use:
Kernel module:
Exports a standard interface like file or terminal (or several...)
GPL all of this work.
Make it useful for others too - and you may sell some additional HW.
Propritary code (user application):
Uses standard file operations - like fopen, seek, ...
The needed headers are LGPL and thus safe.
Comments?
/RogerL
--
Roger Larsson
Skellefte?
Sweden
Dec?a LLX:
> > The irrelevance here is IYHO ... it may well be judged that
> > since these two portions of the work need each other in order
> > to function, the thing really is one work.
>
> a)
> vmware for linux needs a linux kernel to work. does that meen
> you whant to gpl it?
>
> b)
> you can write abstraction modules for different os's. and the
> non-gpl module works with all of them. so my module does not
> need the linux abstraction module it also works with the free-
> BSD module. the only #ifdef in my module will be around the
> module registration code. or i write a propriatary loader,
> so that even the same binary works for different os's
>
And you can use a big array with your binary code and made the source public:
/*
This code is GPL
*/
char *code={big array of code}
void do_somenthin(){
void (*fun) = code;
(*fun)();
}
(well, I dosn't remember the exact sintax of pointer to funtioncs but ... )
You can put the binary driver like "microcode", and GPL
Saludos
Drizzt
--
... 10 IF "LAS RANAS"="TIENEN PELO" THEN PRINT "Windows is good".
____________________________________________________________________________
Drizzt Do'Urden
[email protected]
> (well, I dosn't remember the exact sintax of pointer to funtioncs but .=
> =2E. )
>
> You can put the binary driver like "microcode", and GPL
Nope. The only cases we have microcode like that in the kernel is downloaded
firmware for devices. The same stuff you'd have been finding in the boot
rom instead 12 months ago before the price squeezes reached ripped out any
flash component and doing software download. Richard Stallman doesn't like
that either, but since he currently runs an OS loaded by and using a binary
only BIOS I don't have any direct sympathies right now
Yes, Alan, use these tecnique is a mess, and nobody are going to include a
mess like this in a standar kernel. But someone could use this kind of
tricks to include "binary only mess" in the kernel and no break the GPL ...
I also think about a dinamic patching kernel from user space from /dev/kmem,
another mess but, the limits in "what is dinamic linking", is not clear in
the GPL for me, and you can use these kind of tricks.
I can understand the problems with reports to linux-kernel with binary only
drivers, and why is important that tainted kernel. People in this list don't
have to do the work that must be done for a the company that made the driver
who knows what the binary driver do.
But I can understand less the GPLONLY_ option (and I have read another mail
from you where you comment that there are people that doesn't want that
their code are called from "binary only modules"), because there are tricks
that you can use to jump over the GPL and not put "a glue GPL module" (like
I have read in the thread about this question).
I only thinking about all this topic. I prefer the source for the drivers
(simple, easy debugging) , but is better a binary driver (but the support
must be done by the company that make that driver,of course), that no driver
at all :(, but these is only my opinion.
Saludos
Drizzt
-----Mensaje original-----
De: Alan Cox [mailto:[email protected]]
Enviado el: jueves, 08 de noviembre de 2001 13:41
Para: [email protected]
CC: LLX; [email protected]
Asunto: Re: Module Licensing?
> (well, I dosn't remember the exact sintax of pointer to funtioncs but .=
> =2E. )
>
> You can put the binary driver like "microcode", and GPL
Nope. The only cases we have microcode like that in the kernel is downloaded
firmware for devices. The same stuff you'd have been finding in the boot
rom instead 12 months ago before the price squeezes reached ripped out any
flash component and doing software download. Richard Stallman doesn't like
that either, but since he currently runs an OS loaded by and using a binary
only BIOS I don't have any direct sympathies right now
People always can license the binary driver with the asm source code
or a asm source with:
func:
dd 0xFF,0x01
...
This is a mess also :)
Saludos
Drizzt
"Drizzt Do'Urden" <[email protected]> writes:
> People always can license the binary driver with the asm source code
> or a asm source with:
>
> func:
> dd 0xFF,0x01
> ...
>
>
> This is a mess also :)
Read the GPL again, more carefully.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
Yes, clause 3.a) "machine readable source code". A .s file is, "machine
readable source code" by the assembler and by people that have enough time
to lost.. It is like head.S, but using numeric labels and other stuff of
that kind.
Btw I don't understand exactly the problem with the use of asm code (in
opcodes or in nemonics) and the GPL in this particular case . To me, it's
"machine readable source code" by the assembler and if it's compilation
produces exactly the same executable, and don't see the problem.
It's a nighmare to debug and mantain, but it's the problem who made the
"asm" modulo not the kernel people.
Saludos
Drizzt
On Thu, Nov 08, 2001 at 06:00:45PM +0100, Drizzt Do'Urden wrote:
> Yes, clause 3.a) "machine readable source code". A .s file is, "machine
> readable source code" by the assembler and by people that have enough time
> to lost.. It is like head.S, but using numeric labels and other stuff of
> that kind.
Sigh.
"The source code for a work means the preferred form of the work for
making modifications to it."
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
"Drizzt Do'Urden" <[email protected]> writes:
> Yes, clause 3.a) "machine readable source code". A .s file is, "machine
> readable source code" by the assembler and by people that have enough time
> to lost.. It is like head.S, but using numeric labels and other stuff of
> that kind.
>
> Btw I don't understand exactly the problem with the use of asm code (in
> opcodes or in nemonics) and the GPL in this particular case . To me, it's
> "machine readable source code" by the assembler and if it's compilation
> produces exactly the same executable, and don't see the problem.
You need to read further down in section 3:
The source code for a work means the preferred form of the work for
making modifications to it.
If the code was originally written in assembler, than the assembler
source (with comments and meaningful variable names) is the "preferred
form". If written in C and compiled to assembler, it isn't.
IANAL, but the wording of the GPL is fairly clear. Obfuscated and
semi-compiled source doesn't cut it.
-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863
>"The source code for a work means the preferred form of the work for
>making modifications to it."
yes, I understand all the problem with these, but you can make modifications
also in "these kind of source code".
Closed theme :) I think
Saludos
Drizzt
Dec?a Doug McNaught:
>
> You need to read further down in section 3:
>
> The source code for a work means the preferred form of the work for
> making modifications to it.
>
Ok, thanks for the info, topic closed.
Saludos
Drizzt
--
... Insumiso se pasa el DOOM sin pegar un tiro.
____________________________________________________________________________
Drizzt Do'Urden
[email protected]
Hi.
>>"The source code for a work means the preferred form of the work for
>>making modifications to it."
>>
>
> yes, I understand all the problem with these, but you can make modifications
> also in "these kind of source code".
>
> Closed theme :) I think
Sure, but it's not your _preferred_ way of making modifications.
// Stefan