On Mon, Oct 15, 2007 at 04:39:04PM +0000, Peter P. wrote: > Byron Jeff clayton.edu> writes: > > On Mon, Oct 15, 2007 at 10:53:27AM +0000, Peter P. wrote: > > Peter, > > A bit too much rhetoric here. > > Ok, but ... see below > > > In embedded space the GPL (and LGPL) are problematic from a kernel and > > library standpoint because there are not separate spaces in which kernel, > > Yesno. If you search a little, you will see that the most popular Linux > embedded systems are MMU-less ARM and MIPS CPU powered. That includes most > ADM5xxx routers (MIPS) and the Sharp Zaurus and more. The latter case is a good > example of 'embedded system' where an almost fully featured Linux distribution > exists in a non-separate (and inseparable) code and data space (there is no MMU > in the Zaurus). How it is linked is moot. Today it is linked 'clean', tomorrow > it could use 'accelerator hooks' directly into the kernel (a la m$)(${deity} > forbid, that is a maintainance nightmare). The key idea seems to be the bottom > line. The bottom line is the fact that THE FULL SOURCE IS AVAILABLE. Ultimately, > no matter what is in it, the fact that the source is available solves the > problem in the spirit of the GPL (although likely not in the letter - maybe that > particular problem should be addressed somwhow, but not by me). Peter, If full source availability is a viable option, then the discussion is moot. While personally I think the objective of embedded systems companies should be to sell hardware, real companies are handcuffed with the reality of segments of the organization (boards, shareholders) believing in intellectual property. I know we'll continue to disagree on this point. I also know we cannot sway each other. But I think it's reasonable to discuss the viability of a layered hybrid between open and closed source. > > usage on the desktop, where libraries are dynamically linkable and the > > kernel has its own space. > > > > This is the issue that Xiaofan is struggling with. > > The bottom line is, as above, AVAILABLE SOURCE. The purpose of the teeth in the > GPL is to prevent such use that implies hiding the source and the attribution. Which source? If I write an application using an open source kernel and libraries without modification and interface with standard interfaces, which source am I hiding? If it's a Linux kernel and a standard LGPL set of libraries then there's absolutely no issue in the standard desktop environment. But in the embedded systems environment it doesn't work because of the change in the hardware infrastructure. The LGPL requires that relinking to an updated library be possible. Since the app and the library share the same address space, then the only way to accmplish this is to release the source of my application. That's a problem when in fact no free code has been contributed to the application itself, only to the infrastructure that it uses. The purpose of the GPL here is to force all code that uses it to be as free as it is. That's as problematic as closed source software in my book. I have no problem with modifications to the GPL/LGPL infrastructure having to be source available. But there is a difference between building and infrasturcture and using it. > Not the sale, not the modification, but the hiding and the hoarding. Yes, this > is purely political. The pigopolists who hide the origins of their pirated Linux > applications refuse nothing else but to publish the source of their puny > modifications and additions to the one million lines of code they aggregate > with, therewith (ha!) calling them their own as a whole (that is about as close > as one can get to stealing - probably too close). At least you admit it's political. I agree with you as long as they didn't write it. But I have problems when you start to push enforced freeing of code upon developers who actually develop their own stuff. I'm a believer of free infrastucture coupled with whatever you want applications. I can choose not to use your application because it is not free source available. But I'm not about to force anyone to free their personally written code just to appease me. > > The GPL (and to a lesser degree the LGPL) are deliberately heavyhanded in > > order to curtail the misuse of the code under those licenses. If everyone > > could agree to be reasonable and not greedy, then a less permissive license > > could work. However many commercial developers believe that profit is made > > by doing a value add and creating artificial scarcity. So they do precisely > > what Peter proposes: take open software, value add, then close up the > > results. The GPL is designed precisely to prevent that activity. > > I am NOT proposing that. I was illustrating that as being precisely a breach of > the GPL license in spirit and in letter. The letter and sprit of the GPL only works when all code is free. It doesn't function in an environment where all free code isn't an option. > > But it does it by forcing everything that touches it to be as free as it > > is. There's no middle ground. And that does curtail its use. > > There cannot be a middle ground in this issue. That is the point. Yes there can be. I strongly disagree with this point. By stating there is no middle ground it completely forces anyone with commercial interest from participating because by your stance in order to play, everything you do must be free. I don't advocate stealing mind you. But creating lines of demarcation and vigoursly enforcing them works. I'll put it in the form of a question: On your Linux box, how do you handle Flash applications? There are 3 or so options: 1) I don't do flash. 2) I do Gnash 3) I use Adobe's closed source Flash player/plugin. Personally I do #3. It works in most situations. Would I like Adobe to release the source? Sure! But from a practical standpoint they honor the lines of demarcation by using standard LGPL libraries. > As Linus has > stated it before, stay in user land, you're good to go, touch the kernel and > you're 0wn3d. Don't like it ? There are at least 4 flavors of open source BSD > to choose from and the precedents set by Apple (OSX) and others. You can dream > about the Linux kernel forever, if you like. Just no touchy touchy or there will > be ouchy ouchy. So we actually agree on something. The kernel and libraries are infrastructure. Free to everyone. Used by everyone. All modifications shared. No problem. But you keep wanting to extend this into application space. And embedded systems hardware forces this extension. If I build an embedded system on an ARM and use standard kernel and libraries, why should I be forced to release my source? I'm in user land. It's just that user land, library land, and kernel land all overlap in an embedded system. > > Now Peter is probably not satisfied with this because it allows for > > pigolopolies (interesting word) to build closed source commercial apps > > using free libraries/kernels. > > > > What I am not satisfied with is the idea that GPL code which was released and > conceived as GPL could somehow become something other than GPL by clever > manipulations in a court or by a commitee. I am very satisfied with the idea > that specific libraries and kernels and whatnot conceived to be used as you say > exist and are created, under licenses OTHER than GPL. While I can understand > that most people want to keep their cake, and eat it too, the GPL is not a good > candidate for cake. It was created and engineered for the purpose of stubbornly > resisting consumption and removing the poison and the thorns is next to > impossible (as expected). We all agree on that. The question is how to license so that you get the teeth that you need while functioning in the environment that you're in? There are three fundamental questions with licenses in embedded space: 1) Do source and modifications to the infrastructure need to be released? 2) Does source for the application need to be released? 3) Does the user have the right/ability to upgrade the infrastructure? Let's eliminate permissive licenses such as the BSD: 1) No. BSD doesn't require modifications to the infrastructure to be released. 2) No. BSD doesn't require source for the application to be released. 3) No. BSD doesn't require user ability to upgrade infrastrucure. Now the GPL is completely the opposite in embedded space: 1) Yes. Infrastructure modifications must be released. 2) Yes. Source for the application must be released 3) Yes. User has right to upgrade infrastructure. The question is whether or not mixed hybrids have utility. The LGPL is an example: 1) Yes. Infrastructure modifications must be released. 2) No. Source for the application need not be released 3) Yes. User has right to upgrade infrastructure. But since we are in embedded space, the only way to upgrade the infrastructure is to have the source to the application. I guess linkable modules are a possibility. Now what's the downfall of the following: 1) Yes. Infrastructure modifications must be released. 2) No. Source for the application need not be released 3) No. User does not retain right to upgrade infrastructure. How does this harm the free software community and the user? > > > Actually he uses a modified GPL that facilitates usage of the kernel > > without the GPL touching it. > > Yes, he does. But again, the emphasis is on the purpose: keep the source open > and contributable to and reviewable by third parties, to achieve the best > development speed, peer review ensured security and bug-free-ness and a feature > set that pleases most users. The Linux kernel cannot be both good and closed. > That's the point. It can be only one of them at any given time. But how does that apply to applications that use the kernel? No one wants to close the kernel. Or libraries. The only discussion here is about applications. But in embedded space, applications are in the same space as libraries and the kernel. So how can you resolve the issue of free libraries and kernels but applications that are wholly written by 3rd parties? With the GPL they cannot be mixed. You seem to believe that's the only way that it should be. I'm asking if any other way is viable? > > Not every commercial company is by definition only a taker. > > I never said they were. This discussion is not about 'takers' it is about 'GPL > takers' specifically. In fact, most companies with serious technical backing > have several aces up their sleeves and can (and did, and will), use the right OS > for various products. Be it VxWorks, Linux, ucOS, FreeBSD or whatever. The 'GPL > pigopolism' issue only applies to cheapskates who try to cut the last corner > even when there is nothing left to cut. Unsurprisingly, I have found the quality > of many (several I have seen so far) such products (which are in violation of > the GPL by using Linux and not publishing the source) lacking. As an example, a > certain router that has no source and several serious bugs, as well as a built > in upgrade path, that was never used, because the company preferred to stall and > drop the product instead of publishing the source. As a result, the firmware is > still at V0.0a and there is no way to fix it. That makes for a workhour-sink > doorstep for anyone not in on the bugs, who tries to make it work by tinkering > wit it, looking for a workaround. Good example. Must the source for the buggy application be available. Or is it sufficient to have only the infrastructure and the upgrade path? Or is the upgrade path required? These are not easy questions. There are no easy answers. If your answer is a flat "All source must be available." then most will continue to build completely closed source products that are still buggy and cost more because you have to pay for the infrastructure. What about the Aladdin model of a closed license for a limited amount of time, then freeing it? I don't want to cut the last corner. But in desktop space the LGPL libraries, the kernel exemption, and trivial infrastructure upgrades makes these non issues. How can this be translated into embedded space? > Compare this with the Cisco/Linksys WRT54GL which is still used for new > software solutions in 2007 (it was launched in 2002?! and has at least two > dozen alternative software packages, official and not, plus it sells for more > money than the original product! (and as an aside they seem to have pushed it > to 382km (!!!) link length - wow - in the Andes - > http://radar.oreilly.com/archives/2007/06/wifi_record_ran.html). I rather everything be open too. But given a choice of all closed and a hybrid, the pragmatist in me gravitates to the hybrid. The product will be cheaper and better solely because it uses a free infrastructure. > > So while I agree that free licenses should prevent abuse from the "taker > > only" mentality, there should be some place where commercial development > > can take place without requiring that all of their source be free. > > I guess, the bottom line is, "aggregate with that with which you can keep pace > with". If full open source publication cannot be considered for your product's > software (strictly! - this does not include embedded coprocessors! - hint, > hint), side, then leave GPL alone. The discussion started with leaving the GPL alone, not circumventing it. I'm bandying it about with you trying to understand if a hybrid even makes sense. My gut tells me it does, but I'd like to hear argument of why free infrastructure/closed application have no business in embedded space. > > Over the years I've become a firm believer in the "Your code is your code, > > and free code is free code." philosophy. I really don't care what a company > > does with the code they themselves develop so long as when they use free > > infrastructure, they contribute to the infrastructure. > > More or less always true, not just for code. Even drinks and munchies > contributed at a party work like that. > > > I have a feeling that's what Xiaofan is looking for. And to a degree he is > > correct in his belief that the GPL overcompensates in the embedded space > > because it seeks to turn your code into free code on hardware systems that > > cannot differentiate kernel space from user space. > > Yesno. Again, the GPL is probably not the best license for embedded. Maybe there > should exist a EGPL license for this. After all, if Linus has already 'bent' the > GPL for the kernel, to suit his purposes, he could do some more of it. But that > does not change the fact that the current GPL codebase is, and stays, GPL. And, > as others have discovered, the only solution in case of really wanting the > features, is rewriting from scratch. This can be done before or after the s**t > hits the fan, at the implementor's discretion (and love for egg on the face and > worse). That's painful. Coprocesssors huh?! Simpler solution is to upgrade to hardware that facilitiates separate spaces. That ends the problem probably at additional hardware cost though. BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist