Byron Jeff clayton.edu> writes: > 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. You are right. On the other hand, they do not have to use anything GPL, since they do not agree with the GPL. At all. So they should not use anything GPL. What is unclear. It is very very simple. Closed source + GPL -> lawsuit. Now. Git. > 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. We do not disagree. The only point to be made is the *fact* that currently GPL code never will be anything other than GPL. There will be other licenses, there will be other codebases, but this one won't. That's all. > 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. Correct. But according to the license you must indicate this, and provide a working media (incl. d/l) to a working copy of the source that does what your device's kernel does. Because the code you put into a device is 'distribution'. If you do not publish source, you are breaking the license. Simple. (encryption has been tried - it has failed, they got caught and sued - for more money than without encryption, as it was considered malice afair). > 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 do not agree. The WRT54GL and other devices are proof that this is so. > 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. Correct. That's why valuable already built infrastructure is protected by the GPL. So it cannot be used in a spirit different from that of the GPL. Deliberately. > 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. Every developer is free to develop and publish his or her own stuff. But *forget* about changing the purpose or the license of GPLd code. As I wrote above, it's really easy: source or walk (nothing personal of course). I write closed source and open source code. I think that I know the difference. > 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. You don't need to do anything. It's, again, simple: nobody is forced to use any GPL code. According to the commercial vendors, and there are plenty, their offer is better. Why use GPL when you can have something better ? If you need free free, as in air, use an open source BSD variant. Just, again, don't expect the GPL people to turn towards you and oblige. Every person who publishes GPL code has his and her reasons. Who am I to discuss them ? > 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. Exactly. And until a solution will be found, perhaps in the form of the EGPL, the WRT54GL model will be the only one that will work. A consumer product that has become something of a legend and outsold its expected lifetime by about five years. The makers are likely at the point where they just reorder units and count the money. Nor is the WRT54GL alone. At www.linuxdevice.com, as you know, many of its brothers and sisters are preparing to share its fame (adn fate). > > 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. Try to look at it in causality order: developers join a GPL project for their reasons. They write kernel code for 10 years, agreeing about the license for all this time, and contributing in the belief that the license will protect their IP in that spirit. Dozens, hundreds of them. Then someone decides from the outside that he likes the code so much he'd like to put it in a box with his name on it. Can he do it ? No. Why ? Because the GPL is there to prevent that. Game over. In causality order, his need to do something about the GPL comes 10 years too late (actually more like 16 or so). The someone who would like to repurpose and box the nice product is actually repeating what the US government did with Unix source code in the 1980s, giving back to At&T something they no longer owned, pissing off two dozen universities and probably a million students over the following 10 years (they had to do homework 'on paper'), and even facing UCB which sued and won (settled out of court afaik) over the code it contributed to Unix, thus giving birth to BSD *nix as it is known today. And THAT is precisely what the GPL is designed to prevent, before the fact. > 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. Again, yesno. The flash code is forced upon users by is use by webmasters. You do not *have* to use flash, least of all on linux. But you decided to use it, and found a way. Yet, it is a way that has nothing to do with the kernel. It is a standalone library that can be installed on a plethora of systems. Had it been a kernel mode driver, it would have been a different type of thing. And that's the point. After all, one can run ff and flash on FreeBSD with the linux personality module loaded. No problem. > 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. I don't want anything, I just learned that I need to pay careful attention to what is being said and written. The licenses say that the linux kernel is GPL, and always open source. Always means always. Period. No amount of arguing is going to change that. And I am not extending anything into application space. I am saying, and repeating, one simple fact: kernel == GPL == open source. Published, as you use it, verifiably. Iow, if you say the kernel source for your gizmo is at http://a.b.d/src/this.tgz then that package *must* be downloadable, compilable and work in your device, as a total drop in replacement for what you are using (the kernel part). If it does not, then it is assumed that you modified it and that you did not publish the mods. Then, you are in breach, and get to cease and desist. Again, the WRT54GL publishes the full kernel sources, not the application. The application code of the WRT54GL is closed, and nobody has a problem with that. > > GPL ... 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? Well, if you read the paragraph above, you know how. It's easy. Make a kernel that does what you need (possibly contributing what is needed, such as an ioctl here and there or whatever you need, KNOWING that that ioctl will be fully released as source from start). Put it somewhere where interested developers can find it, publish the location in the docs or whatever, and have at it. You can build any applications you want on top of it, they stay yours. The kernel, you just 'borrowed'. That's the way it is. > There are three fundamental questions with licenses in embedded space: > > 1) Do source and modifications to the infrastructure need to be released? YES if the infrastructure is the kernel. > 2) Does source for the application need to be released? NO, never. UNLESS they are linked against something not GPL. LGPL is ok, GPL is not. > 3) Does the user have the right/ability to upgrade the infrastructure? YES, HE MUST. And this is what is verified. If this fails, you are in breach without any doubt. > 1) Yes. Infrastructure modifications must be released. > 2) Yes. Source for the application must be released NO. > 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. Please see above. You already have what you say you want to have. It exists now. > 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. There is no 'embedded space'. Nobody cares how the upgrade is done as long as it can be done by any suitably technical person (and especially by the author of the code himself). > 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? It removes the possibility to verify that the kernel is unmodified. This is as bad as encryption, and represents malice. Keep in mind the spirit of the license. > > 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 'Space' is hard to define. If you use kernel API function calls you are in breach. If you use the syscall interface you are clean. BUT remember your application must be relinkable against another compatible kernel compiled by someone else. The Zaurus is a good example because there you have exactly this case. The missing MMU makes it nearly impossible to trace any 'kernel calls' (excepting by using hardware tracers). > 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? Please examine the existing living examples and draw your own conclusions. It is clear that the model works as is now. It could be better, but it works now. Why not use it instead of trying to find problems where there are none ? > > 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? The upgrade path for the kernel is required (see above), as well as for the libraries which are not 'yours' (must be LGPL). The application ? Who gives a hoot. Again, the WRT54 example is very good. 2 dozen alternative applications. One does not work ? You have 23 left to try, or write your own. In this case, the application was another 'lifted' GPL application, and the people who jinxed this box did not know how to fix it (the real GPL application out in the wild has the same bug). I suppose that there was a kind of scandal at the company and sparks (and maybe developers) flew. I happen to know that the relevant company has a type of gung-ho spirit that is misplaced in responsible embedded development, and that this particular box was far from being the only stinky part from them. They are on the list of people I would not work with or for, by the way. > What about the Aladdin model of a closed license for a limited amount of > time, then freeing it? That also works, but not for the GPLd part. You could use that for the application. Start a forum and let your 'older' versions 'slip' into the public domain/GPL. But do expect the users to pick it up and overtake you if it's worth anything (technically). Again, look at WRT54: the alternative packages implement everything from file server to Asterisk PBX on that box, besides kiosk mode WiFi access point and 100 other things the original developers never thought about. The original software now looks a bit puny by comparison with what is available from 3rd parties (some for good money!). Read for yourself: http://en.wikipedia.org/wiki/WRT54G > 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? That's pretty easy. DO allow kernel upgrades and publish the source and you're done (of course make sure you use LGPL libraries if any and that they too are upgradeable). > 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. Excepting for the limitations above, why not. Just remember free means free for anyone, not just yourself. THAT is the point of the GPL. > 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. There are plenty of hybrids out there. Understand that which is yours and that which is not. The requirement for the other stuff is 'upgrade-ability' and open source in compilable form for GPL parts. > That's painful. Coprocesssors huh?! Well, a PIC or two doing embedded work in a larger project controlled by a PC running plain Linux and a custom application, ARE coprocessors. > Simpler solution is to upgrade to hardware that facilitiates separate > spaces. That ends the problem probably at additional hardware cost though. Yesno. Separate spaces do not solve anything. Providing the technical path to upgrade that which must be upgradeable is, and providing compilable source for that which must be provided is a must. Peter P. --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist