hmmmm.....I rather missed the point about stable APIs
|
| Author | Content |
|---|---|
| dinotrac Jul 28, 2006 3:14 AM EDT |
Don't get it at all. I can understand the genesis -- evolution making planning difficult (Sorry -- could not resist the juxtaposition of words!! ;0) ) But the discusstion of stable APIs seems like little more than a rationalization for refusing to consider the needs of outside developers. Greg introduces his own myth on this issue: life is black and white. Yes...you can be stable without being forever frozen. Life is all about continuums. |
| Sander_Marechal Jul 28, 2006 3:35 AM EDT |
Did you read stable_api_nonsense.txt (http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Doc...)? It makes quite a lot of sense. |
| dinotrac Jul 28, 2006 6:31 AM EDT |
Yes, I read it. No, I don't buy it. |
| Sander_Marechal Jul 28, 2006 8:28 AM EDT |
Why not? |
| dinotrac Jul 28, 2006 8:48 AM EDT |
For the most part, I don't think it's an either-or proposition. Now and then, you really do have to abandon APIs. Stuff happens. Often, however, you can extend and improve them. Takes a little more thought. isn't as much fun. Doesn't let you stoke the artist inside quite so much, but can be done. The buyback is that it's easier for others to interact with you. Now, the argument put forward uses a bit of circular logic -- presuming that internal interfaces should be of no interest to anyone but kernel developers anyway, and so it shouldn't matter. That's true so long as you do not wish to encourage hardware makers to develop drivers for their equipment. If do wish to encourage that, it starts to matter, whether the drivers are binary or fully open. |
| grouch Jul 28, 2006 9:11 AM EDT |
Did you happen to read the part in Kroah-Hartman's presentation about stability and security?Quoting: Now Windows has also rewritten their USB stack at least 3 times, with Vista, it might be 4 times, I haven't taken a look at it yet. But each time they did a rework, and added new functions and fixed up older ones, they had to keep the old api functions around, as they have taken the stance that they can not break backward compatibility due to their stable API viewpoint. They also don't have access to the code in all of the different drivers, so they can't fix them up. So now the Windows core has all 3 sets of API functions in it, as they can't delete things. That means they maintain the old functions, and have to keep them in memory all the time, and it takes up engineering time to handle all of this extra complexity. That's their business decision to do this, and that's fine, but with Linux, we didn't make that decision, and it helps us remain a lot smaller, more stable, and more secure. If you want a stable API, you can "buy" MS Windows. That will be the only stable thing they *rent* to you. |
| Sander_Marechal Jul 28, 2006 9:25 AM EDT |
Quoting:That's true so long as you do not wish to encourage hardware makers to develop drivers for their equipment. Now, that's plain not true. HW vendors don't do drivers because of lack of interest and because they don't want to GPL their "IP". Remember that even with stable API's the drivers need to be GPL'ed. The only thing that a stable API would enable is maintenance *outside* the kernel tree. So, the question for HW vendors willing to GPL their drivers reduces to: "Why do you want to maintain your GPL driver outside the kernel tree and not inside it?" |
| dinotrac Jul 28, 2006 9:34 AM EDT |
sander - No, the drivers do not need to be GPL'd any more than Nvidia's are now. In fact, there's another approach one could take: A GPL'd shell that interfaces with a proprietary core. Probably a drag for video drivers...translation layers cost performance, but so much of the real work is done in hardware these days that it might not even show up in a way that anybody would notice. Besides....Since when is GPL the only issue? What if the hardware makers simply want provide the best possible driver, taking advantage of their full knowledge of the equipment? IOW, a GPL'd driver that they maintain. Is that a bad thing? i don't think so. You may. |
| dinotrac Jul 28, 2006 9:35 AM EDT |
grouch - You can't seriously be holding Microsoft up as an example of the best that the IT world has to offer. I refuse to believe that. In case you've missed the last 40 years or so, there are other companies in the field, such as IBM and Sun. There are other platforms than PCs, etc. |
| Sander_Marechal Jul 28, 2006 9:44 AM EDT |
Quoting:No, the drivers do not need to be GPL'd any more than Nvidia's are now. They do. And the "shelled" driver is exactly what nvidia is doing now. See my post at http://lxer.com/module/forums/t/23234/ for that. The only reason that nvidia drivers still work that way is because no-one has sued (yet). Quoting:What if the hardware makers simply want provide the best possible driver, taking advantage of their full knowledge of the equipment? They can do that in kernel as well. It's only a matter of *where* the source is stored. Is it on kernel.org or on the vendor's website? And as a bonus, Linus' crew will review your driver for potential problems before it's put on kernel.org, and they do your interface mainenance too! |
| grouch Jul 28, 2006 9:46 AM EDT |
dinotrac: >"In case you've missed the last 40 years or so, there are other companies in the field, such as IBM and Sun. There are other platforms than PCs, etc." In case you missed it, IBM likes Linux and expects it to replace everything else. In case you missed it, Sun has been terrified of Linux running them out of the market. Lots of Sun boxes have been replaced by Linux and GNU/Linux in some high-profile, mission-critical situations. Linux is "the best that the IT world has to offer." You've offered no credible evidence to convince me you know better than the kernel developers regarding the evolving Linux API. |
| dinotrac Jul 28, 2006 9:54 AM EDT |
grouch - All of which has nothing to do with anything. You were holding Microsoft up as an example of maintaining stable APIs. I suggest that Microsoft is a crappy example for any kind of software development. You may disagree, but I think other vendors have done a much better job over the years. As to knowing better than the kernel developers, that's a matter of POV. They are arguing from a standpoint of what's best for kernel developers, which may or may not be what's best for Linux and those who wish to use it. |
| grouch Jul 28, 2006 10:01 AM EDT |
dinotrac: >"You were holding Microsoft up as an example of maintaining stable APIs." No, I wasn't. You were claiming that stable APIs could "be stable without being forever frozen", whatever the hell that means. You claimed Kroah-Hartman introduced his own myth. IF you read his presentation, then you know that he compared Microsoft's stable API to Linux's constantly changing one. Suddenly, you introduced IBM and Sun, as if they haven't recognized that Linux is on track to displace all of the old UNIX systems in every place. dinotrac: >"They are arguing from a standpoint of what's best for kernel developers, which may or may not be what's best for Linux and those who wish to use it." It appears that the focus of Linux developers is what's best for Linux and Linux users. I don't see where you get your argument to the contrary. |
| dinotrac Jul 28, 2006 10:03 AM EDT |
sander - >And as a bonus, Linus' crew will review your driver for potential problems before it's put on kernel.org, and they do your interface maintenance too! That is actually part of the problem. Bad drivers can adversely affect the reputation of good hardware. A manufacturer might not want others messing with its code, even if they don't mind making it open. Sounds odd, but I can understand it. As to the proprietary core within a GPL'd shell -- there is nothing in the GPL to make that illegal if you are the owner of the shell IP. I welcome you, however, to provide some basis for calling the proprietary core illegal, given this fact scenario: 1. The shell compiles and links without the core 2. The core can interact with a previously compiled and linked shell 3. The core uses no headers, etc, from GPL'd code other than the shell, for which the core developer is the copyright owner. Just exactly whose rights are violated? Who has standing to sue anybody in such a sceneario? For that matter, who do you sue? The hardware manufacturer for writing code that doesn't violate anybody's license? Maybe it's the user, for combining the pieces in a way that makes you unhappy....except that.... The GPL gives users lots of freedom to use GPL'd code so long as they don't distribute it. |
| Sander_Marechal Jul 30, 2006 5:48 AM EDT |
Quoting:I welcome you, however, to provide some basis for calling the proprietary core illegal, given this fact scenario: From teh GNU GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html#MereAggregation Quoting:If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. The GPL'ed wrapper shell for video drivers has been designed to work specifically with the binary blobs. It's not a reasonably common interface. Therefor the divers and GPL shell can be considered to be one program, which should as a whole be under the GPL. The FAQ also says: Quoting:What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. This hasn't happened yet. Nvidia believes that what they do is legal. Most kernel devs think it's not. Unfortunately the kernel devs can't/won't sue over it (probabely lack of $$). Someday it will be decided in court and I personally think that nvidia will loose. |
| sbergman27 Jul 30, 2006 6:09 AM EDT |
It's really not that complicated. Linus says that binary modules are OK and his decision has stuck. How can he do something like that when he holds the copyright for only a small fraction of the codebase? The same way any of his decisions are "enforced": through respect from the other developers. Any one of them *could* file suit against the makers of binary kernel modules wrt their own copyrighted code, but they don't out of respect for project policy. This is not to say that Linus likes binary modules. He certainly doesn't go out of his way to make things easy for their creators. The lack of a stable driver api is but one example of that. But he does not believe in going after them legally. |
| dinotrac Jul 30, 2006 6:18 AM EDT |
Steve, sander: The other problem is that one needs a legal basis for saying something can't be done. You must have a breach of contract, a violation of law, and ifringement of rights, etc. In the case of contracts it gets tricky because a contract term may not be legally enforcable. The fact scenario I set up, for example, exceeds no legally granted rights. The one reasonable question would be whether you could distribute GPL'd code together with the proprietary and closed binary core that gets invoked by the GPL'd shell. The GPL seems to say that you can't. On the other hand, I'm very skeptical that a court would say that you can't, for example, include the binary on a separate CD in a physical distribution or separate directory in a downloadable distribution. |
| Sander_Marechal Jul 30, 2006 6:36 AM EDT |
Everything hinges on the fact if the binary blob + GPL glue code are a single program as defined in the GPL. The GPL is ambiguous on that point. A judge would have to sort it out. @steve: Even Linux is bound by the GPL. If he says binary blobs are okay, but a judge rules otherwise then he's out of luck. His statements that binary blobs are okay could be brought up in court to state the "intent of the author" and would be weighed in by the court, but the judge has the final call. @dino: If the core and the shell are designed to work together pretty much exclusively the it can be seen as a single program. If a judge says that is the case, then the core would have to be GPL'ed. But anyway, both sides of the arguement can be discussed indefinately. Only a judge can bring clarity, everything else are just opinions. |
| sbergman27 Jul 30, 2006 6:42 AM EDT |
A judge can force Linus and the other kernel developers to sue binary module distributors? |
| dinotrac Jul 30, 2006 7:14 AM EDT |
sander - It doesn't matter how you see it. You breach, violate, or infringe. So they can be seen as a single program? What does that breach, violate, or infringe? Who is the breacher, violator, or infringer? As to opinions -- yes and no. If somebody wishes to go into court and file a complaint, they will be compelled to specify the elements of the offense. If they cannot do that, the complaint will be tossed. So, let us put it this way: If you were going to tell a judge that some action violated some law, breached some provision of some agreement, or infringed some right, what action would that be? What provision, law, or right would be at stake? Who would be the violator? if you can't answer those questions, you can't even get into court. |
| sbergman27 Jul 30, 2006 7:37 AM EDT |
> but so much of the real work is done in hardware these days And in user space. Actually, do proprietary drivers that use DRI have a problem at all? The drm kernel module just does relatively basic things with the hardware that need to be done from kernel space, right? That shouldn't be particularly revealing of the hardware or subject to third party licensing. So GPLing that part shouldn't be that much of a problem. And Xorg is under an X11 license. So the proprietary user space module is a slam dunk. NVidia does not use DRI. How does ATI's fglrx handle things? |
| dinotrac Jul 30, 2006 10:53 AM EDT |
Steve - And let us not forget that the GPL itself permits interaction between GPL'd and non-GPL'd code over an interface that is in the nature of I/O. |
| Sander_Marechal Jul 30, 2006 12:16 PM EDT |
Quoting:A judge can force Linus and the other kernel developers to sue binary module distributors? No, but there are quite a few kernel devs out there who think binary blobs should be illegal, regardless of what Linus says. One of these might eventually sue and get the matter in front of a judge. |
| sbergman27 Jul 30, 2006 12:35 PM EDT |
True. And then they might fork the kernel for an encore. So, let's say this happened. Say some guy who contributed a bit to the block layer code, which has nothing to do with video, decided to sue Company X over copyright infringement in the form of a proprietary video driver module. Exactly how would that work? |
| dinotrac Jul 30, 2006 1:19 PM EDT |
Steve - It wouldn't. There is no copyright infringement if Company X made no use of the guy's work. He might try to sue for a GPL violation, but he's got a different problem. He's got to figure out who violated what. For example, was it the folks who wrote the video driver? Maybe -- if there was some reason why they had to include a header with some of his (sorry for the presumption, but, in the world of kernel coders, it's pretty safe) code in order to compile their module. But probably not: 1. The header might not rise to the level of authorship needed to trigger copyright protection. Headers tend to be pretty straightforward sets of definitions and the like. If it isn't protectable, the coder doesn't even need a license to use it. 2. The GPL grants coders the right to use the code. You or I can develop pretty much anything we want and incorporate GPL'd code to our heart's content. All the really snarly stuff happens when you try to distribute the code. That's when all of the no-binary without source and freedom to re-distribute stuff kicks in. 3. Although the coder might need to use GPL'd block code to ensure that his driver works (You know -- run linux and make sure everything happy) , that's ok. The block code developer granted a GPL license to use his code. The coder is also free to put his binary driver -- the one with no pretectable GPL'd code -- up on an ftp server all by itself. Nobody violates anything by downloading it. How about the distributor? Now the distributor seems to violate the GPL...presuming that the proprietary driver is distributed along with Linux. The license pretty clearly doesn't permit that. I suspect, however, that a court would put some boundaries on that. For example, they might permit a separate DVD, or, if need be, a separate shrink-wrapped package, or what have you. From there, though, it becomes a slippery slope from the legal standpoint -- and the law can be surprisingly practical this way -- If you can throw a second package in the envelope when you ship it, what's wrong with including an extra DVD in the original package? if you can throw in an extra DVD, why not simply set up a separate directory, etc. Or, a court might decide that the distribution provisions with regard to including non-infringing proprietary software with GPL'd software to be unenforceable. At any rate, a genuine claim of license violation could be made against the distributor. That goes out the drain if the distributor doesn't distribute the binary driver, relying, perhaps, on the coder's ftp site. Well, then, how about the user who goes up to the coder's ftp site and pulls down that nasty old driver? Sorry. GPL permits that. |
| Sander_Marechal Jul 30, 2006 1:49 PM EDT |
Quoting:Exactly how would that work? What dino said, there's no infringement of X's work. And contrary to what dino says he can't sue for GPL infringement. There's no such thing as infringing the GPL. There's only copyright infringememnt. The GPL merely determins what is and is not a copyright infringement. Quoting:The header might not rise to the level of authorship needed to trigger copyright protection. The Linux headers clearly fall under the GPL. That's exactly the reason everybody tries it with a GPL'ed shell around a binary blob. Quoting:The coder is also free to put his binary driver -- the one with no pretectable GPL'd code -- up on an ftp server all by itself. Nobody violates anything by downloading it. There's no such thing as "no protectable GPL code". If it's not protectable then it's public domain and the coder is in the clear. If there is GPL'ed code then he's distributing, thus infringing copyright. The downloaders are *always* in the clear since the act of downloading it isn't distribution. Quoting:Now the distributor seems to violate the GPL...presuming that the proprietary driver is distributed along with Linux. The license pretty clearly doesn't permit that. There is no difference between the distro distributer and the coder who uploaded the binary blob. Either it's copyright infringement for them both or it isn't. I think you are referring to the reason why video drivers have to be downloaded separately. That's not about GPL issues but it has to do with the fact that the license on the binary blobs doesn't allow redistribution by third parties. |
| sbergman27 Jul 30, 2006 2:10 PM EDT |
Oops, you're right. I said copyright infringement when I meant license violation. So, let's say Linus, Andrew, and the gang decide they want to stamp out these nasty proprietary kernel modules. Company X develops a proprietary video driver module and makes it available via online download. Redhat decides they've had enough of being conservative old fuddy-duddies and download the driver and distribute it in RHEL5 Gaming Edition, which the license from Company X permits. Meanwhile, Linspire has a visitation from the Lord and refuses to touch the sinful module. Linus could sue Redhat and have a case. Linspire is obviously in the clear. Joe Gamer installs Linspire and downloads the module from Company X's ftp site and loads it, and he's in the clear, too. And Company X, the one's that created the filthy module in the first place, are completely in the clear on all counts. Is that a fair restatement? |
| grouch Jul 30, 2006 2:39 PM EDT |
>"Oops, you're right. I said copyright infringement when I meant license violation." In the case of the GPL, a license violation means copyright infringement. The GPL grants permissions beyond copyright. If you violate the GPL, copyright law is all you have to fall back on and it doesn't give you permission to copy, modify and distribute. |
| dinotrac Jul 30, 2006 2:55 PM EDT |
sander - WRT: "no protectable GPL'd" code. In much the same way that QT is licensed under both the GPL and a non-free license, a developer of GPL'd software may release his code without regard to whether it is actually protectable. The protectability of code is a legal determination that the coder may not wish to make or may not be able to make. Ditto for potential users. As the author, if the code is not public domain, the developer has the power to grant access under the GPL. Users can use it with confidence so long as the adhere to the GPL. If a header file or some such thing is later ruled to lack protectable content, nothing changes for anybody except that the author is unable to restrict use of the file. The GPL becomes irrelevant for that particular piece of the pie. As to the binary driver without protectable GPL'd code: That merely means that it contains no GPL'd code, or code that, upon scrutiny, would be deemed protectable and hence requiring a grant of rights under the law. Quoting:There is no difference between the distro distributer and the coder who uploaded the binary blob. There is a huge difference. Remember that the coder has not infringed anybody's copyright or violated anybody's license. The coder is not distributing a combination of the driver with anything else. I presume that you are a pretty recent arrival to the world of free software, and the GPL in general. If you had been around 5-6 years ago, you would remember a time when Debian refused to distribute KDE because QT, the toolkit upon which KDE is based, was distributed under a license ( a free license, no less, and one officially deemed as free by the FSF) that was incompatible with the GPL. The issue was a claim that the GPL would not permit GPL'd software to be distributed together with software that was restricted in the particular manner (I now forget what the problem provision was) that QT was. A distributor who combines GPL'd and non-GPL'd software runs the same risk. |
| Sander_Marechal Jul 30, 2006 4:15 PM EDT |
Quoting:And Company X, the one's that created the filthy module in the first place, are completely in the clear on all counts. That is up to the court to decide. Because the GPL shell and the binary blob were designed to work together as a whole exclusively, a court may well find that the whole constitutes one program, in which case the GPL affects both the shell and the binary blob. So far it is pretty clear that a distributer distributing the blob + shell as one whole violates the GPL. The running arguement is wether the blob itself is in violation as well. Linus thinks not. Other people disagree. My explanations above hinge on the fact that the blob itself is in violation. Dinotrac's explanations are based on the fact that the blob on it's own is legal, but not when distributed alongside the shell. Different sections of the GPL affect each scenario with potential different outcomes if it ever gets tested in court. |
| dinotrac Jul 30, 2006 4:32 PM EDT |
>My explanations above hinge on the fact that the blob itself is in violation. If the blob itself is in violation of the GPL, everything becomes very simple. The original copyright infringement means that the coder/distributor/user -- everybody in the entire chain is violating the law. I don't believe there is any way to violate the GPL -- presuming that you are relying on the GPL for your grant of rights -- without also violating copyright law. The reason for that is the GPL's automatic termination provisions. Basically, if you violate the GPL, it rescinds all grants of rights. That leaves you infringing. |
| Sander_Marechal Jul 30, 2006 9:55 PM EDT |
Exactly :-) |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!