This sort of leak is impossible to detect except by a human, and even humans have trouble with it when the list is mixed with live and dead objects and the bits of code which "forget" about objects in the list without removing them are scattered everywhere.
No, not impossible.
Our manager would catch this, or any variation of this, first time it happened. This is because on exit, after legitimate cleanup is done (meaning, we deallocate the things we have been keeping proper track of... memory for windows, palettes, layer lists, that sort of thing), the internal memory pools are all tested for pointers that have not yet been deallocated. Every individual pointer, and the groups they belong to, would be reported along with the name of the pointer(s) and the pool(s) which would generally take you right to the problem area. Then they are automatically cleaned up. It would also catch the list that wasn't destroyed, by the way, because the list resides inside memory allocations we track as well.
So now the questions arise: Why are there pointers remaining allocated? Why is this list still hanging around? What are the names of the pointers? Are they polygons? Image layers? Blocks for list elements? What pool asked for them? Was it a filter? A plug-in (mind you, the plug-ins have their own subversion of all this, they get their memory and other resources from us, not from the OS, but we could have a fault in the plugin handling, for instance) Is it an object we made for the OS, like an icon bitmap? Whatever it is, between the pool ID(s) and the pointer ID(s) we'll be brought close to the source of the error pretty quickly.
Once you know there was a leak, you think about what you did with the software, combine that with the ID's on the pools and pointers so you're looking in the correct area, and the hunt begins. Usually doesn't last too long, either. If it isn't obvious (and it usually is), you just keep reducing user level cases until the problem begins to appear and disappear, and pretty soon you're looking right at the problem.
There's just no substitute for rigid, detailed memory tracking, fire-walling, and monitoring. As a debugging tool, it is a very, very big hammer.
Have all artists starved to death, production and distribution companies collapsed, and is music no longer being created and played because the economic incentive has disappeared?
No, all the artists have not starved to death. However, that is a very poor metric for the state of the musical community.
The fact is, a lot of artists don't make it because the barriers to financial success — not to making a recording, mind you, but to financial independence so one can actually spend pressure-free creative time making music — are now much higher. That's why the radio is filled with utter pop trash; that's why bands *must* tour instead working in the studio, creating new music, that's why recordings are lowest common denominator compressed to the roof, so that every radio station and every moron DJ can have music that is "just as loud" as the other guy.
Sure, you have "music." But you don't have very many great studio bands (at least, unless they were already great studio bands, like Pink Floyd, Rush, Emerson Lake and Palmer, and so on.)
And what is really sad is the people who were raised on this utter crap... they don't even know any better.
In 1970, if ten thousand people had your recording, it meant that pretty close to ten thousand sales had been made. Today, it means that pretty close to ten thousand people with an Internet connection have copied it with no funds flowing back in your direction. That's not a good change, and that has primarily happened because technology enabled it, and copyright law and enforcement is as toothless as a 2-bit crack whore.
In 1970, you'd have made a few tens of thousands of dollars, you'd be at least encouraged, and you'd probably have a raft of new equipment or at least some studio hours paid for. Today, you'd have nothing. In the case where the music is good, but the audience is small, you're really screwed, because you're never going to make enough to survive. You know who makes enough to survive? Britney Fucking Spears, that's who. And the rest of her ilk. Because she's mainstream, and despite the copying, just as you imply, she does fine.
And by the way, I'm a studio musician and a recording engineer as well as a guy who owns tens of thousands of recordings and eleven different high end audio systems to play them on. I also own a literary agency where our authors totally depend on copyright still working (only what it really is, is book copying is still very annoying to end users) so they can sell books. I've been paying close attention to copyright and anti-copyright viewpoints for decades now. Copyright stops working the day technology enables the end user to walk around it less expensively than obtaining a legitimate copy of a work. As a law, it never meant anything. It just felt like it did, because the technology was a higher barrier to cross (for instance, in 1970, if you were copying high fidelity audio, you owned a reel to reel, because that was the only high fidelity medium available at the time.)
It it were only happening with B-trees. I have seen projects that even ignored libc, and had their on memory management, special logging and tracing routines
We have our own memory management; we do it because it allows us to ensure that there are no memory leaks, anywhere, ever. We have our own linked list management because it is a fraction of the size of the alternatives and does exactly what we need. We have our own file dialogs (and treeview dialog logic) because the OS offerings were buggy for almost a decade. We have our own JPEG routines because we need to load all manner of proprietary and oddball JPEGs. We have our own tree structure code for our ray tracer, particle systems and so on because we can make really big trees and unless we control the memory allocation, the tree becomes too fragmented in memory for it to be handled efficiently. I could go on like this for quite a while. In short, though, there are some very good reasons to skip over the canned solutions. And that's assuming that the canned solutions work perfectly, as described.
When one of your operating platforms is Windows, you either learn to do for yourself or you end up with a buggy application, because Windows itself is prone to long term unfixed (and sometimes unfixable) problems. Write your own code and you can eliminate the problems. That's a pretty strong motivation.
Code in libc may be hard to beat when it comes to doing what that code does; but who is to say you need exactly what libc offers? Memory management is a good example. We require firewalled memory boundaries, cumulative usage tracking by routines and by blocks of routines, named memory groups, live overrun detection, dead pointer detection, real-time and post-run logging. And the code has to be really, really good... if there's a bug, we can't wait for the libc maintainer(s) to fix it. With these kinds of needs, pretty soon you end up writing code. It's pretty straightforward, really.
There's a competitive advantage, too. If a bug is found, your turnaround time can be measured in hours if it is in your own code. For every bug that turns out to be a consequence of an OS or otherwise "not your code" library, bugfixes are much more likely to take longer or simply be impossible. Example? We can process streams of image frames. MS's file dialog let you select many files at once. Seems like a natural fit, right? Click on one file, shift click on another, you've got a block, we should process them. Winner! Well, yeah. But.
If you selected more than about 100 files, MS's file dialog would fail to properly terminate the returned file names, and cut off the last one arbitrarily. Leading to all manner of things, not the least of which was not the behavior that the user was trying to achieve. But wait, there's more! Unless the customer, completely unintuitively, selected the last file first and the first file last, the files would be provided to us by the OS out of order. So? (I hear you thinking.) Just process them in the other order, right? Well, yeah, but the first file in the list we got would be mangled in the natural order. And besides, it wasn't the first one the user selected, just a mangled file name somewhere around number 100 or so. What a mess.
We complained to MS for years about these things without result, until I had simply had enough and wrote our own file dialog. End of problem. Now it just works. Plus, since I was writing it anyway, I did it so the file dialog offers tree views, thumbnails, properties, regular expressions, file management, clipboard tricks, you name it.
No, it wasn't perfect first time out the door, but within a few weeks of release, the customers had ferreted out the weak points and they were all fixed and the working application was back in the customer's hands. I haven't seen a bug report on the file dialog in years now. But if I do... I'll put that bitch down like a KKK'er at an MLK rally.
So are music recordings. And we all know how well that's worked out, right?
As an earlier poster said, with precise insight: "The honor system is short on honor." We know this. There is no possible doubt about it. And with open source, it only takes one person to steal something in literally seconds that took many years to develop and hone. This is the reality that commercial developers have to live with.
Speaking as a closed-source, commercial software vendor, I can say with absolute authority that the cleanliness of our code, the presence or quality of comments in it, unethical use of other people's code - these issues have absolutely no bearing on why we're closed source. We're closed source because we do have algorithms that others do not have, particularly in image morphing and geometrics areas; we do gain a competitive advantage from these.
There is no open-source project that offers capabilities even remotely comparable to those we offer. The gimp takes a vague stab at it, but the present release version offers a fraction of the features while weighing in with a considerably larger executable. That double disparity - larger executable and significantly lower feature count - is one way you can get an immediate feel for the quality of algorithms.
That smaller executable and some of the techniques we use with plug-ins, etc., also helps us load and get initialized faster and that in turn means our customers can get to work faster. This advantage could easily lost if other people gain access to our algorithms. In the case of features no one else even has, letting that source code out would be outright poison to our competitive advantage.
Personally, I think the thesis of the FA is largely bankrupt. And copyright is a joke. As soon as you have to go to court, you've pretty much lost. The only winners there are lawyers and companies so large that legal expenses are lost in their revenue stream, and nothing any court does can stem the tide of underground software (and music) distribution anyway, short of shutting down the entire Internet. I consider the act of giving a lawyer money to be an ethical failure. As the owner of five businesses, I do it more often than I'd like to admit, but I dig my heels in all the way when I can. When it comes to protecting 22 years of carefully tweaked original source code, I'm certainly not going to hand the responsibility over to the copyright and patent clown brigades. Trade secret may have its warts, but Johnny Scriptkiddie running off with your work isn't one of them.
So the fact that you personally might get sticker shock from something (like Photoshop, Cubase or AutoCADD) is not a compelling argument.
First of all, Photoshop is a high level application. That has no bearing on what a *developer* might consider unreasonable as a development cost going into their own application. Secondly, I am a developer, I am responsible for an application of Photoshop's approximate class, we're completely debt-free and cashy, and I still wouldn't consider licensing GUI widgets. As far as I am concerned, the day linux gets GUI widgets that are always there and available on the same terms as those in OS X and Windows is the day I'm willing to release a port to the platform. Other people may have other opinions, and I'm not saying they aren't valid, but that's mine. Either the OS provides the GUI, or as far as I'm concerned, there is no GUI. And incorporating anything using the GPL... not a chance on this earth. But we do have a working linux port ready for the eventuality that the OS changes to provide a standard GUI. There are projects running to get that done, thank goodness. All we'll have to do is move the widgetry over and we should be good to go.
Since MacOS is in the mix there's an obvious potential value to having a cross platform solution. If supporting Linux poses a problem then so does supporting the Macs
Not so. Mac users pay, and pay well, and in large numbers, for good applications. If your app isn't a support problem, every sale is a profitable sale, and the Mac OS, being extremely stable and reliable (just like linux, I might add), is a wonderful platform for selling software into. The linux market isn't even remotely comparable. The GPL is the perfect example of the linux attitude towards commercial software - and it is not commercial friendly. Selling support doesn't work either unless your app is so unfriendly people require help to use it, or else if it is buggy, or has compatibility problems. Applications that "just work", which is our actual goal, have to be sold on initial perceived value, actual value in use, and perceived value of upgrades. Selling someone a "service contract" you know they'll never have to use isn't a very ethical thing to do either.
Even the current Troll prices don't work out to very many billed developer hours.
Oh. I get it. You think the cost of going with a third party widget set is the initial monetary outlay. Well, that's certainly part of it, but what happens when trolltech goes out of business, and linux just keeps evolving? Or the opposite - when Trolltech decides that they're not going to support an older linux, but we want to support our customers? Why should we risk tying our application to a third party? With a better OS design - meaning, one that actually has its own GUI - you can be pretty certain that your stuff is going to continue working. Windows 95 software still works and its been 12 years. Trolltech would never do this, I hear you say? Whoops, wrong. They already have. I can't compile or run the current Gimp on a stock RH9 system, not all that old, frankly. If it isn't complaining about the font libraries or the version of the C compiler, it's having a meltdown over some obscure library I've never even heard of. When I spoke up about this, I was told, "update the linux system"; but that's precisely the wrong answer. A commercial app needs to work on the widest possible number of systems, not only the latest and greatest. At least, as far as I'm concerned. I admit I've run into developers who grab at new OS features like chimps after bright yellow bananas, but we're not one of those. Our objective is to get the app working, and keep the app working. If something shows up we want from a later OS, and we can't special case it in and out based on OS level detection, we just won't use it. Because to lock out our users with old OS's is unaccept
QT is commercial, extra cost. Which case I specifically addressed. So the only "bollocks" in sight are yours. There are days when it seems like the lower the slashdot ID, the more likely the poster will be rude, uninformed, and just plain wrongheaded. Thanks for making this one of those days.
We have too many stupid tort suits. We have nowhere near enough suits against the government for overreaching its authority.
Well said.
People should not be deterred from challenging the law by the threat of jail.
Exactly.
Not to mention that the constant pressure for the addition of new legislation, without a corresponding pressure to eradicate wrongheaded, inappropriate or simply outdated legislation is an imbalance that is slowly poisoning the entire social construct.
Honestly, I'd like to see maximum numbers of local, state and federal laws that could be in force at any one time. Once they hit the limit, to add a new law at any particular level, they'd have to remove an old one at that same level.
Furthermore, such a limit should be WELL under the number of laws we have now.
No, actually it isn't. Most GPS units have considerable software support at the PC level. Mine, for instance (a Garmin), has a complete out-of-unit mapping system (for Windows) with the ability to tag places, make custom icons, route out-of-car and plan, plus optional maps and some other features.
Creating these tools for each OS involves considerable additional investment, and each tool or feature that is a cost+ add-on brings the issue of who will or will not pay more and more to the forefront. As GPS units subsume more and more features - MP3 playing, DVD playing, NWS, XM, traffic, and other radio services, folding your images into the maps and so on, the investment in PC level software can increase dramatically.
Linux simply isn't fertile ground for this for all the reasons I mentioned, plus a few others here and there (such as the royal pain in the neck of trying to pick a widget set with the least annoying license, best feature set, lowest extra cost, and broad distribution - as compared to the standard GUI tools available on OS X and Windows.)
So while I decline to be as rude as you were with your "nonsensical crap" kind of remark, the fact remains, you're simply wrong.
Why don't more Linux-using shops reach out to the Linux-using community?"
Because linux users, as a general rule, have a strong aversion to paying for a commercial product. They're used to free software, and free software, service models excepted, is a very poor model for a company to earn with.
Service models won't do for consumer products, either. They have to work, they have to be intuitive, etc. The optimum consumer product (like the GPS in my car, now that I think about it) has to "just work."
Depending on the product, there may be some issues with licenses as well, if the company wishes to keep the product a closed-source project (quite likely.) The GPL in particular can be a problem in this regard, and even the LGPL can be a problem (see section 4d, which specifies that either source code sufficient to recompile and relink, or a shared library already present on the user's computer must be used.)
It really is too bad that the barrier for entry for commercial entitles is so rough; I got a good look at Ubuntu the other day, and I was downright astonished. That's an OS ready for my grandmother. Finally.
Of course I have, I have also seen people question whether they will hold up. Have you never seen such questions?
No, never, and I've been writing software since the early 1970's. What's to hold up? Take that python database for example: I wrote it, I released it, I gave you the link, I maintain no claim on what you can do with it. I explicitly disclaim all obligations, and there was no exchange of anything from you to me that obligates me to you in any way. I kept the appropriate records when I wrote it, so as to unequivocally establish the release date — there's notarized and sealed source code in multiple bank vaults as per our IP lawyer's recommendation, just as we maintain for our commercial software. So... what's to "hold up"? How can you steal it? How can you take it "away"? How can you break an obligation to me when you don't have any? How can I break an obligation to you when I don't have any? Where's the problem?
Bingo, and so you gave them B without them having the four freedoms. That is my point exactly.
With a PD release mechanism, AB is mine to give; so that's not a valid issue unless I choose to continue AB in the same vein of release as A; that's a freedom of mine. The only difference between AB and A are the differences (B) I put in it; as you are perfectly free to have A without the B differences, you have no legitimate claim on AB (or B, which is really what you get when you get AB, as you already had A) unless I choose to offer that option.
Can you think of a cleaner wording for a license that will do what the GPL does / tries to do?
Easily. A better wording for the GPL would drop the nonsensical smoke and mirrors about "protecting freedoms" and simply say:
This license formalizes an exchange. If you use this code and distribute it in any manner, you agree to exchange the right to distribute what is provided here for (1) a commitment to distribute any new and/or derived and/or duplicated version in the same manner and (2) extend this commitment in such a way as it remains in force for each successive generation.
In the legalese equivalent, of course. Have to give the lawyers their ragged, bleeding, abused pound of flesh.
That's the entire point of it, after all. The "four freedoms" are actually diminished by this type of license. It is disingenuous to claim they are looked after as if there weren't far better ways to do so, such as PD's easily demonstrated superior abilities. The GPL should just say what it is actually doing — passing along a restriction — and leave it at that.
OK, I release program A as PD (if that is indeed possible)...
Of course it is... what an... unexpected remark. Huh. Have you truly never run into a PD release? Here's one for you, a multiple read-client / single write-client flat file database written in python that implements a very useful subset of SQL and comes in at under 20k. In fact, zipped, the database engine, two database examples, a test / example program, and the docs come in at about 13k bytes and don't use any library that isn't part of python itself (re and os are used.) There it is, you can do anything you like with it. And I hope you do.:-) At least download it and read the docs, so you can see the terms (none) and see what it can do. So there's some actual PD software; mystery solved.
You make a new program B based laregly on A and release it (C) all rights reserved.
A still exists, unmolested, as PD at this point. So no harm or change of status has come to A at all. B is a new work, so it could have any type of release. Copyrighted, GPL'd, PD, BSD, etc. There is no harm to A in the fact that B contains A to any proportion. To the extent that B is new work (let's say it is mostly A, as in your example), that new work should be controlled by the author. A, which is not new work, is still out there and still controlled by the fact that it is PD and available to anyone.
For a very specific example, my database engine, above, is "A". You take it and incorporate it in something you write, unspecified, we'll just call it B and stipulate that B contains A, or perhaps it is more enlightening to call your aggregate production "AB", indicating some of my stuff, A, is in there. Now, my database engine, A, is still available. You wrote new stuff - I have no claim on what you wrote. That's the PD outlook. You wrote your stuff, it is yours. I chose to release A as PD, but that was my choice. Why should you be obligated to do the same? It isn't as if your incorporation of A into AB devalued A somehow. Quite the opposite. You added value and your own personal twist, now you are, and should be, responsible for the disposition of AB.
Third person gets B from you and now does not have the four freedoms with respect to B.
No, no, just wait a minute! They never had the four freedoms with respect to B; they had the four freedoms with respect to A, and they still do. I didn't give them A, I gave them B. They can still get A, presumably from the same place I got it. Or perhaps even from me. A != B, after all; doesn't hurt me a bit to hand out copies of A, no matter what my plans and intent are for B, or how much, or how little, I've changed it. So nothing has been lost, and of course, the community has gained B in whatever form the author, me, has chosen to bring it to them based on the new work. Also - in your scenario, B is "based largely on A" and so your access to A gives you - largely - what is in B. Presumably, this would allow you to create your own B without any particular trouble. So there is very little sense in the idea that A should control B in this case, even if you're just trying to take the work that B represents. But there's another side of this coin - when B is by far the larger part of the code. Then where does the justification for A controlling B come from?
It seems to me that what you are arguing for is that by writing A and releasing it as GPL, A gets to control all software that incorporates it downstream, regardless of the magnitude of additional effort or anything else for that matter.
It appears I've established that your outlook, that A should control B, is without merit other than it gets you additional free stuff you didn't have to write yourself. Which certainly has value, but as it is coercive — A controls B by force o
PD allows someone in the chain to take away freedoms for derivative works should anyone in the chain desire.
I ask you again, exactly how does PD allow freedoms to be taken away? Please take a little time and explain. I really don't see how this could possibly be the case. So I'm asking you to educate me. If I disagree, I'll tell you. If I am enlightened, I'll thank you.
the GPL was never about the developer/user getting freedom; it is about the software getting freedom.
Well, that's an interesting idea, applying "freedom" to an inanimate object with no emotions or feelings to hurt or resources to damage that can be a building block in all manner of structures.
Funny thing, though, the GPL restricts which structures the software may participate in, or be a building block in, based on classing the behavior of those who utilize the software. So if the GPL is about giving the software freedom, I'd say it was a complete and utter failure. What it does is provides restrictions on how the software may be used. This isn't freedom for said inanimate object. This is limitation.
On the other hand, If I release software object X as PD, it can be incorporated in any structure, in any manner. If it is incorporated one way here, it may be incorporated another elsewhere. And so on, ad infinitum. If it is subsumed inside a closed source project, it still exists in unmodified form (the original creation) and can still be incorporated endlessly as released.
Nowhere in a PD release stream does the developer earlier in line get to restrict the freedoms of a developer later in line. This (if you're concerned about freedom) is a good thing. Also, nowhere does a developer later in line get to restrict the freedoms of a developer earlier in line. Again, a good thing. X is still 100% available to everyone.
Now, a closed source fellow may have produced XY, and he's not sharing. But so what? You still have X. You didn't write Y, so in what way can it be construed that you (or I) should have control over it if freedom is the issue? You might produce XZ and share it; no problem there, either. Now we have X and XZ in PD, or X in PD and XZ in GPL or BSD, and XY closed (but benefiting those users who end up with it anyway.) The guy who did X did what he wanted; the guy who did Y did what he wanted; the guy who did Z (you) did what he wanted. The world ends up with X, XY, and XZ. X is in no way compromised. Freedom all around. No one telling anyone else what to do with what they write. We simply see people specifying what to do with what they write. And no lawyers. How nice and fuzzy.:-)
Did you misunderstand the context or my question that badly?
I don't think so. You asked for better wording for a license to protect the four freedoms. I responded that PD protects the four freedoms better (which is really a very direct answer to your question), and then I outlined in precisely what ways that was so. PD is very much "a license" in this context because it describes, precisely as a license does, how one may proceed with regard to distribution and use of code.
Then I pointed out that protecting the four freedoms best wasn't really what the GPL did; what it does is restrict freedom, specifically the freedom to subsume a GPL'd work inside another work without having to give up your new work, or the manner of integration. I noted that PD does not do this; so PD stands as better protecting the four freedoms, plus adding others. What PD does not do is restrict the freedom to subsume a work inside another work in any way, shape or form.
The question isn't limited to copyleft, though you might prefer it to be. Not if freedoms, even just those four, can be addressed better by other methods. And in fact, they can be. The best move to protect them is to go from the GPL to PD. If the intent, as you posed it, is to protect those four freedoms. Not to mention some other useful freedoms.
PD may indeed give the four freedoms to the first generation as does the BSD. But neither protect those freedoms for subsequent generations.
Ok, two things. First, PD protects the freedoms applied to the "first generation" (the work the original coder did) *better* than the GPL does, as I outlined. It protects them in every way just as the GPL does, then protects additional freedoms.
Second, PD does not allow the first generation coder to apply conditions to the second (and later) generation coders, protecting MORE freedoms. The GPL, at this juncture, applies restrictions, not freedoms. The original work (first generation) was a product of, let's say my work. Now I put it out there for the public to benefit. If I put it out there PD, you can add to it if you like, and release 2nd gen mods for everyone's benefit. Or not. This is a freedom; a choice. Your choice, and, I might add, your choice applied to your work. This freedom continues forward for every path that continues in PD. However, in the same situation, if I GPL it, you must give out your work if you redistribute. This is not a freedom; it is not a choice. It is a restriction. This restriction propagates endlessly with the code, like a poison pill, holding back freedom at every generation, restricting every generation. At no point, even in the first generation, can this GPL'd code be subsumed in any form into another project and then distributed in closed form. The PD version, however, can — even if you decide to keep yours closed, the first gen can still be used and forked into all manner of uses and modes and distribution, as can subsequent, more advanced generations that continue in PD through other people's hands.
Here's the core of the matter. PD says "I hand this code over, have at it, this is what I did, you can use it, improve it, even screw it up. It's a gift. A free one. No strings." GPL says "I provide this code, and you can use it. But if you distribute it, then any changes you make must also be handed out under the same terms as the ones I used. In other words, not a gift, but an exchange; I give you code; you give me compliance with my idea of how you should license your code." This is copyleft.
Now, I do not have a problem with copyleft, as you keep coming back to. None at all. I wouldn't use it, but that isn't because I have a problem with it, it is because it doesn't solve any problem that I have nearly as well as other available choices. PD completely and cleanly solves the problem when I want people to benefit the maximum amount without prejudice or c
None of the freedoms are in the least compromised by that as far as I can tell. In no way is the code prevented from being distributed in any of the original ways from the state it was in at the time. If you think so, specify exactly how you see that happening. Claiming it does without specifying how is specious.
If you want to honestly try to answer the question, fine. If you just want to have the freedom to restrict the freedom of others, let's not argue, we just disagree.
I *did* honestly answer the question. Don't be rude.
The government takes the freedoms of killing, torturing and in general harming people away...
few could argue that we are less free because of that.
We are less free because of that. My ability to defend my family, my property and my home is compromised by the government's monopoly on killing. This is a very bad thing. Worse, it is done to protect people who have no business in my home or on my property, at my family's expense. You can certainly argue that by placing such a restriction on people, accidents can be prevented, but the fact is, considerable freedom and safety are lost — as well as innocent lives.
Torture for information retrieval is stupid (including waterboarding and all the other borderline techniques the morons are using today) because a tortured individual will tell you anything in order to stop the behavior. However, torture as punishment for a crime (for instance, placing someone in a pound-you-in-the-ass-federal-pen) can serve as both deterrent and retribution. Retribution is not a zero-value experience for those who have been wronged. The government reserves this right as well. That - IMHO - is probably for the best. Though I think they use it inappropriately, for example on adult citizens who are simply exercising a choice as what to do with or to their own bodies and/or the bodies of other consenting, informed adults.
Can you think of a better wording for a license that will protect the four freedoms in all situations?
The better choice is PD, as in, I release this source code as PD - you can do anything you like with it. The FSF's four freedoms are:
Run the program, for any purpose
Study how the program works, and adapt it to your needs
Redistribute copies so you can help your neighbor
Improve the program, and release your improvements to the public, so that the whole community benefits
For #1, PD allows you to do this, and it also allows an end user to run it as a client of a closed source, commercial project, which the GPL disallows.
For #2, PD allows you to do this as well, only the "your needs" that you can adapt it to are broader; you can do anything that you could do under the GPL, but you can also implement a fully commercial, closed source modification (or use) of the PD code in distribution.
For #3, you can redistribute or not, just as under the GPL. But you can also redistribute as closed source, modified or not, which you cannot do under the GPL.
For #4, you can do anything the GPL allows here, and you can also improve it (or just use it) and release it in proprietary executable form so you can benefit people in a way that the GPL does not allow.
Clearly, if the four freedoms are the critical issue, then PD is a far superior mechanism for implementing them. You said you were looking for a mechanism to protect the four freedoms in "any" situation; it is obvious that the GPL protects them in considerably fewer situations than does PD. As near as I can figure out, nothing protects them in "all" situations, not even PD.
What the GPL actually accomplishes is the erection of a legal structure that must be navigated or avoided by those people who choose to be downstream clients of GPL'd source. This means that lawyers have an opportunity to earn money, people are restricted in how they can use such projects in ways they would not have been if the project had been PD, and (here we get into the actual reason for the GPL, or so my instincts tell me) any changes or improvements to the code must be made available to everyone if the code is redistributed in any form.
So a value exchange — new changes going to the community in exchange for the use of the unmodified project — is a behavior forced upon the users of GPL'd code. The freedom to do this of course exists with PD, but it isn't freedom to do this that the GPL is actually working to implement; it is the requirement to do it.
As other posters have said before me, by all means, if the GPL is what you want to use, then use it.
Just don't think it is freedom that you're getting. What you're getting is restriction at the expense of freedom. Which may be precisely what you want. Just be sure it is. If the four freedoms are what you want to protect and foster, then PD is a much better choice.
Me, I'll either go commercial, or I'll go PD. The former is a means to earn a living with what I consider to be the strongest potential to earn; the latter is a means to benefit the developer community in the broadest possible sense, which in turn can benefit others downstream from the developers. The GPL, as far as I am concerned, isn't even in the running.
The OS has "first rights" to all the resources that make things fast. It has the CPU before any app does; so the more time it spends using said CPU (or CPUs), the less cycles available to a user app, and therefore, the user app slows down. It has RAM before any app does; so if it eats up RAM that a user app could use, the user app is forced into conservative strategies (swapping, block processing, etc.) that it otherwise could have avoided. This can result in a huge difference in application speed. Both linux and OS X are quite likely to page something out of RAM and onto the hard drive even if you're using it when RAM gets tight. Or the OS might flat out fail to run your app if there isn't enough RAM. So if the OS is careful, even penurious, about its use of RAM, this benefits user apps, especially large ones. And speed will be the first thing you notice.
That's why the optimum strategy is to (a) buy the fastest CPU you can afford, and (b) the most RAM you can afford. Doesn't hurt to hunt down apps that are known to be conservative in RAM use and built with less inherently clunky/hoggish technologies (often that means c instead of c++, for instance.) Look for the application that does what you want that has the smallest executable. Then look to see how much RAM is taken when it is running as compared to the others. It's a fun exercise
and can provide you with many surprises, not to mention useful results.
Both multiple workspaces and backup software have been available for quite some time. I have both on all my machines. Aside from the damage done to the Apple developers who used to fill those niches (not quite as blatant as the hit to the Konfabulator people, but still), there's not a lot there to take notice of.
I'm just hoping I'll be able to refresh a network share; right now, if something changes, disconnect and reconnect. Fairly annoying.
Slashdot Mirror
No, not impossible.
Our manager would catch this, or any variation of this, first time it happened. This is because on exit, after legitimate cleanup is done (meaning, we deallocate the things we have been keeping proper track of... memory for windows, palettes, layer lists, that sort of thing), the internal memory pools are all tested for pointers that have not yet been deallocated. Every individual pointer, and the groups they belong to, would be reported along with the name of the pointer(s) and the pool(s) which would generally take you right to the problem area. Then they are automatically cleaned up. It would also catch the list that wasn't destroyed, by the way, because the list resides inside memory allocations we track as well.
So now the questions arise: Why are there pointers remaining allocated? Why is this list still hanging around? What are the names of the pointers? Are they polygons? Image layers? Blocks for list elements? What pool asked for them? Was it a filter? A plug-in (mind you, the plug-ins have their own subversion of all this, they get their memory and other resources from us, not from the OS, but we could have a fault in the plugin handling, for instance) Is it an object we made for the OS, like an icon bitmap? Whatever it is, between the pool ID(s) and the pointer ID(s) we'll be brought close to the source of the error pretty quickly.
Once you know there was a leak, you think about what you did with the software, combine that with the ID's on the pools and pointers so you're looking in the correct area, and the hunt begins. Usually doesn't last too long, either. If it isn't obvious (and it usually is), you just keep reducing user level cases until the problem begins to appear and disappear, and pretty soon you're looking right at the problem.
There's just no substitute for rigid, detailed memory tracking, fire-walling, and monitoring. As a debugging tool, it is a very, very big hammer.
No, all the artists have not starved to death. However, that is a very poor metric for the state of the musical community.
The fact is, a lot of artists don't make it because the barriers to financial success — not to making a recording, mind you, but to financial independence so one can actually spend pressure-free creative time making music — are now much higher. That's why the radio is filled with utter pop trash; that's why bands *must* tour instead working in the studio, creating new music, that's why recordings are lowest common denominator compressed to the roof, so that every radio station and every moron DJ can have music that is "just as loud" as the other guy.
Sure, you have "music." But you don't have very many great studio bands (at least, unless they were already great studio bands, like Pink Floyd, Rush, Emerson Lake and Palmer, and so on.)
And what is really sad is the people who were raised on this utter crap... they don't even know any better.
In 1970, if ten thousand people had your recording, it meant that pretty close to ten thousand sales had been made. Today, it means that pretty close to ten thousand people with an Internet connection have copied it with no funds flowing back in your direction. That's not a good change, and that has primarily happened because technology enabled it, and copyright law and enforcement is as toothless as a 2-bit crack whore.
In 1970, you'd have made a few tens of thousands of dollars, you'd be at least encouraged, and you'd probably have a raft of new equipment or at least some studio hours paid for. Today, you'd have nothing. In the case where the music is good, but the audience is small, you're really screwed, because you're never going to make enough to survive. You know who makes enough to survive? Britney Fucking Spears, that's who. And the rest of her ilk. Because she's mainstream, and despite the copying, just as you imply, she does fine.
And by the way, I'm a studio musician and a recording engineer as well as a guy who owns tens of thousands of recordings and eleven different high end audio systems to play them on. I also own a literary agency where our authors totally depend on copyright still working (only what it really is, is book copying is still very annoying to end users) so they can sell books. I've been paying close attention to copyright and anti-copyright viewpoints for decades now. Copyright stops working the day technology enables the end user to walk around it less expensively than obtaining a legitimate copy of a work. As a law, it never meant anything. It just felt like it did, because the technology was a higher barrier to cross (for instance, in 1970, if you were copying high fidelity audio, you owned a reel to reel, because that was the only high fidelity medium available at the time.)
We have our own memory management; we do it because it allows us to ensure that there are no memory leaks, anywhere, ever. We have our own linked list management because it is a fraction of the size of the alternatives and does exactly what we need. We have our own file dialogs (and treeview dialog logic) because the OS offerings were buggy for almost a decade. We have our own JPEG routines because we need to load all manner of proprietary and oddball JPEGs. We have our own tree structure code for our ray tracer, particle systems and so on because we can make really big trees and unless we control the memory allocation, the tree becomes too fragmented in memory for it to be handled efficiently. I could go on like this for quite a while. In short, though, there are some very good reasons to skip over the canned solutions. And that's assuming that the canned solutions work perfectly, as described.
When one of your operating platforms is Windows, you either learn to do for yourself or you end up with a buggy application, because Windows itself is prone to long term unfixed (and sometimes unfixable) problems. Write your own code and you can eliminate the problems. That's a pretty strong motivation.
Code in libc may be hard to beat when it comes to doing what that code does; but who is to say you need exactly what libc offers? Memory management is a good example. We require firewalled memory boundaries, cumulative usage tracking by routines and by blocks of routines, named memory groups, live overrun detection, dead pointer detection, real-time and post-run logging. And the code has to be really, really good... if there's a bug, we can't wait for the libc maintainer(s) to fix it. With these kinds of needs, pretty soon you end up writing code. It's pretty straightforward, really.
There's a competitive advantage, too. If a bug is found, your turnaround time can be measured in hours if it is in your own code. For every bug that turns out to be a consequence of an OS or otherwise "not your code" library, bugfixes are much more likely to take longer or simply be impossible. Example? We can process streams of image frames. MS's file dialog let you select many files at once. Seems like a natural fit, right? Click on one file, shift click on another, you've got a block, we should process them. Winner! Well, yeah. But.
If you selected more than about 100 files, MS's file dialog would fail to properly terminate the returned file names, and cut off the last one arbitrarily. Leading to all manner of things, not the least of which was not the behavior that the user was trying to achieve. But wait, there's more! Unless the customer, completely unintuitively, selected the last file first and the first file last, the files would be provided to us by the OS out of order. So? (I hear you thinking.) Just process them in the other order, right? Well, yeah, but the first file in the list we got would be mangled in the natural order. And besides, it wasn't the first one the user selected, just a mangled file name somewhere around number 100 or so. What a mess.
We complained to MS for years about these things without result, until I had simply had enough and wrote our own file dialog. End of problem. Now it just works. Plus, since I was writing it anyway, I did it so the file dialog offers tree views, thumbnails, properties, regular expressions, file management, clipboard tricks, you name it.
No, it wasn't perfect first time out the door, but within a few weeks of release, the customers had ferreted out the weak points and they were all fixed and the working application was back in the customer's hands. I haven't seen a bug report on the file dialog in years now. But if I do... I'll put that bitch down like a KKK'er at an MLK rally.
It isn't wasn
So are music recordings. And we all know how well that's worked out, right?
As an earlier poster said, with precise insight: "The honor system is short on honor." We know this. There is no possible doubt about it. And with open source, it only takes one person to steal something in literally seconds that took many years to develop and hone. This is the reality that commercial developers have to live with.
Speaking as a closed-source, commercial software vendor, I can say with absolute authority that the cleanliness of our code, the presence or quality of comments in it, unethical use of other people's code - these issues have absolutely no bearing on why we're closed source. We're closed source because we do have algorithms that others do not have, particularly in image morphing and geometrics areas; we do gain a competitive advantage from these.
There is no open-source project that offers capabilities even remotely comparable to those we offer. The gimp takes a vague stab at it, but the present release version offers a fraction of the features while weighing in with a considerably larger executable. That double disparity - larger executable and significantly lower feature count - is one way you can get an immediate feel for the quality of algorithms.
That smaller executable and some of the techniques we use with plug-ins, etc., also helps us load and get initialized faster and that in turn means our customers can get to work faster. This advantage could easily lost if other people gain access to our algorithms. In the case of features no one else even has, letting that source code out would be outright poison to our competitive advantage.
Personally, I think the thesis of the FA is largely bankrupt. And copyright is a joke. As soon as you have to go to court, you've pretty much lost. The only winners there are lawyers and companies so large that legal expenses are lost in their revenue stream, and nothing any court does can stem the tide of underground software (and music) distribution anyway, short of shutting down the entire Internet. I consider the act of giving a lawyer money to be an ethical failure. As the owner of five businesses, I do it more often than I'd like to admit, but I dig my heels in all the way when I can. When it comes to protecting 22 years of carefully tweaked original source code, I'm certainly not going to hand the responsibility over to the copyright and patent clown brigades. Trade secret may have its warts, but Johnny Scriptkiddie running off with your work isn't one of them.
First of all, Photoshop is a high level application. That has no bearing on what a *developer* might consider unreasonable as a development cost going into their own application. Secondly, I am a developer, I am responsible for an application of Photoshop's approximate class, we're completely debt-free and cashy, and I still wouldn't consider licensing GUI widgets. As far as I am concerned, the day linux gets GUI widgets that are always there and available on the same terms as those in OS X and Windows is the day I'm willing to release a port to the platform. Other people may have other opinions, and I'm not saying they aren't valid, but that's mine. Either the OS provides the GUI, or as far as I'm concerned, there is no GUI. And incorporating anything using the GPL... not a chance on this earth. But we do have a working linux port ready for the eventuality that the OS changes to provide a standard GUI. There are projects running to get that done, thank goodness. All we'll have to do is move the widgetry over and we should be good to go.
Not so. Mac users pay, and pay well, and in large numbers, for good applications. If your app isn't a support problem, every sale is a profitable sale, and the Mac OS, being extremely stable and reliable (just like linux, I might add), is a wonderful platform for selling software into. The linux market isn't even remotely comparable. The GPL is the perfect example of the linux attitude towards commercial software - and it is not commercial friendly. Selling support doesn't work either unless your app is so unfriendly people require help to use it, or else if it is buggy, or has compatibility problems. Applications that "just work", which is our actual goal, have to be sold on initial perceived value, actual value in use, and perceived value of upgrades. Selling someone a "service contract" you know they'll never have to use isn't a very ethical thing to do either.
Oh. I get it. You think the cost of going with a third party widget set is the initial monetary outlay. Well, that's certainly part of it, but what happens when trolltech goes out of business, and linux just keeps evolving? Or the opposite - when Trolltech decides that they're not going to support an older linux, but we want to support our customers? Why should we risk tying our application to a third party? With a better OS design - meaning, one that actually has its own GUI - you can be pretty certain that your stuff is going to continue working. Windows 95 software still works and its been 12 years. Trolltech would never do this, I hear you say? Whoops, wrong. They already have. I can't compile or run the current Gimp on a stock RH9 system, not all that old, frankly. If it isn't complaining about the font libraries or the version of the C compiler, it's having a meltdown over some obscure library I've never even heard of. When I spoke up about this, I was told, "update the linux system"; but that's precisely the wrong answer. A commercial app needs to work on the widest possible number of systems, not only the latest and greatest. At least, as far as I'm concerned. I admit I've run into developers who grab at new OS features like chimps after bright yellow bananas, but we're not one of those. Our objective is to get the app working, and keep the app working. If something shows up we want from a later OS, and we can't special case it in and out based on OS level detection, we just won't use it. Because to lock out our users with old OS's is unaccept
QT is commercial, extra cost. Which case I specifically addressed. So the only "bollocks" in sight are yours. There are days when it seems like the lower the slashdot ID, the more likely the poster will be rude, uninformed, and just plain wrongheaded. Thanks for making this one of those days.
Well said.
Exactly.
Not to mention that the constant pressure for the addition of new legislation, without a corresponding pressure to eradicate wrongheaded, inappropriate or simply outdated legislation is an imbalance that is slowly poisoning the entire social construct.
Honestly, I'd like to see maximum numbers of local, state and federal laws that could be in force at any one time. Once they hit the limit, to add a new law at any particular level, they'd have to remove an old one at that same level.
Furthermore, such a limit should be WELL under the number of laws we have now.
No, actually it isn't. Most GPS units have considerable software support at the PC level. Mine, for instance (a Garmin), has a complete out-of-unit mapping system (for Windows) with the ability to tag places, make custom icons, route out-of-car and plan, plus optional maps and some other features.
Creating these tools for each OS involves considerable additional investment, and each tool or feature that is a cost+ add-on brings the issue of who will or will not pay more and more to the forefront. As GPS units subsume more and more features - MP3 playing, DVD playing, NWS, XM, traffic, and other radio services, folding your images into the maps and so on, the investment in PC level software can increase dramatically.
Linux simply isn't fertile ground for this for all the reasons I mentioned, plus a few others here and there (such as the royal pain in the neck of trying to pick a widget set with the least annoying license, best feature set, lowest extra cost, and broad distribution - as compared to the standard GUI tools available on OS X and Windows.)
So while I decline to be as rude as you were with your "nonsensical crap" kind of remark, the fact remains, you're simply wrong.
That's not how our IP lawyers see it; may I ask who did the analysis of the LGPL for you?
Because linux users, as a general rule, have a strong aversion to paying for a commercial product. They're used to free software, and free software, service models excepted, is a very poor model for a company to earn with.
Service models won't do for consumer products, either. They have to work, they have to be intuitive, etc. The optimum consumer product (like the GPS in my car, now that I think about it) has to "just work."
Depending on the product, there may be some issues with licenses as well, if the company wishes to keep the product a closed-source project (quite likely.) The GPL in particular can be a problem in this regard, and even the LGPL can be a problem (see section 4d, which specifies that either source code sufficient to recompile and relink, or a shared library already present on the user's computer must be used.)
It really is too bad that the barrier for entry for commercial entitles is so rough; I got a good look at Ubuntu the other day, and I was downright astonished. That's an OS ready for my grandmother. Finally.
No, never, and I've been writing software since the early 1970's. What's to hold up? Take that python database for example: I wrote it, I released it, I gave you the link, I maintain no claim on what you can do with it. I explicitly disclaim all obligations, and there was no exchange of anything from you to me that obligates me to you in any way. I kept the appropriate records when I wrote it, so as to unequivocally establish the release date — there's notarized and sealed source code in multiple bank vaults as per our IP lawyer's recommendation, just as we maintain for our commercial software. So... what's to "hold up"? How can you steal it? How can you take it "away"? How can you break an obligation to me when you don't have any? How can I break an obligation to you when I don't have any? Where's the problem?
With a PD release mechanism, AB is mine to give; so that's not a valid issue unless I choose to continue AB in the same vein of release as A; that's a freedom of mine. The only difference between AB and A are the differences (B) I put in it; as you are perfectly free to have A without the B differences, you have no legitimate claim on AB (or B, which is really what you get when you get AB, as you already had A) unless I choose to offer that option.
Easily. A better wording for the GPL would drop the nonsensical smoke and mirrors about "protecting freedoms" and simply say:
This license formalizes an exchange. If you use this code and distribute it in any manner, you agree to exchange the right to distribute what is provided here for (1) a commitment to distribute any new and/or derived and/or duplicated version in the same manner and (2) extend this commitment in such a way as it remains in force for each successive generation.
In the legalese equivalent, of course. Have to give the lawyers their ragged, bleeding, abused pound of flesh.
That's the entire point of it, after all. The "four freedoms" are actually diminished by this type of license. It is disingenuous to claim they are looked after as if there weren't far better ways to do so, such as PD's easily demonstrated superior abilities. The GPL should just say what it is actually doing — passing along a restriction — and leave it at that.
Of course it is... what an... unexpected remark. Huh. Have you truly never run into a PD release? Here's one for you, a multiple read-client / single write-client flat file database written in python that implements a very useful subset of SQL and comes in at under 20k. In fact, zipped, the database engine, two database examples, a test / example program, and the docs come in at about 13k bytes and don't use any library that isn't part of python itself (re and os are used.) There it is, you can do anything you like with it. And I hope you do. :-) At least download it and read the docs, so you can see the terms (none) and see what it can do. So there's some actual PD software; mystery solved.
A still exists, unmolested, as PD at this point. So no harm or change of status has come to A at all. B is a new work, so it could have any type of release. Copyrighted, GPL'd, PD, BSD, etc. There is no harm to A in the fact that B contains A to any proportion. To the extent that B is new work (let's say it is mostly A, as in your example), that new work should be controlled by the author. A, which is not new work, is still out there and still controlled by the fact that it is PD and available to anyone.
For a very specific example, my database engine, above, is "A". You take it and incorporate it in something you write, unspecified, we'll just call it B and stipulate that B contains A, or perhaps it is more enlightening to call your aggregate production "AB", indicating some of my stuff, A, is in there. Now, my database engine, A, is still available. You wrote new stuff - I have no claim on what you wrote. That's the PD outlook. You wrote your stuff, it is yours. I chose to release A as PD, but that was my choice. Why should you be obligated to do the same? It isn't as if your incorporation of A into AB devalued A somehow. Quite the opposite. You added value and your own personal twist, now you are, and should be, responsible for the disposition of AB.
No, no, just wait a minute! They never had the four freedoms with respect to B; they had the four freedoms with respect to A, and they still do. I didn't give them A, I gave them B. They can still get A, presumably from the same place I got it. Or perhaps even from me. A != B, after all; doesn't hurt me a bit to hand out copies of A, no matter what my plans and intent are for B, or how much, or how little, I've changed it. So nothing has been lost, and of course, the community has gained B in whatever form the author, me, has chosen to bring it to them based on the new work. Also - in your scenario, B is "based largely on A" and so your access to A gives you - largely - what is in B. Presumably, this would allow you to create your own B without any particular trouble. So there is very little sense in the idea that A should control B in this case, even if you're just trying to take the work that B represents. But there's another side of this coin - when B is by far the larger part of the code. Then where does the justification for A controlling B come from?
It seems to me that what you are arguing for is that by writing A and releasing it as GPL, A gets to control all software that incorporates it downstream, regardless of the magnitude of additional effort or anything else for that matter.
It appears I've established that your outlook, that A should control B, is without merit other than it gets you additional free stuff you didn't have to write yourself. Which certainly has value, but as it is coercive — A controls B by force o
I ask you again, exactly how does PD allow freedoms to be taken away? Please take a little time and explain. I really don't see how this could possibly be the case. So I'm asking you to educate me. If I disagree, I'll tell you. If I am enlightened, I'll thank you.
Well, that's an interesting idea, applying "freedom" to an inanimate object with no emotions or feelings to hurt or resources to damage that can be a building block in all manner of structures.
Funny thing, though, the GPL restricts which structures the software may participate in, or be a building block in, based on classing the behavior of those who utilize the software. So if the GPL is about giving the software freedom, I'd say it was a complete and utter failure. What it does is provides restrictions on how the software may be used. This isn't freedom for said inanimate object. This is limitation.
On the other hand, If I release software object X as PD, it can be incorporated in any structure, in any manner. If it is incorporated one way here, it may be incorporated another elsewhere. And so on, ad infinitum. If it is subsumed inside a closed source project, it still exists in unmodified form (the original creation) and can still be incorporated endlessly as released.
Nowhere in a PD release stream does the developer earlier in line get to restrict the freedoms of a developer later in line. This (if you're concerned about freedom) is a good thing. Also, nowhere does a developer later in line get to restrict the freedoms of a developer earlier in line. Again, a good thing. X is still 100% available to everyone.
Now, a closed source fellow may have produced XY, and he's not sharing. But so what? You still have X. You didn't write Y, so in what way can it be construed that you (or I) should have control over it if freedom is the issue? You might produce XZ and share it; no problem there, either. Now we have X and XZ in PD, or X in PD and XZ in GPL or BSD, and XY closed (but benefiting those users who end up with it anyway.) The guy who did X did what he wanted; the guy who did Y did what he wanted; the guy who did Z (you) did what he wanted. The world ends up with X, XY, and XZ. X is in no way compromised. Freedom all around. No one telling anyone else what to do with what they write. We simply see people specifying what to do with what they write. And no lawyers. How nice and fuzzy. :-)
I don't think so. You asked for better wording for a license to protect the four freedoms. I responded that PD protects the four freedoms better (which is really a very direct answer to your question), and then I outlined in precisely what ways that was so. PD is very much "a license" in this context because it describes, precisely as a license does, how one may proceed with regard to distribution and use of code.
Then I pointed out that protecting the four freedoms best wasn't really what the GPL did; what it does is restrict freedom, specifically the freedom to subsume a GPL'd work inside another work without having to give up your new work, or the manner of integration. I noted that PD does not do this; so PD stands as better protecting the four freedoms, plus adding others. What PD does not do is restrict the freedom to subsume a work inside another work in any way, shape or form.
The question isn't limited to copyleft, though you might prefer it to be. Not if freedoms, even just those four, can be addressed better by other methods. And in fact, they can be. The best move to protect them is to go from the GPL to PD. If the intent, as you posed it, is to protect those four freedoms. Not to mention some other useful freedoms.
Ok, two things. First, PD protects the freedoms applied to the "first generation" (the work the original coder did) *better* than the GPL does, as I outlined. It protects them in every way just as the GPL does, then protects additional freedoms.
Second, PD does not allow the first generation coder to apply conditions to the second (and later) generation coders, protecting MORE freedoms. The GPL, at this juncture, applies restrictions, not freedoms. The original work (first generation) was a product of, let's say my work. Now I put it out there for the public to benefit. If I put it out there PD, you can add to it if you like, and release 2nd gen mods for everyone's benefit. Or not. This is a freedom; a choice. Your choice, and, I might add, your choice applied to your work. This freedom continues forward for every path that continues in PD. However, in the same situation, if I GPL it, you must give out your work if you redistribute. This is not a freedom; it is not a choice. It is a restriction. This restriction propagates endlessly with the code, like a poison pill, holding back freedom at every generation, restricting every generation. At no point, even in the first generation, can this GPL'd code be subsumed in any form into another project and then distributed in closed form. The PD version, however, can — even if you decide to keep yours closed, the first gen can still be used and forked into all manner of uses and modes and distribution, as can subsequent, more advanced generations that continue in PD through other people's hands.
Here's the core of the matter. PD says "I hand this code over, have at it, this is what I did, you can use it, improve it, even screw it up. It's a gift. A free one. No strings." GPL says "I provide this code, and you can use it. But if you distribute it, then any changes you make must also be handed out under the same terms as the ones I used. In other words, not a gift, but an exchange; I give you code; you give me compliance with my idea of how you should license your code." This is copyleft.
Now, I do not have a problem with copyleft, as you keep coming back to. None at all. I wouldn't use it, but that isn't because I have a problem with it, it is because it doesn't solve any problem that I have nearly as well as other available choices. PD completely and cleanly solves the problem when I want people to benefit the maximum amount without prejudice or c
None of the freedoms are in the least compromised by that as far as I can tell. In no way is the code prevented from being distributed in any of the original ways from the state it was in at the time. If you think so, specify exactly how you see that happening. Claiming it does without specifying how is specious.
I *did* honestly answer the question. Don't be rude.
We are less free because of that. My ability to defend my family, my property and my home is compromised by the government's monopoly on killing. This is a very bad thing. Worse, it is done to protect people who have no business in my home or on my property, at my family's expense. You can certainly argue that by placing such a restriction on people, accidents can be prevented, but the fact is, considerable freedom and safety are lost — as well as innocent lives.
Torture for information retrieval is stupid (including waterboarding and all the other borderline techniques the morons are using today) because a tortured individual will tell you anything in order to stop the behavior. However, torture as punishment for a crime (for instance, placing someone in a pound-you-in-the-ass-federal-pen) can serve as both deterrent and retribution. Retribution is not a zero-value experience for those who have been wronged. The government reserves this right as well. That - IMHO - is probably for the best. Though I think they use it inappropriately, for example on adult citizens who are simply exercising a choice as what to do with or to their own bodies and/or the bodies of other consenting, informed adults.
The better choice is PD, as in, I release this source code as PD - you can do anything you like with it. The FSF's four freedoms are:
For #1, PD allows you to do this, and it also allows an end user to run it as a client of a closed source, commercial project, which the GPL disallows.
For #2, PD allows you to do this as well, only the "your needs" that you can adapt it to are broader; you can do anything that you could do under the GPL, but you can also implement a fully commercial, closed source modification (or use) of the PD code in distribution.
For #3, you can redistribute or not, just as under the GPL. But you can also redistribute as closed source, modified or not, which you cannot do under the GPL.
For #4, you can do anything the GPL allows here, and you can also improve it (or just use it) and release it in proprietary executable form so you can benefit people in a way that the GPL does not allow.
Clearly, if the four freedoms are the critical issue, then PD is a far superior mechanism for implementing them. You said you were looking for a mechanism to protect the four freedoms in "any" situation; it is obvious that the GPL protects them in considerably fewer situations than does PD. As near as I can figure out, nothing protects them in "all" situations, not even PD.
What the GPL actually accomplishes is the erection of a legal structure that must be navigated or avoided by those people who choose to be downstream clients of GPL'd source. This means that lawyers have an opportunity to earn money, people are restricted in how they can use such projects in ways they would not have been if the project had been PD, and (here we get into the actual reason for the GPL, or so my instincts tell me) any changes or improvements to the code must be made available to everyone if the code is redistributed in any form.
So a value exchange — new changes going to the community in exchange for the use of the unmodified project — is a behavior forced upon the users of GPL'd code. The freedom to do this of course exists with PD, but it isn't freedom to do this that the GPL is actually working to implement; it is the requirement to do it.
As other posters have said before me, by all means, if the GPL is what you want to use, then use it.
Just don't think it is freedom that you're getting. What you're getting is restriction at the expense of freedom. Which may be precisely what you want. Just be sure it is. If the four freedoms are what you want to protect and foster, then PD is a much better choice.
Me, I'll either go commercial, or I'll go PD. The former is a means to earn a living with what I consider to be the strongest potential to earn; the latter is a means to benefit the developer community in the broadest possible sense, which in turn can benefit others downstream from the developers. The GPL, as far as I am concerned, isn't even in the running.
Add. A lot.
The OS has "first rights" to all the resources that make things fast. It has the CPU before any app does; so the more time it spends using said CPU (or CPUs), the less cycles available to a user app, and therefore, the user app slows down. It has RAM before any app does; so if it eats up RAM that a user app could use, the user app is forced into conservative strategies (swapping, block processing, etc.) that it otherwise could have avoided. This can result in a huge difference in application speed. Both linux and OS X are quite likely to page something out of RAM and onto the hard drive even if you're using it when RAM gets tight. Or the OS might flat out fail to run your app if there isn't enough RAM. So if the OS is careful, even penurious, about its use of RAM, this benefits user apps, especially large ones. And speed will be the first thing you notice.
That's why the optimum strategy is to (a) buy the fastest CPU you can afford, and (b) the most RAM you can afford. Doesn't hurt to hunt down apps that are known to be conservative in RAM use and built with less inherently clunky/hoggish technologies (often that means c instead of c++, for instance.) Look for the application that does what you want that has the smallest executable. Then look to see how much RAM is taken when it is running as compared to the others. It's a fun exercise and can provide you with many surprises, not to mention useful results.
Both multiple workspaces and backup software have been available for quite some time. I have both on all my machines. Aside from the damage done to the Apple developers who used to fill those niches (not quite as blatant as the hit to the Konfabulator people, but still), there's not a lot there to take notice of.
I'm just hoping I'll be able to refresh a network share; right now, if something changes, disconnect and reconnect. Fairly annoying.
Awesome, truly awesome. Mods, wake up! Follow the link!
Yeah, yeah, I know it only affects physical outcomes. Laugh anyway. It's Monday.
For offline work, it might mean there's a menu entry such as "Check for New Version" or "Volunteer to beta test new version" or some such thing.