I wouldn't normally respond to a post with this tone, but in this case I make an exception.
I have rewritten dozens of libraries that I could only find in GPL. And released my implementations under a simple (don't sue if it doesn't work) BSD license so other commercial developers could benefit from my work.
I don't freeload. I just make the code truly free.
(sigh) Here restarts the classical and purely semantic debate about what the GPL does or does not do.
I do agree that "forever" was arguably too strong a term, as it could imply alternate license negotiations are prohibited, which as you point out is not the case with single author GPL source.
So what's your point? That GPL tainted code isn't tainted if I obtain untainted code from the authors? Yes, I'll agree with that, but then it isn't GPL code, is it.
I am tired of hearing GPL defenders making such ridiculous assertions over what is essentially a semantic issue. Lets see - you also object to my use of the term "taint" on moral grounds. Look, if you believe that the GPL will make us all free, then stand up for the GPL - and all of its clauses, with all of their implications.
Please don't try to deflect criticisms of the GPL by pointing out that by negotiating terms other than the GPL you can resolve specific complaints with the GPL - most defenses of the GPL I have heard attempt this. As to negotiating licenses external to the GPL, I've been there and been asked to pay exorbitant fees for the "privilege" of not wishing to post my own source, numbers in excess of $1M. I would stipulate that use of the GPL functions as a significant deterrent to releasing code under a non-GPL license, as I would argue was part of its intent. Additionally, it is sometimes impossible to craft satisfactory terms for release of previously GPL'd code into a source base under other terms such as BSD. The use of the ex-GPL is often restricted to the point that it severely limits the reusability of the code using it, due to the need for all subsequent uses to negotiate license terms. I'm not talking commercial code here, just unencumbered open source.
The GPL debate to me is summed up simply: GPL code cannot be used in non GPL code, and GPL prevents the use of any traditional business model (other than VC/IPO fed burn rate games), and serves primarily as a "poison pill" to commercial developers. To GPL code is to say "you can use my code as long as you don't make any money with it, and I get all of your code too." In some code niches the GPL is appropriate, in most larger application spaces it is not, as someone does have to pay the bills, and not all of us are willing to work as waiters to subsidize our coding.
If you want to argue GPL vs. open and truly unencumbered source licenses, I'd be glad to entertain the discussion, online or off. Lets not waste time arguing semantics or pretend the GPL does less than it does.
Personally, I consider the GPL evil - it forever locks reusable code into a non-commercial model. I used to release reusable code under LGPL, now I use BSD.
That said, I completely agree w/ Carmack. This is his commercial work, he could release under a license stipulating that licensees were required to pour Cherry Slurpees over their head before redistributing, and he could sue anyone who chose to circumvent said clause.
If Slade doesn't like the GPL, he shouldn't have used GPL tainted code. Now he gets to pay the piper, or we get an interesting (and LONG due!) test case for the GPL's working.
I've been offered jobs in other states, only to find out the companies try and make you sign employment agreements with multi-year "non-compete" clauses and assignments to the company of any personal work that be related to anything the company might ever wish to think about.
These are both illegal in California, so I'm still here. Plus I like my cable modem, DSL line, the beaches, Skiing, and Yosemite.
Gun laws do suck here though, and getting worse - pretty soon it'll be illegal to defend yourself with anything other than a muzzleloader equipped with retinal scan, police remote disable receiver, GPS transponder, and a row of "are you sure" buttons. I may have to reconsider.
I do agree that we have similar views on some of the problems and their solutions, and I know my bias against broad statements is asserting itself, but I think that you are pushing open source as a solution when it only gets us halfway there.
Also, my comments on information hiding weren't meant to ignore your comments on thread monitoring, only to insist that information hiding is only a solution for a narrow subset of the problem space. Threat monitoring scales far better with application scope and threat models. (Even in the real world.)
Point (d) is interesting. r/e peer review, I've worked at and with companies that took both extremes of peer review - some companies view it as important, others a rubber stamp political process. In a commercial environment that must protect its IP to survive, peer review may be the only acceptable option using internal resources. People like myself have been hired to review alledgedly secure systems, and if the consultant actually knows what the heck their doing, then it can work. OTOH, most of my clients didn't want to hear the truth - I won't miss that sideline...:)
I also must disagree that open source alone can "force designers to use provably secure methods" - I've seen bad designers in commercial and open source systems, and often open source teams are pressed to get systems up and running quickly (lest another team finish that segment first). I've seen bad design principles here in as many varied ways.
I would argue that the greatest strength of Open Source r/e security is in its ability to (a) expose security problems before they are exploited, and (b) allow those problems to be corrected by anyone with the skillset, without waiting for the original developers to get around to it.
I would additionally stipulate that the skillset involved in designing {foo} software does not necessarily also mean those designers have the skillset needed to do a very good job in making it secure. Most of my peers consider security to be that "boring", "tedious", "annoying" thing that forces them to memorize "stupid" passwords.
Open source design paradigms may help bring security experts and software designers together, but I think the general statement "only open source can force designers to use provably secure methods" is wrong because so few programmers even know what "provably secure methods" are.
In fact, I could argue that there are very few "provably secure methods", if any. There are some cryptographic methods with expired patents that may provide tools, but few programmers know how to use them properly. Even smart software tamper detection can be defeated with various trivial attacks.
I know that most of my peers in security agree with the assertion that any software calling itself secure should receive the scope of review possible with open source.
I think that my problem, as some others who read your essay, was the implied assertion that using the open source process will make your software secure. Unless the initial open source team includes a real security expert, it probably wont be. And judging from the posts on BugTraq, it rarely is.
I written this sort of code for a living for 10 years, and ESR doesn't even come close to understanding the technical issues involved. Instead, he's taken snippets from recent posts and built upon them yet another pulput for "open source will save you". His assumptions and solutions are flawed.
Even Carmack's comments are predicated on yet another assumption - an environment of primarily statically loaded entities. Even through the use of extensive preprocessing and highly efficient resource management, it can take hundreds (or thousands) of milliseconds to load and initialize geometry before it comes into view. Quake can avoid this with small level size, low entity count, large memory footprint, local large disk or CD cache, and long level setup time.
If VR applications are to move past the common set of constraints Quake imposes (which are completely acceptable for its genre of gameplay), then more issues are introduced.
Very large worlds running across many distributed servers, clients utilizing continuous level of detail and realtime streaming preloading make it possible to wander around infinite sized worlds and never have to wait for a "loading" screen to interrupt the "suspension of disbeleif" so important in games. ESR's simple "fix" breaks this.
If you want to prevent information cheating, you have code at the servers which examine user actions and determine if they appear to be acting on more information than they should have according to the game policies and the distributed master clock. This works for people shooting at targets on their way around corners, as well as aim bots. Simple heuristics can filter out false positives, such as lucky shots.
Use digital certificates for robust user authentication with a difficult to automate "create new user" system and you've raised the price for cheating. Cheaters can be locked out, or even better, placed into games with each other seperate from the non-cheating players.
I agree that Open Source is the way to go - security by obscurity is why most systems calling themselves "secure" are laughable to those who work in the field. But it is not a magic bullet.
ESR's lessons: (a)Never trust a client program to be honest - This is absolutely correct, and I'd add that servers shouldn't be trusted to be honest either - clients should watch servers, and servers should watch each other.
(b) you can't have real security if you trade it away to get performance, - I agree with this truism.
(c) real security comes not from obscurity but from minimum disclosure, No, real security also comes from protecting information and actively monitoring for compromises. Minimum disclosure only works in a small subset of security models. If I hide a spreadsheet column that is too sensitive, and that column is needed, then no work will get done with that spreadsheet even if the client is open source.
(d) only open source can force designers to use provably secure methods. I hate to berate open source, but I must, as this comment is the pulpit speaking. I would argue that "peer review" has worked just fine in many situations - the NSA has done quite well providing strong ciphers for its clients (by this I mean the ones it cares about actually protecting) without open source. Open source is a superset of classical "peer review" in this regards.
There are some interesting lessons in this source base release. I hate to see them abused as a pulpit for incorrect information, especially when it hits near home (I run an open source massively distributed VR project).
If anyone wants to learn more about the few hundred other cool technical problems in online VR, a recent book ("Networked Virtual Environments" ISBN 0-201-325577-8) provides a great overview, its the first I've seen that was written by people who knew what they were talking about.
GPL does more than prevent closed source forks, it prevents any use, in whole or in part, that do not comply in whole with its license. This prevents reuse of subsets, even individual lines of code (subject to arguable limits of "fair use" interpretation), by non-GPL code. This doesn't help make code more "free" - its more like a club - unless your're GPL, you can't take advantage of ANY work done under the GPL.
Second, "the greatest things that require the most effort already are open source" - so, has everything that can be written, already been written?
GPL works fine for closed scope projects like an operating system. It bites for shared library and application development, unless you buy into the flawed business model that all applications can be developed and given away for free. Sooner or later somebody has to pay the electricity and ISP bill...
Disagreements like this wouldn't exist if the GPL were remotely close to perfect. In the real world the GPL has only limited use. The FSF preaches it as the cure to all software licensing woes. They too are simplistic in vision - we still live in a capitalistic soceity, and we don't all want to be waiters.
"Data that is supposed to confidential" is the problem. With very limited exceptions, most data related to consumer activities is not legally protected. And there are cases where data is legally protected, but mega-mergers have created situations where one division can access data belonging to another division giving it access to data which would have been illegal to read. In this case it is now legal since its not being "shared" between companies, merely shared between arms of the same company. This includes insurance and medical information, BTW, not just charge slips.
Second, it is practically impossible to obtain services (banking, insurance, credit cards) without waiving most of the right you might otherwise have - its all in the fine print of the agreements. Don't like it? You get to keep your money in your matress.
Third, do you plan on suing everyone that misuses your data? Your banks, insurance company, the DMV, the unilities, your grocery store, ect. ad nauseum. The combined legal budgets of these entities exceeds those of most small countries. Hope you have a BIG matress. :
Fine - there is no initial link between your PSN and your identity. However, as soon as you go online, you start leaving big tracks pointing to your shack in the woods. Even your chained SSH connections through root-kitted hosts can be backtracked through traffic analysis, and it only takes one mistake or insecure program to reveal all.
More importantly, "big databases" mean that once a correlation is established between your PSN and your SSN, your anonymity is gone. And to the extent any logs exist of your activities before this correlation was established, your previous activites are now known.
Before you laugh too loud, making these sorts of correlations between "anonymous" credit card statements sold by your bank and data sold by your merchants is already a hundred million dollar (or more) industry in the US.
Add what is being done in the name of fighting terrorism and hate crimes, and (if you are a US citizen) you have no privacy. You just don't realize it yet.
Option 4 is allowed under the GPL! The "General Public Virus" whiners want to eliminate this option: they want to deprive me of my rights to make money or do what I want with my code! They want to remove the very rights they pretend to "defend".
Your assertion is interesting but untrue. Coders who release under GPL always retain the option of releasing under another parallel license, but this is neither unique to GPL, nor prevented in any other "open source" license.
What us "General Public Virus" whiners want RMS and his acolytes to stop denying is the simple fact that the GPL does infect code it is used in. Stop using ad hominym, subterfuge, or misdirection, and call the spade a spade.
RMS used the phrase "Strictly speaking" to qualify a lie, to give himself plausable deniability when deflecting the core criticism of GPL by making a highly misleading and untrue statement.
Us "General Public Virus" whiners merely want the truth to remain the truth, free beer or no free beer. I've used the LGPL too, by the way, its a great license. But GPL has implications far beyond sharing code, and this must be kept clear. Altrustic phrases and hand waving do not change the legal implications of the GPL.
RMS claimed "If someone has used some of my GPL-covered code in a program, and releases the program, I cannot make that person release the program under the GPL."
This is essentially a lie, and you and other GPL advocates do your license a disservice to dispute the point or play word games to dance around the simple truth.
Yes, if I use GPL code in my app, I can toss the hard drive into an incenerator and distribute the ashes, which lets me distribute without using the GPL! There are thousands of other scenarios in which I can distribute my application without placing it under GPL, but none of them are relevant to this discussion:
If I use a line of GPL code, and I want to distribute my app, I must make my entire app GPL. RMS implied otherwise. He lied.
Good lord, where has lucidity gone in these discussions?
The discussion was referring to the use of GPL code in another application. Therefore, your #2 is irrelevant. The GPL license issue we are discussing is terms for distribution of application source containing GPL code, therefore your #3 is irrelevant.
We are left with #1: Use GPL code in your app, and you MUST release your app under GPL, with all that entails.
Your post is a perfect example of why so many GPL advocates are viewed as extreme, irrational, or worse. Stick to the point, and have the courage to stand up for what your license really means.
Strictly speaking, nothing we free software developers do can legally require others to release their code in any particular way. If someone has used some of my GPL-covered code in a program, and releases the program, I cannot make that person release the program under the GPL. I can, however, deny permission to release my code on any other basis. That is what the GPL does.
The GPL is a legal document. If someone uses some GPL code and releases under a non-GPL license, you can sue them. The "Strictly speaking" sentence is technically true, but wholly inaccurate, misleading, and I would consider it an unethical assertion.
Yes, "strictly speaking", anyone can post anything they want under any license, and without time travel this cannot be prevented. That is not the point, and he knows it.
The GPL requires code it is linked against to become GPL'd. RMS's word games do his movement and the open source community a disservice. He needs to acknowledge this simple, basic element of the GPL, and stop playing FUD games around it.
FWIW, the FIRST application I plan on developing for my Handspring/Visor (well first hard one) when it arrives is SSH Telnet.
Also FWIW, I work in the security / crypto field and do exactly this sort of thing for a living, so I do know what I'm getting into.
It will be unencumbered open source. Might be Java though, I've got C++ and Java crypto libs and I need to look at the performance issues on that platform, but Java is faster to develop... I've already got SSH Telnet in Java, just have to reproduce JCE components.
Well, I hadn't planned to announce this yet, and we're probably going to get./'d even though the web site is wrong (for example, it says community source, but I changed my mind and are now releasing as unencumbered open source.)
I've worked in distributed networking for a long time, first in video games, then in multi-user VR. One thing I was always upset about was the low quality and high cost of available solutions to this problem (I wanted to stick to 3d engine design). On the other end of the spectrum were the "enterprise" solutions, where I was upset about the low performance and VERY VERY high cost.
To make a long story short, I'm about to release the first in a series of unencumbered open source libraries related to this problem. The initial release is of the distributed networking component.
It's an implementation of a Java JMS provider, where JMS is Sun's reference interface-only specification for enterprise messaging: Java Message Service. Available enterprise message bus software like JMS providers can price up into the 7 digits, and still suck.
We chose Java as a reasonable first pass at cross-platform, but the code was designed to port to ANSI C/C++ easily - we already have XP ANSI C/C++ versions of most of the applicable Java platform libraries. The network protocols are defined in ietf-draft format and have no Java dependencies whatsoever. We already intent to release native Win32 and Linux versions of the server, and possibly the client.
I could type for days about performance and features, but suffice to say it implements the full JMS Publish/Subscribe spec, with substantial extensions for security (one evaluating user is preparing for NSA certification, as we use secure protocols and provide features like compartmentalization across bridged secure networks), packet and real time streams managed using JMS "Topic" abstract addressing (one demo app is full duplex audio chat), and reliability (n-way hot failover, adaptive load balancing, and massive scalability across complex network topologies.) Its about to interact with LDAP servers for user authentication, it uses XML based configuration files, supports dependant handling auto-update according to site policies, is getting a JSP based remote admin feature, and washes dishes on alternate Thursdays.
BTW, if you want to send CORBA, DCOM, OLE, XML, or any other funky object, just encapsulate it. JMS tries to abstract away these issues - it's a good API.
If anyone is interested in this, the base API alpha release (including FULL source) should be early-end of next month, just email me. No mailing list yet, we're still setting up the public CVS server and new web site. I'm releasing a pre-pre-pre alpha next week, so its not like I still have 90% of the code left to complete.
Preemptive comment - Please minimize the "vaporware" status flaming, I mentioned that issue in my subject line. I'm giving away a substantial percentage of the IP I've personally developed over the last 5 years here, primarily 'cause I need more people to help me improve it and the rest of the VR system I'm building. I'm tired of making VC people rich, now I just want to see something cool make it to market. If I have to give it away, so be it...
The Web3D Consortium is "cooperating" with yet another for-profit entity, in this case Blaxxun. The source is not open, in fact the "community license" and addendum terms are one of the most restrictive yet released.
Blaxxun probably released it in an attempt to subvert mindshare away from the OpenVRML group and others now starting up that want to make a truly open source VRML browser.
As for "the Web3D Consortium", they will cut a deal with anyone who will pay their bills or keep them in the drivers seat in behalf of their corporate sponsors: Microsoft, Blaxxun, SGI, Sony, Apple, ect.
They had lofty goals. Politics and money have made it impossible for any of them to be acheived. This deal is no exception.
Your mixing metaphors. Proprietary software is not necessarily the same thing as commercial software - consider the new Sendmail, using the value-add model on top of open source base. Is that an evil to rid the world of? GPL does more than prohibit proprietary use - it also prohibits commercial use. These are not necessarily the same - the best commercial software is written to open standards.
"extremely dangerous"? Part of the problem with this discussion is that too many individuals elevate their opinions to that of a religion statement, and refuse to consider rational arguments that refute their basic tenets.
I believe in truly unemcumbered "open source" software. GPL is the most invasive, restrictive, infectuous license in general distribution. It attempts to impose a communist or altruistic business model on the software developers. How is that not infinetely more dangerous than a simple waiver of liability?
I find this topic fascinating, and it has personally come up repatedly over the 15+ years I've been programming professionally. I'm dealing with it again as I prepare to release a few man-years of IP into open source.
GPL is a touchy subject because it imposes such severe restrictions on reuse, while being praised under the "open source" monkier.
GPL'd source may essentially never be used in a commercial project again, as all projects it is used within are forced to become non-commercial and subject to GPL.
Many programmers, such as myself, cannot understand why it isn't a larger issue. Only programmers remaining in academia or working in a non-capitalist market can ignore the consequences of GPL and pretend that all is OK. There are a few companies buoyed on Internet Stock IPO's that would argue the point, but I'd point them to their balance sheet r/e burn rate vs. actual revenue.
It's an "open source" license that _forces_ you to change your business model to an indirect one, such as selling support or distribution packages at near-cost. The source is "open", but the terms of use are more invasive than the most predatory license agreements I've ever seen. This has been wildly successful for some niche systems in leau of legal challenges, but should all software development go this route? Most programmers would starve to death.
"Lying"? If facts annoy or disturb you, feel free to refute them - it keeps the conversation productive. Personal perjoratives are out of line unless you can support your accusation.
The revenue streams that sustain most "Open Source" companies have little to do with software development - They derive primarily from redistribution and support (RedHat, SuSE, Caldera), are subsidized from other aspects of the business, or are "burn-rate" statistics in the Internet Stock phenomemon. There are exceptions, such as development tools (Cygnus) or open source reverted to quasi-commercial via value-add(sendmail).
Wasn't Cyclic one of the first true open source companies to turn a balance sheet profit on support sales of an open source product? But they spent years and had a tremendous market share before doing so.
Allow me to clarify: Being a software engineer, when I say "software" "may never be used commercially again by any other party", I mean the source code may never be used again in a commercial product. (In the future I'll be more careful r/e my choice of vernacular in this point, I can understand how a non-programmer [and some programmers] could easily misunderstand this.)
To me and many of my peers who write code for a living, the intellectual value of those subroutines and libraries, once placed under GPL, is forever wasted to any other developers unless they can place their entire application under GPL. So we continue to reinvent the wheel, and release what we can under a non-GPL license that is open and unencumbered.
Personally, I find the use of the term "open source" in conjunction with "GPL" to be offensive. "Open" source should be unencumbered source.
A clever play on words to denegrate the "Virus" term, yet also incorrect in many ways, and inapplicable - far more so than the political, technically misleading phrase "Self-Perpetuating".
The purpose of a vaccine is to stimulate a preemptive immune resonse to a future exposure to some dangerous substance. I don't see what GPL has in common with that, other than tertiary behavioral aspects listed above.
On the other hand, a clause in a agreement expressly forbidding the inclusion of any GPL code would meet the general definition of a vaccine.
The reproductive vectors of a virus bear an amusing similarity to that of the GPL license clause. I am a strong supporter of truly "open source" software - I release 75% of the code I produce, and am constantly evangalizing my employer to let me release more. Yet I can't stand the idea of a license that imposes its terms on everything it is used with. That "infectious" nature of GPL earned it the derogatory moniker of "Viral", which happens to be technically accurate.
The reason behind this debate is simple - GPL only allows the originator of software to make money. From that point on, it may never be used commercially again by any other party. That is an unacceptably broad restriction, and it hurts development signifigantly - commercial entities have far more resources available to contribute. If they can work together under open standards, far more will be accomplished than under the nearly communistic paradigm that GPL seeks to impose. "Viral" is the least of the derogatory terms that could be applied. It seeks a lofty goal, but does so in a highly questionable, politically polarized manner.
Simple question - If GPL is the 'one true way leading to eternal life', why does this debate persist?
"Self-perpetuating" is an inaccurate euphamism in this context. If you wish to play syntactical games, then GPL cannot be called self-perpetuating.
First, it requires the actions of the computer it is running on and the software it has been embedded into to "spread", so it does nothing by "self" by any definition of the term.
Second, GPL does far more than "perpetuate" - since its license circumvents the license of the entire application it comes into contact with and changes the license of the entire source base to match its own, "viral" is the only correct term.
Whether GPL is "good" or "bad" is another debate, but please don't attempt to apply euphamisms to it, especially an incorrect one that obsfucates critical issues.
I agree completely in principal. However, there are issues that change the magnitude of the work. The classic question - what if fundamental breakthrough exist that allow the NSA to decrypt ciphers in use with a trivial workload? Most ciphers in use today rely either on the difficulty of factoring large numbers or on the complexity of Feistel networks.
The number sieve is one of the best techniques known publicly to reduce the workload of factorization by orders of magnitude, and work progresses on methods beyond differential and linear cryptanalysis. Who knows what techniques are known to the NSA? Additionally, the figures that have been published in regards to the abilities of massively parallel custom hardware for brute force or more elegant attacks are grossly underestimating the capabilities of both chip designers and system integrators.
I do still agree that massive deployment of crypto would greatly help by significantly increasing the resources needed to decrypt all flagged traffic. IPSec without key escrow, or transparent systems like Swan would do nicely for this. Monitoring will still be done, albeit "dragnet" style monitoring would be severely curtailed.
Current USGOV policies remain merely a holding action to deter the widespread deployment of a PKI (public key infrastructure) and its integration into commonly used electronic messaging products, such as email, until they can figure out how to make domestic use of encryption illegal or force key escrow.
When the letter instituting this policy was finally released under FOIA, I placed a copy up on the wall next to my desk.
The NSA is not concerned about message traffic volume, this remains a red herring despite the growth of the internet. Parallelism works fine in this application, and traditional budgetary issues simply do not apply. Think about it.
Slashdot Mirror
I wouldn't normally respond to a post with this tone, but in this case I make an exception.
I have rewritten dozens of libraries that I could only find in GPL. And released my implementations under a simple (don't sue if it doesn't work) BSD license so other commercial developers could benefit from my work.
I don't freeload. I just make the code truly free.
(sigh) Here restarts the classical and purely semantic debate about what the GPL does or does not do.
I do agree that "forever" was arguably too strong a term, as it could imply alternate license negotiations are prohibited, which as you point out is not the case with single author GPL source.
So what's your point? That GPL tainted code isn't tainted if I obtain untainted code from the authors? Yes, I'll agree with that, but then it isn't GPL code, is it.
I am tired of hearing GPL defenders making such ridiculous assertions over what is essentially a semantic issue. Lets see - you also object to my use of the term "taint" on moral grounds. Look, if you believe that the GPL will make us all free, then stand up for the GPL - and all of its clauses, with all of their implications.
Please don't try to deflect criticisms of the GPL by pointing out that by negotiating terms other than the GPL you can resolve specific complaints with the GPL - most defenses of the GPL I have heard attempt this. As to negotiating licenses external to the GPL, I've been there and been asked to pay exorbitant fees for the "privilege" of not wishing to post my own source, numbers in excess of $1M. I would stipulate that use of the GPL functions as a significant deterrent to releasing code under a non-GPL license, as I would argue was part of its intent. Additionally, it is sometimes impossible to craft satisfactory terms for release of previously GPL'd code into a source base under other terms such as BSD. The use of the ex-GPL is often restricted to the point that it severely limits the reusability of the code using it, due to the need for all subsequent uses to negotiate license terms. I'm not talking commercial code here, just unencumbered open source.
The GPL debate to me is summed up simply: GPL code cannot be used in non GPL code, and GPL prevents the use of any traditional business model (other than VC/IPO fed burn rate games), and serves primarily as a "poison pill" to commercial developers. To GPL code is to say "you can use my code as long as you don't make any money with it, and I get all of your code too." In some code niches the GPL is appropriate, in most larger application spaces it is not, as someone does have to pay the bills, and not all of us are willing to work as waiters to subsidize our coding.
If you want to argue GPL vs. open and truly unencumbered source licenses, I'd be glad to entertain the discussion, online or off. Lets not waste time arguing semantics or pretend the GPL does less than it does.
Personally, I consider the GPL evil - it forever locks reusable code into a non-commercial model. I used to release reusable code under LGPL, now I use BSD.
That said, I completely agree w/ Carmack. This is his commercial work, he could release under a license stipulating that licensees were required to pour Cherry Slurpees over their head before redistributing, and he could sue anyone who chose to circumvent said clause.
If Slade doesn't like the GPL, he shouldn't have used GPL tainted code. Now he gets to pay the piper, or we get an interesting (and LONG due!) test case for the GPL's working.
These are both illegal in California, so I'm still here. Plus I like my cable modem, DSL line, the beaches, Skiing, and Yosemite.
Gun laws do suck here though, and getting worse - pretty soon it'll be illegal to defend yourself with anything other than a muzzleloader equipped with retinal scan, police remote disable receiver, GPS transponder, and a row of "are you sure" buttons. I may have to reconsider.
Also, my comments on information hiding weren't meant to ignore your comments on thread monitoring, only to insist that information hiding is only a solution for a narrow subset of the problem space. Threat monitoring scales far better with application scope and threat models. (Even in the real world.)
Point (d) is interesting. r/e peer review, I've worked at and with companies that took both extremes of peer review - some companies view it as important, others a rubber stamp political process. In a commercial environment that must protect its IP to survive, peer review may be the only acceptable option using internal resources. People like myself have been hired to review alledgedly secure systems, and if the consultant actually knows what the heck their doing, then it can work. OTOH, most of my clients didn't want to hear the truth - I won't miss that sideline... :)
I also must disagree that open source alone can "force designers to use provably secure methods" - I've seen bad designers in commercial and open source systems, and often open source teams are pressed to get systems up and running quickly (lest another team finish that segment first). I've seen bad design principles here in as many varied ways.
I would argue that the greatest strength of Open Source r/e security is in its ability to (a) expose security problems before they are exploited, and (b) allow those problems to be corrected by anyone with the skillset, without waiting for the original developers to get around to it.
I would additionally stipulate that the skillset involved in designing {foo} software does not necessarily also mean those designers have the skillset needed to do a very good job in making it secure. Most of my peers consider security to be that "boring", "tedious", "annoying" thing that forces them to memorize "stupid" passwords.
Open source design paradigms may help bring security experts and software designers together, but I think the general statement "only open source can force designers to use provably secure methods" is wrong because so few programmers even know what "provably secure methods" are.
In fact, I could argue that there are very few "provably secure methods", if any. There are some cryptographic methods with expired patents that may provide tools, but few programmers know how to use them properly. Even smart software tamper detection can be defeated with various trivial attacks.
I know that most of my peers in security agree with the assertion that any software calling itself secure should receive the scope of review possible with open source.
I think that my problem, as some others who read your essay, was the implied assertion that using the open source process will make your software secure. Unless the initial open source team includes a real security expert, it probably wont be. And judging from the posts on BugTraq, it rarely is.
Even Carmack's comments are predicated on yet another assumption - an environment of primarily statically loaded entities. Even through the use of extensive preprocessing and highly efficient resource management, it can take hundreds (or thousands) of milliseconds to load and initialize geometry before it comes into view. Quake can avoid this with small level size, low entity count, large memory footprint, local large disk or CD cache, and long level setup time.
If VR applications are to move past the common set of constraints Quake imposes (which are completely acceptable for its genre of gameplay), then more issues are introduced.
Very large worlds running across many distributed servers, clients utilizing continuous level of detail and realtime streaming preloading make it possible to wander around infinite sized worlds and never have to wait for a "loading" screen to interrupt the "suspension of disbeleif" so important in games. ESR's simple "fix" breaks this.
If you want to prevent information cheating, you have code at the servers which examine user actions and determine if they appear to be acting on more information than they should have according to the game policies and the distributed master clock. This works for people shooting at targets on their way around corners, as well as aim bots. Simple heuristics can filter out false positives, such as lucky shots.
Use digital certificates for robust user authentication with a difficult to automate "create new user" system and you've raised the price for cheating. Cheaters can be locked out, or even better, placed into games with each other seperate from the non-cheating players.
I agree that Open Source is the way to go - security by obscurity is why most systems calling themselves "secure" are laughable to those who work in the field. But it is not a magic bullet.
ESR's lessons: (a)Never trust a client program to be honest - This is absolutely correct, and I'd add that servers shouldn't be trusted to be honest either - clients should watch servers, and servers should watch each other.
(b) you can't have real security if you trade it away to get performance, - I agree with this truism.
(c) real security comes not from obscurity but from minimum disclosure, No, real security also comes from protecting information and actively monitoring for compromises. Minimum disclosure only works in a small subset of security models. If I hide a spreadsheet column that is too sensitive, and that column is needed, then no work will get done with that spreadsheet even if the client is open source.
(d) only open source can force designers to use provably secure methods. I hate to berate open source, but I must, as this comment is the pulpit speaking. I would argue that "peer review" has worked just fine in many situations - the NSA has done quite well providing strong ciphers for its clients (by this I mean the ones it cares about actually protecting) without open source. Open source is a superset of classical "peer review" in this regards.
There are some interesting lessons in this source base release. I hate to see them abused as a pulpit for incorrect information, especially when it hits near home (I run an open source massively distributed VR project).
If anyone wants to learn more about the few hundred other cool technical problems in online VR, a recent book ("Networked Virtual Environments" ISBN 0-201-325577-8) provides a great overview, its the first I've seen that was written by people who knew what they were talking about.
GPL does more than prevent closed source forks, it prevents any use, in whole or in part, that do not comply in whole with its license. This prevents reuse of subsets, even individual lines of code (subject to arguable limits of "fair use" interpretation), by non-GPL code. This doesn't help make code more "free" - its more like a club - unless your're GPL, you can't take advantage of ANY work done under the GPL.
Second, "the greatest things that require the most effort already are open source" - so, has everything that can be written, already been written?
GPL works fine for closed scope projects like an operating system. It bites for shared library and application development, unless you buy into the flawed business model that all applications can be developed and given away for free. Sooner or later somebody has to pay the electricity and ISP bill...
Disagreements like this wouldn't exist if the GPL were remotely close to perfect. In the real world the GPL has only limited use. The FSF preaches it as the cure to all software licensing woes. They too are simplistic in vision - we still live in a capitalistic soceity, and we don't all want to be waiters.
"Data that is supposed to confidential" is the problem. With very limited exceptions, most data related to consumer activities is not legally protected. And there are cases where data is legally protected, but mega-mergers have created situations where one division can access data belonging to another division giving it access to data which would have been illegal to read. In this case it is now legal since its not being "shared" between companies, merely shared between arms of the same company. This includes insurance and medical information, BTW, not just charge slips.
Second, it is practically impossible to obtain services (banking, insurance, credit cards) without waiving most of the right you might otherwise have - its all in the fine print of the agreements. Don't like it? You get to keep your money in your matress.
Third, do you plan on suing everyone that misuses your data? Your banks, insurance company, the DMV, the unilities, your grocery store, ect. ad nauseum. The combined legal budgets of these entities exceeds those of most small countries. Hope you have a BIG matress. :
Fine - there is no initial link between your PSN and your identity. However, as soon as you go online, you start leaving big tracks pointing to your shack in the woods. Even your chained SSH connections through root-kitted hosts can be backtracked through traffic analysis, and it only takes one mistake or insecure program to reveal all.
More importantly, "big databases" mean that once a correlation is established between your PSN and your SSN, your anonymity is gone. And to the extent any logs exist of your activities before this correlation was established, your previous activites are now known.
Before you laugh too loud, making these sorts of correlations between "anonymous" credit card statements sold by your bank and data sold by your merchants is already a hundred million dollar (or more) industry in the US.
Add what is being done in the name of fighting terrorism and hate crimes, and (if you are a US citizen) you have no privacy. You just don't realize it yet.
Your assertion is interesting but untrue. Coders who release under GPL always retain the option of releasing under another parallel license, but this is neither unique to GPL, nor prevented in any other "open source" license.
What us "General Public Virus" whiners want RMS and his acolytes to stop denying is the simple fact that the GPL does infect code it is used in. Stop using ad hominym, subterfuge, or misdirection, and call the spade a spade.
RMS used the phrase "Strictly speaking" to qualify a lie, to give himself plausable deniability when deflecting the core criticism of GPL by making a highly misleading and untrue statement.
Us "General Public Virus" whiners merely want the truth to remain the truth, free beer or no free beer. I've used the LGPL too, by the way, its a great license. But GPL has implications far beyond sharing code, and this must be kept clear. Altrustic phrases and hand waving do not change the legal implications of the GPL.
RMS claimed "If someone has used some of my GPL-covered code in a program, and releases the program, I cannot make that person release the program under the GPL."
This is essentially a lie, and you and other GPL advocates do your license a disservice to dispute the point or play word games to dance around the simple truth.
Yes, if I use GPL code in my app, I can toss the hard drive into an incenerator and distribute the ashes, which lets me distribute without using the GPL! There are thousands of other scenarios in which I can distribute my application without placing it under GPL, but none of them are relevant to this discussion:
If I use a line of GPL code, and I want to distribute my app, I must make my entire app GPL. RMS implied otherwise. He lied.
The discussion was referring to the use of GPL code in another application. Therefore, your #2 is irrelevant. The GPL license issue we are discussing is terms for distribution of application source containing GPL code, therefore your #3 is irrelevant.
We are left with #1: Use GPL code in your app, and you MUST release your app under GPL, with all that entails.
Your post is a perfect example of why so many GPL advocates are viewed as extreme, irrational, or worse. Stick to the point, and have the courage to stand up for what your license really means.
The GPL is a legal document. If someone uses some GPL code and releases under a non-GPL license, you can sue them. The "Strictly speaking" sentence is technically true, but wholly inaccurate, misleading, and I would consider it an unethical assertion.
Yes, "strictly speaking", anyone can post anything they want under any license, and without time travel this cannot be prevented. That is not the point, and he knows it.
The GPL requires code it is linked against to become GPL'd. RMS's word games do his movement and the open source community a disservice. He needs to acknowledge this simple, basic element of the GPL, and stop playing FUD games around it.
Also FWIW, I work in the security / crypto field and do exactly this sort of thing for a living, so I do know what I'm getting into.
It will be unencumbered open source. Might be Java though, I've got C++ and Java crypto libs and I need to look at the performance issues on that platform, but Java is faster to develop... I've already got SSH Telnet in Java, just have to reproduce JCE components.
I too want this more than anything on my PDA.
And yes, I meant "/.", not "./"... :)
I've worked in distributed networking for a long time, first in video games, then in multi-user VR. One thing I was always upset about was the low quality and high cost of available solutions to this problem (I wanted to stick to 3d engine design). On the other end of the spectrum were the "enterprise" solutions, where I was upset about the low performance and VERY VERY high cost.
To make a long story short, I'm about to release the first in a series of unencumbered open source libraries related to this problem. The initial release is of the distributed networking component.
It's an implementation of a Java JMS provider, where JMS is Sun's reference interface-only specification for enterprise messaging: Java Message Service. Available enterprise message bus software like JMS providers can price up into the 7 digits, and still suck.
We chose Java as a reasonable first pass at cross-platform, but the code was designed to port to ANSI C/C++ easily - we already have XP ANSI C/C++ versions of most of the applicable Java platform libraries. The network protocols are defined in ietf-draft format and have no Java dependencies whatsoever. We already intent to release native Win32 and Linux versions of the server, and possibly the client.
I could type for days about performance and features, but suffice to say it implements the full JMS Publish/Subscribe spec, with substantial extensions for security (one evaluating user is preparing for NSA certification, as we use secure protocols and provide features like compartmentalization across bridged secure networks), packet and real time streams managed using JMS "Topic" abstract addressing (one demo app is full duplex audio chat), and reliability (n-way hot failover, adaptive load balancing, and massive scalability across complex network topologies.) Its about to interact with LDAP servers for user authentication, it uses XML based configuration files, supports dependant handling auto-update according to site policies, is getting a JSP based remote admin feature, and washes dishes on alternate Thursdays.
BTW, if you want to send CORBA, DCOM, OLE, XML, or any other funky object, just encapsulate it. JMS tries to abstract away these issues - it's a good API.
If anyone is interested in this, the base API alpha release (including FULL source) should be early-end of next month, just email me. No mailing list yet, we're still setting up the public CVS server and new web site. I'm releasing a pre-pre-pre alpha next week, so its not like I still have 90% of the code left to complete.
Preemptive comment - Please minimize the "vaporware" status flaming, I mentioned that issue in my subject line. I'm giving away a substantial percentage of the IP I've personally developed over the last 5 years here, primarily 'cause I need more people to help me improve it and the rest of the VR system I'm building. I'm tired of making VC people rich, now I just want to see something cool make it to market. If I have to give it away, so be it...
Blaxxun probably released it in an attempt to subvert mindshare away from the OpenVRML group and others now starting up that want to make a truly open source VRML browser.
As for "the Web3D Consortium", they will cut a deal with anyone who will pay their bills or keep them in the drivers seat in behalf of their corporate sponsors: Microsoft, Blaxxun, SGI, Sony, Apple, ect.
They had lofty goals. Politics and money have made it impossible for any of them to be acheived. This deal is no exception.
"extremely dangerous"? Part of the problem with this discussion is that too many individuals elevate their opinions to that of a religion statement, and refuse to consider rational arguments that refute their basic tenets.
I believe in truly unemcumbered "open source" software. GPL is the most invasive, restrictive, infectuous license in general distribution. It attempts to impose a communist or altruistic business model on the software developers. How is that not infinetely more dangerous than a simple waiver of liability?
GPL is a touchy subject because it imposes such severe restrictions on reuse, while being praised under the "open source" monkier.
GPL'd source may essentially never be used in a commercial project again, as all projects it is used within are forced to become non-commercial and subject to GPL.
Many programmers, such as myself, cannot understand why it isn't a larger issue. Only programmers remaining in academia or working in a non-capitalist market can ignore the consequences of GPL and pretend that all is OK. There are a few companies buoyed on Internet Stock IPO's that would argue the point, but I'd point them to their balance sheet r/e burn rate vs. actual revenue.
It's an "open source" license that _forces_ you to change your business model to an indirect one, such as selling support or distribution packages at near-cost. The source is "open", but the terms of use are more invasive than the most predatory license agreements I've ever seen. This has been wildly successful for some niche systems in leau of legal challenges, but should all software development go this route? Most programmers would starve to death.
That's a good reason to argue...
"Lying"? If facts annoy or disturb you, feel free to refute them - it keeps the conversation productive. Personal perjoratives are out of line unless you can support your accusation.
The revenue streams that sustain most "Open Source" companies have little to do with software development - They derive primarily from redistribution and support (RedHat, SuSE, Caldera), are subsidized from other aspects of the business, or are "burn-rate" statistics in the Internet Stock phenomemon. There are exceptions, such as development tools (Cygnus) or open source reverted to quasi-commercial via value-add(sendmail).
Wasn't Cyclic one of the first true open source companies to turn a balance sheet profit on support sales of an open source product? But they spent years and had a tremendous market share before doing so.
Allow me to clarify: Being a software engineer, when I say "software" "may never be used commercially again by any other party", I mean the source code may never be used again in a commercial product. (In the future I'll be more careful r/e my choice of vernacular in this point, I can understand how a non-programmer [and some programmers] could easily misunderstand this.)
To me and many of my peers who write code for a living, the intellectual value of those subroutines and libraries, once placed under GPL, is forever wasted to any other developers unless they can place their entire application under GPL. So we continue to reinvent the wheel, and release what we can under a non-GPL license that is open and unencumbered.
Personally, I find the use of the term "open source" in conjunction with "GPL" to be offensive. "Open" source should be unencumbered source.
The purpose of a vaccine is to stimulate a preemptive immune resonse to a future exposure to some dangerous substance. I don't see what GPL has in common with that, other than tertiary behavioral aspects listed above.
On the other hand, a clause in a agreement expressly forbidding the inclusion of any GPL code would meet the general definition of a vaccine.
The reproductive vectors of a virus bear an amusing similarity to that of the GPL license clause. I am a strong supporter of truly "open source" software - I release 75% of the code I produce, and am constantly evangalizing my employer to let me release more. Yet I can't stand the idea of a license that imposes its terms on everything it is used with. That "infectious" nature of GPL earned it the derogatory moniker of "Viral", which happens to be technically accurate.
The reason behind this debate is simple - GPL only allows the originator of software to make money. From that point on, it may never be used commercially again by any other party. That is an unacceptably broad restriction, and it hurts development signifigantly - commercial entities have far more resources available to contribute. If they can work together under open standards, far more will be accomplished than under the nearly communistic paradigm that GPL seeks to impose. "Viral" is the least of the derogatory terms that could be applied. It seeks a lofty goal, but does so in a highly questionable, politically polarized manner.
Simple question - If GPL is the 'one true way leading to eternal life', why does this debate persist?
First, it requires the actions of the computer it is running on and the software it has been embedded into to "spread", so it does nothing by "self" by any definition of the term.
Second, GPL does far more than "perpetuate" - since its license circumvents the license of the entire application it comes into contact with and changes the license of the entire source base to match its own, "viral" is the only correct term.
Whether GPL is "good" or "bad" is another debate, but please don't attempt to apply euphamisms to it, especially an incorrect one that obsfucates critical issues.
I agree completely in principal. However, there are issues that change the magnitude of the work. The classic question - what if fundamental breakthrough exist that allow the NSA to decrypt ciphers in use with a trivial workload? Most ciphers in use today rely either on the difficulty of factoring large numbers or on the complexity of Feistel networks.
The number sieve is one of the best techniques known publicly to reduce the workload of factorization by orders of magnitude, and work progresses on methods beyond differential and linear cryptanalysis. Who knows what techniques are known to the NSA? Additionally, the figures that have been published in regards to the abilities of massively parallel custom hardware for brute force or more elegant attacks are grossly underestimating the capabilities of both chip designers and system integrators.
I do still agree that massive deployment of crypto would greatly help by significantly increasing the resources needed to decrypt all flagged traffic. IPSec without key escrow, or transparent systems like Swan would do nicely for this. Monitoring will still be done, albeit "dragnet" style monitoring would be severely curtailed.
Current USGOV policies remain merely a holding action to deter the widespread deployment of a PKI (public key infrastructure) and its integration into commonly used electronic messaging products, such as email, until they can figure out how to make domestic use of encryption illegal or force key escrow.
When the letter instituting this policy was finally released under FOIA, I placed a copy up on the wall next to my desk.
The NSA is not concerned about message traffic volume, this remains a red herring despite the growth of the internet. Parallelism works fine in this application, and traditional budgetary issues simply do not apply. Think about it.