I have been a socialist. I have been a libertarian. I have been an anarchist. And not just from the armchair. I have been arrested as an anarchist protesting the government.
I think a funny scene in a political comedy -- sort of like the scene in Woody Allen's Zelig where Zelig tries to play cello in a marching band -- would be someone bringing an armchair with them to a rally or protest event, getting arrested along with their armchair, seeing the character in a jail cell with his armchair with him. That would be funny, would it not?
Yes, and a powerful parable as well. Perhaps he could receive a more severe sentence than the flag burners. And in other news,
The master shook his head, and said "No shoes will let me outrun a lion. Fortunately, I don't need to do that. I only have to run faster than the slowest of my companions." With this, the students were enlightened.
Some teachers give the running shoes to the slowest student, and provide a whole nuther kind of enlightenment. And now for something completly on topic:
Linux *is* centralized, in a hiearchy even. Anti-"IP" is not anti-property, but rather anti-usury. Socialism is by definition statist.
I was with you on your comments (and strangely even agreed with them) until I got to "anti-usury." I am against "intellectual property" as defined by software patents, but I can't make the connection to usury.
Usury. The well-known "Microsoft Tax." Made sense to me. -Jared
Linux *is* centralized, in a hiearchy even. Anti-"IP" is not anti-property, but rather anti-usury. Socialism is by definition statist.
I was with you on your comments (and strangely even agreed with them) until I got to "anti-usury." I am against "intellectual property" as defined by software patents, but I can't make the connection to usury.
Usury. The well-known "Microsoft Tax." Made sense to me.
I think that what people forget is that there are reasons that all operating systems on the market in today's IT world are there because they have something that the user wants. In the case of Linux it is an inexpensive OS that can be used in non-fault tolerant environments without having to purchase too much additional functionality while having a wide choice of companies and organizations to provide OS support. Windows on the other hand is not as stable as Linux, however has it's own strengths in the fact that it is the most recognizable OS on the market today. If you were to set someone who was relatively computer illiterate down in front of Windows and Linux, which one do you think they would recognize? Novell is still a viable OS because it does what it was designed to do very well and that is file and print services. I do not understand what you mean by the "Microsoft Tax". If a company or person creates a product and markets it extremely well (regardless of whether it is good or not) and there is a demand for that product, why would they not price it based on the demand? That does not seem like a tax to me, that seems like capitalism to me. Now, if you want to go to a more model in society where by the rich should foot the bill for the poor, then you should be looking at the communist party. Equal distribution of wealth and price controls on products to squelch capitalism are a couple of the main foundations of a communistic society. Phil
On Monday 22 January 2007 14:56, Phil Thayer wrote:
I think that what people forget is that there are reasons that all operating systems on the market in today's IT world are there because they have something that the user wants.
Or, in the case of Microsoft, because they have a monopoly.
Windows on the other hand is not as stable as Linux, however has it's own strengths in the fact that it is the most recognizable OS on the market today. If you were to set someone who was relatively computer illiterate down in front of Windows and Linux, which one do you think they would recognize?
If someone is computer illiterate, they wouldn't recognize either. They would certainly have an easier time using a *nix OS than they would using Windows.
I do not understand what you mean by the "Microsoft Tax". If a company or person creates a product and markets it extremely well (regardless of whether it is good or not) and there is a demand for that product, why would they not price it based on the demand? That does not seem like a tax to me, that seems like capitalism to me.
Except that it is not optional. You are *forced* to purchase Windows with the vast majority of computers. If it was optional, you *might* have a point.
I think that what people forget is that there are reasons that all operating systems on the market in today's IT world are there because they have something that the user wants.
Or, in the case of Microsoft, because they have a monopoly.
I don't think Microsoft has a monopoly. If they did then there would not be the number of OS's still in the market that there are now. If you were to look at all the OS's that are on the market now and categorize them there are more *nix type OS's than windows type OS's. In fact the *nix type OS installations actually out number the Windows installations in certain areas of the computer industry. The area that Windows has the strongest foothold is in the personal/workstation market. Not in the server market. I think it's time that the *nix community realize that they don't have to display the persecution syndrome to get respect. They already have it in the markets that really count.
If someone is computer illiterate, they wouldn't recognize either. They would certainly have an easier time using a *nix OS than they would using Windows.
Most likely the little they have seen about computers is from the TV which would be windows.
I do not understand what you mean by the "Microsoft Tax". If a company or person creates a product and markets it extremely well (regardless of whether it is good or not) and there is a demand for that product, why would they not price it based on the demand? That does not seem like a tax to me, that seems like capitalism to me.
Except that it is not optional. You are *forced* to purchase Windows with the vast majority of computers. If it was optional, you *might* have a point.
Not true. HP is the largest computer vendor in the country and has the largest share of computer sales and you can order a PC from them with Linux pre-installed just like you can windows pre-installed. Pretty much every computer vendor in the country is providing that option now. We have the respect of the companies selling the hardware. Also, they see the opportunity to sell a support contract with the free Linux which means money in their pockets.
_______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Monday 22 January 2007 15:14, Phil Thayer wrote:
I don't think Microsoft has a monopoly.
90% of the market is a monopoly: Microsoft has a monopoly on the desktop market. Not that there is anything inherently wrong with a monopoly in itself-- its when the monopoly is abused that it becomes a big problem real fast. Microsoft's abuse of its monopoly is evident from the number of people buying and/or using Windows because they have no real freedom to choose other good options.
If someone is computer illiterate, they wouldn't recognize either. They would certainly have an easier time using a *nix OS than they would using Windows.
Most likely the little they have seen about computers is from the TV which would be windows.
Computers are rarely shown in detail in movies, and from what I've seen, there's a good variety of OS used there. Can't comment on TV as I have not watched it for at least 2-3 years.
You are *forced* to purchase Windows with the vast majority of computers. If it was optional, you *might* have a point.
Not true. HP is the largest computer vendor in the country and has the largest share of computer sales and you can order a PC from them with Linux pre-installed just like you can windows pre-installed. Pretty much every computer vendor in the country is providing that option now.
Right..... so where can I go to buy a good laptop without Windows exactly? Last time I checked (within the past year), they all mandated a Windows purchase.
We have the respect of the companies selling the hardware.
That's why companies like nVidia and ATi continue to violate the licensing terms on Linux...
Also, they see the opportunity to sell a support contract with the free Linux which means money in their pockets.
Not only do they ship computers with Linux, but they also support it? Are you writing a science-fiction novel?
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
That's why companies like nVidia and ATi continue to violate the licensing terms on Linux...
I still have yet to see someone point out where the licensing terms of Linux preclude the use of binary drivers. I'm not aware of them using any GPL code and disclosing it, but I do know of them releasing closed code drivers. Closed code is not against the Linux license, AFAIK, so long as that code does not include code from an Open license, such as the GPL. Where is it written that closed binary drivers are against the GPL? They may be against the spirit of it, but not against the actual terms.
On Monday 22 January 2007 15:55, Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
That's why companies like nVidia and ATi continue to violate the licensing terms on Linux...
I still have yet to see someone point out where the licensing terms of Linux preclude the use of binary drivers. I'm not aware of them using any GPL code and disclosing it, but I do know of them releasing closed code drivers. Closed code is not against the Linux license, AFAIK, so long as that code does not include code from an Open license, such as the GPL. Where is it written that closed binary drivers are against the GPL? They may be against the spirit of it, but not against the actual terms.
Nobody disputes that the code links to Linux, which the GPL forbids. By using internal, unfixed function calls, it is also a derivative work. The GPL forbids linking (of any kind) with incompatibly licensed code.
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Nobody disputes that the code links to Linux, which the GPL forbids. By using internal, unfixed function calls, it is also a derivative work.
The GPL forbids linking (of any kind) with incompatibly licensed code.
From http://www.gnu.org/licenses/licenses.html I read:
[quote] To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program's code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable. [/quote] I think it would be a hard argument to say that software that makes calls into GPL code as being "derived from it." If someone took the actual GPL code for a driver and made modifications to it and released that, then yes, it would need a continuation of the license. If we make the argument that calling GPL code from closed code violates it, or vica versa, then we have to show that nsidwrapper and WINE violate it too. Jon.
On Monday 22 January 2007 16:21, you wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Nobody disputes that the code links to Linux, which the GPL forbids. By using internal, unfixed function calls, it is also a derivative work.
The GPL forbids linking (of any kind) with incompatibly licensed code.
From http://www.gnu.org/licenses/licenses.html I read:
[quote] To copyleft a program, we first state that it is copyrighted; then we add distribution terms, which are a legal instrument that gives everyone the rights to use, modify, and redistribute the program's code or any program derived from it but only if the distribution terms are unchanged. Thus, the code and the freedoms become legally inseparable. [/quote]
I think it would be a hard argument to say that software that makes calls into GPL code as being "derived from it."
Using an internal GPL'd API, it does.
If we make the argument that calling GPL code from closed code violates it, or vica versa, then we have to show that nsidwrapper and WINE violate it too.
ndiswrapper is in a grey area since, at least in theory, a GPL-compatible NDIS driver exists. WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Using an internal GPL'd API, it does.
The question is what do you mean by use? This is where I lose track from what most people seem to write about it. Use, as in taking the API code and using it and modifiying it in the driver, or using the code as in making API calls to it?
ndiswrapper is in a grey area since, at least in theory, a GPL-compatible NDIS driver exists.
But, that GPL compatible NDIS driver ends up executing closed code, thus it's whole purpose. That still makes a point out of the API "use" distinction. It's generating use of otherwise incompatible hardware under the GPL kernel, through the use of closed drivers. The difference is that NDISwrapper is a basic frame work for drivers, while nVidia and ATI use their own framework to link to specific points of the kernel.
WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
For WINE to function it must make calls into all sorts of areas of GPL code. How is it different to have a graphics routine call from a Win32 program be redirected to a GPL video driver, or even have a Win32 program make a transfer through the network of the host Linux system than it is for nVidia or ATI to make drivers that take input from GPL code to display on their hardware? All have to interact with a GPL API at some point. Where do we draw the line? Making calls to the API is one thing. Building in the actual code to the API is another. That's the distinction I've been pointing out. Modifying code is different than pointing data streams and variable values at locations used by code under the GPL.
On Monday 22 January 2007 16:51, Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Using an internal GPL'd API, it does.
The question is what do you mean by use? This is where I lose track from what most people seem to write about it. Use, as in taking the API code and using it and modifiying it in the driver, or using the code as in making API calls to it?
Both.
ndiswrapper is in a grey area since, at least in theory, a GPL-compatible NDIS driver exists.
But, that GPL compatible NDIS driver ends up executing closed code, thus it's whole purpose.
No it doesn't. I mean the driver itself, not the binding.
WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
For WINE to function it must make calls into all sorts of areas of GPL code.
Not quite.
How is it different to have a graphics routine call from a Win32 program be redirected to a GPL video driver, or even have a Win32 program make a transfer through the network of the host Linux system than it is for nVidia or ATI to make drivers that take input from GPL code to display on their hardware? All have to interact with a GPL API at some point. Where do we draw the line? Making calls to the API is one thing. Building in the actual code to the API is another. That's the distinction I've been pointing out. Modifying code is different than pointing data streams and variable values at locations used by code under the GPL.
Linux specifically excludes userland from the GPL obligations. Even if it did not, the code itself is not technically linking to Linux until runtime if it has the potential to link against something else (for example, BSD) unmodified.
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Both.
Linus posted to the kerneltrap list: "I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin." ( http://kerneltrap.org/node/1735 ) If they had to write an interface layer for their existing driver code (which seems most likely) then it fits under non-derived. Writing code to interface to GPL code is certainly not the same as writing code that uses GPL code to function. Since the nVidia driver is closed, we don't know for sure, and under the DMCA, we aren't allowed to look at the binary driver to be sure.
No it doesn't. I mean the driver itself, not the binding.
Then see above and what the horses mouth says about it. ;)
WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
For WINE to function it must make calls into all sorts of areas of GPL code.
Not quite.
WINE lets a Win32 program execute and intercepts Windows API function calls and translates them into Linux API calls, and vice versa. Much of the Linux API is GPL code. I'm sure we all know that. The userspace exception applies to the kernel, not GPL components running on top of the kernel. A program can run on top of the kernel in userspace and be clear of _kernel_ GPL restrictions, but what about the huge base of GPL code that makes up a distro? Linus has no say over that. That's what I mean when I write that it makes all sorts of calls into GPL code.
Linux specifically excludes userland from the GPL obligations. Even if it did not, the code itself is not technically linking to Linux until runtime if it has the potential to link against something else (for example, BSD) unmodified.
It also makes "tolerable" exceptions for kernel modules. Without the source code from the companies we don't know if they have GPL code in the driver and have to trust them to tell us they don't. Thus, most of what I read about is people theorizing about what might be in the driver and if it is a violation. From what is out there, I see that closed source is not a problem, so long as it contains no GPL code. The problem most people have with closed source is that they can't see the source to be sure that it really doesn't have any. Jon.
On Monday 22 January 2007 17:38, Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Both.
Linus posted to the kerneltrap list:
Linus is wrong. He's not the only copyright holder, either.
WINE is not GPL'd, but even if it were, it would be a similar situation to ndiswrapper-- "GPL'd" software does exist built on the Win32 API.
For WINE to function it must make calls into all sorts of areas of GPL code.
Not quite.
WINE lets a Win32 program execute and intercepts Windows API function calls and translates them into Linux API calls, and vice versa.
No, it translates them into libc and X11 API calls, in addition to implementing the Win32 API that has no libc/X11 equivalent.
Much of the Linux API is GPL code. I'm sure we all know that. The userspace exception applies to the kernel, not GPL components running on top of the kernel.
Linux *is* the kernel. libc is not Linux, and is a standard API with multiple implementations. GNU libc is LGPL, not GPL. Your claim is without basis.
A program can run on top of the kernel in userspace and be clear of _kernel_ GPL restrictions, but what about the huge base of GPL code that makes up a distro?
And that is exactly why proprietary software often uses GTK (which is LGPL) instead of Qt (which is GPL).
Linus has no say over that.
That's what I mean when I write that it makes all sorts of calls into GPL code.
You're still missing the point that there is a legitimate use of WINE when the program running is GPL-compatible. For example, VirtualDub. VirtualDub is GPL, running with WINE's LGPL API, running on glibc (LGPL) and X11 (compatible). Everything here is linking happily.
Linux specifically excludes userland from the GPL obligations. Even if it did not, the code itself is not technically linking to Linux until runtime if it has the potential to link against something else (for example, BSD) unmodified.
It also makes "tolerable" exceptions for kernel modules.
It doesn't, never has, and never will (legal impossibility).
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Linus is wrong. He's not the only copyright holder, either.
Be that as it may, he still has no say over GPL code in userland. But, you also did post that "Linux specifically excludes userland from the GPL obligations." So, if it is stated that the userland is not bound and it must make calls to GPL APIs to talk to the kernel, then why aren't modules that make calls to GPL APIs in the kernel clear too? From what I've read they should be treated the same, which ever way is chosen.
No, it translates them into libc and X11 API calls, in addition to implementing the Win32 API that has no libc/X11 equivalent.
I sit corrected here.
Much of the Linux API is GPL code. I'm sure we all know that. The userspace exception applies to the kernel, not GPL components running on top of the kernel.
Linux *is* the kernel. libc is not Linux, and is a standard API with multiple implementations. GNU libc is LGPL, not GPL. Your claim is without basis.
There is more in a distro than libc for software to talk to. Even so, it still boils down to the userspace exception. It still isn't clear, in terms of the license, if the userspace is really clear. AFAICT it's not. Programs must talk to the GPL kernel at some point and the argument is that the ability to talk (using header files, and possible macros and inline functions) is necessary to run. It seems to me that programmers who write a header and include macros and inline functions have created a chicken-and-egg situation. You can't talk to the code without bringing GPL code into the object file, but you can't get that code removed without having to include the modified source of that header with the GPL and all. I'd think the clearest way is to clean up the code to remove those parts (if possible, move them out the the header) and include those changed files as appropriate under the GPL. Then, the compiled source wouldn't include GPL code in the object. Of course the modification would have to be done seperately and I'm not sure about "avoiding loopholes" in doing it this way.
You're still missing the point that there is a legitimate use of WINE when the program running is GPL-compatible. For example, VirtualDub. VirtualDub is GPL, running with WINE's LGPL API, running on glibc (LGPL) and X11 (compatible). Everything here is linking happily.
But, I never said there wasn't a legitimate use. We can take this argument to where DRM is ok because it does have some legitimate uses. There's that whole related debate over if teh kernel should actively block non-GPL code, which would be a form of DRM in itself.
It also makes "tolerable" exceptions for kernel modules.
It doesn't, never has, and never will (legal impossibility).
I guess the "exceptions" part is at issue. Kernel modules that are not derived works are allowed, but I'm still wondering if the translation layer between closed code and the GPL is supposed to be open. Without seeing the nVidia source we don't know if they are going straight for the kernel API with new code, or if they are merely fine tuning an abstraction/translation layer to an existing driver. Jon.
On Tuesday 23 January 2007 00:31, Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Linus is wrong. He's not the only copyright holder, either.
Be that as it may, he still has no say over GPL code in userland. But, you also did post that "Linux specifically excludes userland from the GPL obligations." So, if it is stated that the userland is not bound and it must make calls to GPL APIs to talk to the kernel, then why aren't modules that make calls to GPL APIs in the kernel clear too? From what I've read they should be treated the same, which ever way is chosen.
1) Linux isn't a microkernel. Linux is monolithic. It is a single program. Modules are part of the program that can be disabled or loaded at runtime. 2) The GPL terms apply to Linux and any Linux-specific APIs that are not deemed userland (as userland has a specific exception). Anyone copying/deriving from the internal API must legally abide by its copyright.
Much of the Linux API is GPL code. I'm sure we all know that. The userspace exception applies to the kernel, not GPL components running on top of the kernel.
Linux *is* the kernel. libc is not Linux, and is a standard API with multiple implementations. GNU libc is LGPL, not GPL. Your claim is without basis.
There is more in a distro than libc for software to talk to. Even so, it still boils down to the userspace exception. It still isn't clear, in terms of the license, if the userspace is really clear. AFAICT it's not.
Code that is/becomes part of Linux is clearly not userspace.
You're still missing the point that there is a legitimate use of WINE when the program running is GPL-compatible. For example, VirtualDub. VirtualDub is GPL, running with WINE's LGPL API, running on glibc (LGPL) and X11 (compatible). Everything here is linking happily.
But, I never said there wasn't a legitimate use. We can take this argument to where DRM is ok because it does have some legitimate uses.
DRM is illegitimate use of an encryption chip. Illegit use cannot have some legit use.
There's that whole related debate over if teh kernel should actively block non-GPL code, which would be a form of DRM in itself.
It would be DRM just as much as GPL is copyright. It's abusing copyright/DRM to reverse its effect.
It also makes "tolerable" exceptions for kernel modules.
It doesn't, never has, and never will (legal impossibility).
I guess the "exceptions" part is at issue. Kernel modules that are not derived works are allowed,
Kernel modules are always derived works, and there is no exceptions for them in any form.
but I'm still wondering if the translation layer between closed code and the GPL is supposed to be open. Without seeing the nVidia source we don't know if they are going straight for the kernel API with new code, or if they are merely fine tuning an abstraction/translation layer to an existing driver.
Irrelevant. Their wrapper would need to work against a GPL-compatible "blob-piece" in order for it to be valid. For example, if they released the code to a stripped down blob, they might get into the grey-area.
Ok- let's look at this from a different angle. It's all about the integrity of OUR data. GPL and traditional IP rules are of need very different conceptually. Then we have to consider what is in the "public interest" Some of the obfuscation in closed source code is ostensibly there for forensic use by law enforcement. Some of the "Embedded Identification" in both hardware and software is either overtly for legal fictions or can be so used in possible violation of our rights to speak freely. DO note than my mention of "hardware" rests on the fact of embedded software being effectively closed to user examination! So the recurring in this thread comments about "API calls and free Vs nonfree code usages often can be hidden in embedded software. BEST examples I can use are the Linux variant wireless gear and networking devices running firmware NOT accessible to us. And YES i am repeating myself from above to hammer on the point. Because if we can't see the code how will ever really know? In a FOSS world the USER has potential to control their "data" In a "closed source" world? That trailing ? is the largest blank ever. In a realm where obfuscation reigns what is truth or lies absent proof? Arguably then there's a gap in how closed source software handles userdata as opposed to common sense- let alone how open source works. For in the FOSS world there still exists a chance for users to either themselves or thru designated by the user experts to validate what I define as "userdata integrity" or "where's your data and who owns it?" The concept includes such details as -where the"userdata" goes and how /where it is stored including who can and cannot access it. I submit that absent code being freely and verified by publication audited for security issues all code not so vetted is inherently suspect! Where then does that place any windows software? FOSS then becomes our last best hope to retain OUR data integrity. Before I am accused of bias, I also fear certain trends in Linux implementations having potential to compromise data integrity. SO- to direct our focus to matters free of partisan rhetoric politics. I am beginning a thread on data integrity. "It's 2100- do you really know where your data is and who can or cannot see it?"
Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Linus is wrong. He's not the only copyright holder, either.
Linus can be wrong all he wants, who cares? Have you ever read the GPL? Only derivative works, or in simple terms "a modification of the original", are required to perpetuate the GPL. *If*, by some absurd stretch of logic, you claim that *any* kernel driver, even if created outside of the kernel source tree, is a derivative work, then the technicality is still easily overcome. It has been explained repeatedly on the LKML. To circumvent the licensing issue, a developer need only write a "wrapper" kernel module that then interfaces with other, non-GPLed programs/code. Remember, the GPL does not dictate what your derivitive work is allowed to do while running. As long as the non-GPLed work can be compiled independently of any GPLed code (rather trivial to make happen), then the GPL can not be forced on it. All you end up doing is giving everyone a headache, and discouraging widespread adoption of your code.
On Wednesday 24 January 2007 13:06, Bradley Hook wrote:
Jon Pruente wrote:
On 1/22/07, Luke -Jr <luke@dashjr.org> wrote:
Linus is wrong. He's not the only copyright holder, either.
Linus can be wrong all he wants, who cares? Have you ever read the GPL? Only derivative works, or in simple terms "a modification of the original", are required to perpetuate the GPL. *If*, by some absurd stretch of logic, you claim that *any* kernel driver, even if created outside of the kernel source tree, is a derivative work, then the technicality is still easily overcome.
No, the GPL also requires anything linking to be GPL-compatible.
It has been explained repeatedly on the LKML. To circumvent the licensing issue, a developer need only write a "wrapper" kernel module that then interfaces with other, non-GPLed programs/code. Remember, the GPL does not dictate what your derivitive work is allowed to do while running. As long as the non-GPLed work can be compiled independently of any GPLed code (rather trivial to make happen), then the GPL can not be forced on it.
Each part needs to be *linkable* independently of any non-GPL-compatible code.
Luke -Jr wrote:
No, the GPL also requires anything linking to be GPL-compatible.
Really? Where? http://www.gnu.org/licenses/gpl.html I only see the sequence of letters "link" once, and that is not even in the terms and conditions portion of the license. I've read the GPL multiple times, and don't recall ever seeing that specified, or even implied. Let's make a new rule: Do not say "the GPL {says|requires|states|etc.} {something}" unless you also cite which section number and version of the GPL you are referring to.
Each part needs to be *linkable* independently of any non-GPL-compatible code.
Even if this were true, this is still trivial. Two pieces of program code can interface with each other without having linked object code. If you need a rather obvious example, consider any client-server based application. In the case of certain programs (i.e., video drivers), this restriction does not remove the possibility of proprietary drivers, it simply makes life more difficult for everyone involved with developing or using those drivers. ~Bradley
On Wednesday 24 January 2007 15:31, Bradley Hook wrote:
Luke -Jr wrote:
No, the GPL also requires anything linking to be GPL-compatible.
Really? Where? http://www.gnu.org/licenses/gpl.html
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation "If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."
Each part needs to be *linkable* independently of any non-GPL-compatible code.
Even if this were true, this is still trivial. Two pieces of program code can interface with each other without having linked object code. If you need a rather obvious example, consider any client-server based application. In the case of certain programs (i.e., video drivers), this restriction does not remove the possibility of proprietary drivers, it simply makes life more difficult for everyone involved with developing or using those drivers.
However, the current state of nVidia/ATi's drivers is not legal.
On Wednesday 24 January 2007 15:44, Luke -Jr wrote:
However, the current state of nVidia/ATi's drivers is not legal.
IANAL - but I work for one, and I know you're not either, and you are also not doing as requested and citing the section of the GPL that would make this "illegal". I note that nVidia and ATI have been distributing Linux-compatible drivers for a while now, and they're not in court over it. I don't use them, but from the discussions I've heard they get compiled locally, which strongly suggests that the source code is available, which would suggest to me that they're quit compatible with what I know of the GPL and open software. Rampant misunderstanding and miss-interpretation of the implications of Open Source licensing is one of the things that holds commercial developers and hardware companies back from participating in the OS community, so your ranting is not only not helping, it's hurting. Go read the GPL. Go read the DSL site. Learn something.
On Wednesday 24 January 2007 16:06, Jonathan Hutchins wrote:
I note that nVidia and ATI have been distributing Linux-compatible drivers for a while now, and they're not in court over it.
Because the copyright holders haven't wanted to test their relationship with nVidia/ATi. The fear is that there would end up being no drivers at all (which is better IMO).
I don't use them, but from the discussions I've heard they get compiled locally, which strongly suggests that the source code is available, which would suggest to me that they're quit compatible with what I know of the GPL and open software.
The GPL is not compatible with everything open source. Either way, the only code compiled by the user is a small source code binding between Linux and a blackbox object file. Using internal data structures and functions from Linux, this binding is a derivative work of it, thus is required to be licensed under the GPL. Using internal data structures and functions from the incompatibly licensed .o blob, the GPL forbids its distribution.
Luke -Jr wrote:
The GPL is not compatible with everything open source. Either way, the only code compiled by the user is a small source code binding between Linux and a blackbox object file. Using internal data structures and functions from Linux, this binding is a derivative work of it, thus is required to be licensed under the GPL. Using internal data structures and functions from the incompatibly licensed .o blob, the GPL forbids its distribution.
This "derivative work" you are referring to is never distributed. Source code that can generate a work (that you seem to think is a derivative) is what is being distributed. Again, the GPL's scope is limited to copying, modification, and distribution (GPL v2, section 0). Half of your argument *may* apply under the terms of GPLv3 (I haven't read a recent draft), but it certainly does not apply under GPLv2. ~Bradley
On Thursday 25 January 2007 08:56, Bradley Hook wrote:
Luke -Jr wrote:
The GPL is not compatible with everything open source. Either way, the only code compiled by the user is a small source code binding between Linux and a blackbox object file. Using internal data structures and functions from Linux, this binding is a derivative work of it, thus is required to be licensed under the GPL. Using internal data structures and functions from the incompatibly licensed .o blob, the GPL forbids its distribution.
This "derivative work" you are referring to is never distributed. Source code that can generate a work (that you seem to think is a derivative) is what is being distributed. Again, the GPL's scope is limited to copying, modification, and distribution (GPL v2, section 0).
Source code is the work.
Half of your argument *may* apply under the terms of GPLv3 (I haven't read a recent draft), but it certainly does not apply under GPLv2.
Many (a majority) of actual Linux developers disagree with you.
On Thursday 25 January 2007 09:33, Luke -Jr wrote:
Many (a majority) of actual Linux developers disagree with you.
FYI, "a majority" was meant to be followed by a "?" Thus:
Many (a majority?) of actual Linux developers disagree with you.
On Thu, Jan 25, 2007 at 09:33:29AM -0600, Luke -Jr wrote:
This "derivative work" you are referring to is never distributed. Source code that can generate a work (that you seem to think is a derivative) is what is being distributed. Again, the GPL's scope is limited to copying, modification, and distribution (GPL v2, section 0).
Source code is the work.
Half of your argument *may* apply under the terms of GPLv3 (I haven't read a recent draft), but it certainly does not apply under GPLv2.
Many (a majority) of actual Linux developers disagree with you.
Then they are wrong. Refering to another work, e.g. #include doesn't make the source code a derivative work. If I have created the source code as an original work and don't include any of the referenced work, but only refer to (#include) it, it is not derivative work, and I can distribute it under any terms I may desire. In order for a work to be a derivative work, the work needs to actually include the other work and not merely refer to it. -- Hal Duston hald@kc.rr.com
On Thursday 25 January 2007 10:14, Hal Duston wrote:
Refering to another work, e.g. #include doesn't make the source code a derivative work. If I have created the source code as an original work and don't include any of the referenced work, but only refer to (#include) it, it is not derivative work, and I can distribute it under any terms I may desire. In order for a work to be a derivative work, the work needs to actually include the other work and not merely refer to it.
Mere referencing would not make a kernel module possible. You need to copy symbol names and derive code from function arguments and Linux-invented structures.
Luke -Jr wrote:
On Thursday 25 January 2007 10:14, Hal Duston wrote:
Refering to another work, e.g. #include doesn't make the source code a derivative work. If I have created the source code as an original work and don't include any of the referenced work, but only refer to (#include) it, it is not derivative work, and I can distribute it under any terms I may desire. In order for a work to be a derivative work, the work needs to actually include the other work and not merely refer to it.
Mere referencing would not make a kernel module possible. You need to copy symbol names and derive code from function arguments and Linux-invented structures.
Been following this thread from the perspective of a mildly disinterested bystander. When did the "kernel" come into play with regard to GPL and source code availability? I can appreciate passionate defense of licenses and freedom and such, but personal attacks aren't serving anyone.
_______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
Luke -Jr wrote:
On Thursday 25 January 2007 10:14, Hal Duston wrote:
Refering to another work, e.g. #include doesn't make the source code a derivative work. If I have created the source code as an original work and don't include any of the referenced work, but only refer to (#include) it, it is not derivative work, and I can distribute it under any terms I may desire. In order for a work to be a derivative work, the work needs to actually include the other work and not merely refer to it.
Mere referencing would not make a kernel module possible. You need to copy symbol names and derive code from function arguments and Linux-invented structures.
Copying a symbol name doesn't make something a derivative work. I have written code which copies the symbol name strcpy, but that doesn't make my code a derivative work of the standard library which defines strcpy. As "derive code from function arguments and Linux-invented structures", I don't even know what that means. I write code to pass values to the functions as arguments, but that also doesn't make my code a derivative work. I also write code that populates the Linux-invented structures, but once again, that code isn't derived from the other work, as it does not include any text in common. "My source code file" below is not a derived work of the library, as it uses the library, and refers to the include file, but does not have any code in common. /*** My source code file **************************************/ #include "include.h" void func_d(void); void func_d(void) { struct struct_b c; c.a = 1; c.b = 1; func_a(c.a, c.b); } /****************************************************************/ /*** Source code from library *********************************/ #include "include.h" int func_a(int a, int b) { return a - b; } /****************************************************************/ /*** Include file from library ********************************/ int func_a(int a, int b); struct struct_b { int a; int b; }; /****************************************************************/ -- Hal Duston hald@kc.rr.com
Hal Duston wrote:
Copying a symbol name doesn't make something a derivative work. I have written code which copies the symbol name strcpy, but that doesn't make my code a derivative work of the standard library which defines strcpy.
Exactly. "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. The 'Program', below, refers to any such program or work, and a 'work based on the Program' means either the Program or any *derivative* work under *copyright* *law*: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term 'modification'.) Each licensee is addressed as 'you'." (GPL v2, section 0, emphasis added). And... "A 'derivative work' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a 'derivative work'." (17 U.S.C. Sec. 101) I don't see how a kernel module, that does not contain any kernel source code in its own distributed source code, can be considered a derivative work under these definitions. ~Bradley
Luke -Jr wrote:
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
"If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."
Dude, seriously, read the license yourself. It is obvious that you are relying on interpretations, which is the absolute worst thing you can do in the case of copyright and licensing. The very same section that you quote in that FAQ states: "What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that..." Please, take the time to read at least sections 0 and 2 of the GPL, version 2. These sections clearly define what conditions must be met.
However, the current state of nVidia/ATi's drivers is not legal.
I have not looked at the nVidia/ATI installers closely enough to determine if this is absolutely true or false. As I recall, both installers require the kernel headers to already be installed on your system, implying that no kernel code is included in the material distributed by nVidia/ATI. The GPL *explicitly* states that "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope" (GPL v2, section 0). This means that running, compiling, linking, and interfacing are all outside the scope of the GPL. This means you need to find some other legal mechanism to base your claims on. If you honestly believe nVidia/ATI are violating either the legal requirements or moral attitude of the GPL, then why don't you file a lawsuit and see if the FSF, OSDL, or any other respected OSS community organizations come to side with you. Of course, you need to own some aspect of the Intellectual Property contained in the Linux kernel before you can even file suit. ~Bradley
On Wednesday 24 January 2007 16:09, Bradley Hook wrote:
Luke -Jr wrote:
http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation
"If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program."
Dude, seriously, read the license yourself. It is obvious that you are relying on interpretations, which is the absolute worst thing you can do in the case of copyright and licensing.
Nobody is better qualified to interpret than the author.
If you honestly believe nVidia/ATI are violating either the legal requirements or moral attitude of the GPL, then why don't you file a lawsuit and see if the FSF, OSDL, or any other respected OSS community organizations come to side with you. Of course, you need to own some aspect of the Intellectual Property contained in the Linux kernel before you can even file suit.
There's been talk about kernel copyright holders possibly beginning to enforce it...
Luke -Jr wrote:
Nobody is better qualified to interpret than the author.
I did not say who was or was not qualified to interpret the material. I was simply making the point that it is not a good idea to *RELY" on any interpretation of a legal document, regardless of who made it. READ THE ORIGINAL YOURSELF! And when it comes to legal documents, the author is not necessarily the most qualified to interpret the legal implications. The author is the best qualified to interpret their own intentions, but this is a totally different thing. ~Bradley
90% of the market is a monopoly: Microsoft has a monopoly on the desktop market. Not that there is anything inherently wrong with a monopoly in itself-- its when the monopoly is abused that it becomes a big problem real fast. Microsoft's abuse of its monopoly is evident from the number of people buying and/or using Windows because they have no real freedom to choose other good options.
They have 90% of the desktop market because that is what they targeted with their marketing initially. Their technology did not hold up and cannot hold up when it gets out of the desktop market. So, I'm not real worried if they have the market for the GUI front-end systems that support the server backends running a *nix OS.
Computers are rarely shown in detail in movies, and from what I've seen, there's a good variety of OS used there. Can't comment on TV as I have not watched it for at least 2-3 years.
Good for you. You are in the minority when it comes to watching TV. I can tell you that anytime I have seen a computer on a TV show it is almost always a Windows system.
Right..... so where can I go to buy a good laptop without Windows exactly? Last time I checked (within the past year), they all mandated a Windows purchase.
Go to http://www.dell.com/content/products/productdetails.aspx/precn_390?c=us& l=en&s=bsd&cs=04 one of the options for this system is Red Hat. Read this new release from HP in 2004. http://www.hp.com/hpinfo/newsroom/press/2004/040803a.html?jumpid=reg_R10 02_USEN Read the last paragraph of the Dell Workstations Solutions page to find out about the Dell Red Hat support provided. http://www.dell.com/content/topics/global.aspx/solutions/en/precision_li nux?c=us&cs=19&l=en&s=dhs Here is the HP Linux support and consulting services page that describes their commitment to Linux. http://h20219.www2.hp.com/services/cache/390161-0-0-225-121.aspx?jumpid= reg_R1002_USEN And then if you want a world class RDBMS with Linux (including support and consulting services) look at http://www.oracle.com/technologies/linux/index.html
We have the respect of the companies selling the hardware.
That's why companies like nVidia and ATi continue to violate the licensing terms on Linux...
I really don't keep up with all that. Not when companies like Apple blatantly violate patent laws live on TV in front of the whole world. nVidia and Ati violating the terms of the Linux licensing is trivial. At least they want to get into what they must see as a lucrative market in the Linux world.
Also, they see the opportunity to sell a support contract with the free Linux which means money in their pockets.
Not only do they ship computers with Linux, but they also support it? Are you writing a science-fiction novel?
Not only do they ship with Linux but they support it. As for the Science Fiction part...Well in the '60's people viewed science fiction as having computers that you could hold in your lap and phones that you would be able to use with a simple communications device in the ear and a "communicator" that was on the belt of the person communicating. Gee, maybe science fiction is the precursor of reality? In any case, Linux and *nix in general are not the small misunderstood group of OS's that everyone likes to think of them to be. They are a major player in the IT industry. Not just some hobby OS that is on the verge of dying away. Phil
On Monday 22 January 2007 16:02, Phil Thayer wrote:
Right..... so where can I go to buy a good laptop without Windows exactly? Last time I checked (within the past year), they all mandated a Windows purchase.
Go to http://www.dell.com/content/products/productdetails.aspx/precn_390?c=us& l=en&s=bsd&cs=04 one of the options for this system is Red Hat.
We have the respect of the companies selling the hardware.
That's why companies like nVidia and ATi continue to violate the licensing terms on Linux...
I really don't keep up with all that. Not when companies like Apple blatantly violate patent laws live on TV in front of the whole world.
Patent laws are unjust anyway.
nVidia and Ati violating the terms of the Linux licensing is trivial.
As a result, real drivers are virtually non-existent for both (in regards to full support for recent products); the situation would likely be a lot better without their proprietary junk.
participants (10)
-
ben -
Bradley Hook -
Hal Duston -
Jared -
Jon Pruente -
Jonathan Hutchins -
Luke -Jr -
Luke-Jr
-
Oren Beck -
Phil Thayer