.NET emphasizes safe, portable runtimes (very similar to Java), as well as extensive runtime and language support for components. Maybe that's all marketing hype, or maybe Microsoft will fail at that and revert to their old ways, but at least on paper, that's very different from Gnome and the environments built on top of it.
Gnome is still a C-based system with a variety of language bindings on top of it (Perl, Python, C++, etc.). There is no unifying runtime or unifying object model underlying Gnome.
If open source efforts want to compete with.NET, they'd have to adopt similar technologies. A Java runtime is the most obvious choice, though not necessarily with Sun's Java libraries.
I for one think Outlook is horrible. Besides its numerous security holes, I find its user interface cumbersome. Yet, many Outlook users would defend their mail client religiously.
The fact is that there isn't a single piece of software that makes everybody happy. The problem with Windows is not that it's universally bad, but that it wants to be the one platform everybody uses. And I think it's not all that desirable that Helix/Gnome and KDE are trying to give us more of the same stuff. Using KDE2 is almost like using Windows now, down to the senseless editor bindings, and Gnome seems poised to follow suit.
On top of that,
Evolution has a number of features that are pretty
interesting like vFolders (which are virtual folders that
are created dynamically as the result of a query on
your mail). We believe that vFolders will create a new
way of dealing with your information in better, smarter
ways.
Virtual folders have been around for a while, among other places, in the Emacs VM mail reader. It would be nice if open source projects would acknowledge other open source projects.
(Gee, Miguel is beginning to sound like he's making a venture capital pitch.)
Most of the inventions that had transformed life between 1900 and 1950 were made around 1900 or sometimes even long before. Likewise, the impact of today's inventions isn't going to be really felt for a long time; we have barely scratched the surface of what is possible once biotechnology and computing become ubiquitous.
That isn't to say that there aren't problems. The article points out correctly that preventive healthcare and public health is much more important to increasing life span than other medical advances. And economic opportunism and vested interests may well keep inventions from reaching their true potential for decades to come.
How superficial the article is, you can see from its concluding remarks. While Thomas Edison was cleary important in popularizing and marketing inventions, much of what he was successful with had been invented many years prior to him--including the light bulb.
The article and analysis is about as hostile to open source as it coulde be. The reasoning is that because someone may have seen Microsoft's source code, its security problems may become understood by crackers, and that puts the security of the system at risk.
"Whoever stole proprietary secrets at
the heart of the ubiquitous Windows
program can hack into any PC in the
world that uses it and is connected to
the Internet," the report states.
Of course, that's completely bogus and runs counter to decades of experience with computer security. If Windows were so full of holes that people with access to the source code could break in, Windows would be compromised a lot more than it is. Besides, lots of people have access to Windows source code already, and such security holes would be hard to keep under wraps. If Windows wants to become more secure, it needs more public exposure of its source code, not less.
It is scary to think that people like Hamre and his think tank are considered authorities when it comes to "cybersecurity", as they call it.
Great, just what we need: another overblown client with its own "full OOP language, XML, and socket connections". Another set of security holes in the client. Another reason to buy nothing but Microsoft and Apple because that's the only place Macromedia will bother to support this stuff fully. More duplication of functionality and code bloat. More content that's entertaining and distracting rather than informative. And all defined at the convenience of a single vendor who wants to use their market position to do an end-run around open standards. And another chance for people like you to sell lots of books and training on repackaged old technology.
Sorry, I am most unimpressed. Macromedia has a legal right to do this sort of thing, but for users, it's a good idea to turn this sort of thing off and complain to any web master whose site it is an important component of.
They don't make a moral argument, they make an economic argument: if you sell used books, writers won't have an incentive to produce much anymore and you'll be able to sell fewer books in the long run.
And that amounts to trying to make an end-run around fair-use doctrines through collusion among participants in the market. I actually consider that immoral.
Most people I know don't sell the books they enjoy. It's the commercial, hyped drivel that they bought by accident that they would like to get rid of. Those books should be returnable to the publisher as a defective product in the first place.
Far from depriving good authors of their well-deserved compensation, a thriving, efficient market in used books finally restores some real economic feedback into the book market. Maybe this will finally serve to weed out the bad stuff from the good stuff and have publishers pay more attention to quality than to marketability again.
Regarding the possibility of an attacker standing between you and your bank, I
suggest you do a traceroute sometime and look how many systems and how many
companies (and therefore employees) have access to your packets.
The same is true for telephone conversations or financial transactions. Thousands of people have opportunities to intercept either, yet there seems to be fairly little actual fraud by employees. My point is that ISPs and backbones carry important personal data, and their employees must live up to a similar level of responsibility. This isn't a burden the consumer should have to carry.
SSH and SSL are clearly designed to protect against MITM attacks as well as passive eavesdropping.
Well, I suppose you are right that the intent is arguable. However, the actual product is clearly ineffective in preventing them. And that's hardly a surprise: without secure key distribution via a route other than the Internet, there is no way you can guard against man-in-the-middle attacks.
To a company, grunt work is easier to find than managerial talent. Managerial talent is what makes money, what makes the company work.
Without technical expertise there would be no technical company. Managerial expertise, on the other hand, may or may not be necessary to keep things running smoothly.
For example, in many professional offices (doctors, lawyers, engineering consulting), there is no separate management. And a 6-8 person office with technical experts may well operate more like a professional office than a big, old-style hierarhical company. And it will fail if its technical talent isn't top notch.
I think the long release times are in part due to the architecture of the Linux kernel. Unlike user mode programs, where add-ons are very easy to distribute separately, for the kernel, many kinds of features seem to require extensive discussion, coordination, and planning before they can added, and they really only get used widely if they are part of a kernel distribution.
The architecture of the current Linux kernel served it well over the first few years of its existence: it allowed a lot of features and reasonable performance to be implemented quickly. But it may not serve as well in the current environment.
Can we solve this problem? Maybe one of the open source microkernels, or maybe the use of some other programming language for the kernel that couples different parts of the kernel less tightly and isolates the kernel from problems in individual modules would help. Or maybe it will be possible to move there incrementally, without starting from scratch.
To summarize what you seem to be saying: you implemented a custom software package that gives you roughly what XML and the DOM do: declarative tags and a programmatic interface to manipulate them. That appears to imply that you have something that isn't really used like JSP, and you have something that doesn't really conform to a widely used standard.
Since XML/XHTML and the DOM give you a widely-used and pretty well defined way of doing just that, why not just build tools that conform to those standards?
however, XSLT is hard! its hard for developers to learn, its hard to debug, its hard to tune for performance.
You don't need to use XSLT to use the XML related standards for building web applications. You can implement transformations using a DOM API, you can take the xmlc approach used by Enhydra, or you can take any of a number of other approaches.
The essence of such an approach is that both the presentation (possibly in the form of XHTML) and the content are represented as data structures. XSLT is only one way of putting the two together. Manipulating the two data structures via a custom-written servlet is another, which is what I was suggesting.
nobody reccomends that you use JSP like PHP or ASP.
There is nothing in JSP, after all, that restricts people from doing full programming, including conditionals and loops. In fact, many JSP examples do just that, just the same way ASP and PHP programmers do it. That's fine for quick hacks (PHP is great for that), but it isn't good for large projects in my opinion.
Servlets are far worse because you end up embedding chunks of HTML in your methods.
That's the old style of writing servlets, not what I am referring to.
If you build your web application out of XML and servlets, there is no markup or content in methods. The whole point of using XML (including XHTML and DOM) is to separate processing from presentation. In such a system, servlets only contain logic.
Servlets are very useful, but I think you should forget JSP. While mixing content and code like that is very popular (ASP, PHP, JSP, etc.), it causes a lot of problems as you try to maintain the site. Most importantly, you can't as easily hand of writing to a writer or code maintenance to a programmer because each will trip over the other's stuff.
Consider using some form of XML or template system instead. For Java, you can get several servlet-based template systems, as well as a number of XML implementations (check xml.apache.org).
Re:great program, but it isn't keeping up
on
Gimp 1.2.0 Released
·
· Score: 2
First, doing image processing the way he suggests has been tried by a number of others (me included). It's so
much simpler to operate directly on a raster that the users themselves have abandoned this sort of program as
they've gained access to machines that can handle the full resolution image.
Well, I have implemented image processing routines of both types myself. Yes, implementing filters on the full resolution image is simple and well understood. It is also the most general, and you can implement a great variety of filters easily that way.
But the most common operations can be implemented in a pretty straightforward way in a compressed multiresolution representation as well. I'm pretty sure that a system that performs such operations would help a great number of people doing day-to-day operations much more efficiently. I also think that it is possible (with on-the-fly decompression) to reuse many of the full resolution filters in such a system without rewrite (but also without the associated performance gain).
Third, that's just not the way Free Software works. Coders do what they want to do, and the user's needs are a
distant second to those of the developer. A very large and healthy commercial market exists if you want things the
ohter way around.
Speaking as a user, I think there is nothing wrong for the authors of free software to be aware of what users think and what limits they hit. The Gimp is really hitting its limits for me, and I suspect for many other users as well, when it comes to dealing with the kind of data digital cameras and scanners spit out these days.
Now, let me emphasize again that I think the Gimp authors have been doing and are doing a great job, they are under no obligation to even consider this issue.
But even as the step towards a new free software project, talking about the limits of existing systems and possible new approaches in the context of an excellent and established free software system like the Gimp seems like the right place to start: that's where people with similar interests are likely to be found, after all.
Those are good and valid questions. Let me provide a bit more information.
It seems like there may be a paper that you should have provided a link to...
A readable reference is Stollnitz, DeRose, and Salesin: "Wavelets for Computer Graphics".
First question: why isn't Moore's promise of faster processors+more RAM sufficient for the GIMP (I've only used it casually, so I may have not noticed it as being as slow as other people...)
Depends on what you want to do with it, how much time you have, and how much you are willing to pay for the hardware. You can edit a single 2000x3000x8 image on a PentiumIII with a few hundred megabytes just fine. If you want to composite six of those images, it's going to be painful. If you want to color correct a hundred of them, it's going to be painful as well. If you want to edit a 600dpi 16 bit scan, you are talking 210Mbytes just for a single image: a lot of data to move around, and a big chunk of address space.
Second question: if the GIMP isn't keeping up, and other commercial programers aren't keeping up.... then who is?
And even if these hypothetically Jonses do exist, what is the quality of images using their edit-while-compressed
technology? Who said it was commercial quality? The computer scientist who invented it... or a professional graphic
artist?
Done right, there should be no difference in quality. Not all operations can be done fast in the compressed domain, but enough common ones can be to make this useful.
Who is doing it? I think you are going to see a lot more of that coming pretty soon in systems like Photoshop. In part, they are probably waiting for JPEG2000. There are also a number of research packages (downloadable) that do wavelet-based image processing, although often with different applications in mind.
Incidentally, the fact that the commercial market hasn't picked it up doesn't mean it isn't mature. Photoshop users for years thought that "scripting" was an obscure and advanced functionality.
Third question: I beleive I'm not alone when I say I'm not exactly sure what you mean when you say "multiresolution
editing"... at least not in a way that would require a total rewrite of a program... care to elaborate?
See my other response; basically, what I mean by it here is being able to perform many image operations without touching every pixel (I should perhaps have said more properly "compressed domain editing" or "wavelet-based editing", but those terms have their own problems).
Let me emphasize again that I'm not complaining about the Gimp: I think it's a great and useful program and its developers have done a terrific job. However, I regularly hit its limits and there aren't any good commercial alternatives out there either. I think this is a good opportunity to start applying some pretty well understood computer graphics technology in an open source project.
Well, recording and replaying is one approach to getting some of the benefits. But it isn't quite what I mean.
If multiresolution representations are implemented well, you perform the image processing operations directly in the compressed domain and often never have to touch most of the coefficients in the image. Many forms of color adjustments (with or without masks), sharpening, smoothing, and painting fall into that domain. There is no need to replay anything, and you can inspect full resolution results instantly.
Systems like SSH and SSL are clearly designed to protect against eavesdropping, not against man-in-the-middle attacks. Now, are man-in-the-middle attacks really a problem?
Tools like dsniff seem mainly designed for use on non-switching LANs. Unless you manage to subvert the infrastructure of a major ISP, I don't see how they would help you with hacking the traffic between me and my bank using a man-in-the-middle attack. But the infrastructure problems that allow man-in-the-middle attacks are much easier to exploit for denial-of-service, so it seems likely that major ISPs already have a strong incentive to guard against them.
So, before getting all pushed out of shape about the possibilities, I would like to hear more discussion about the possibility of man-in-the-middle attacks on the Internet infrastructure itself--the part between my site and the bank's site which neither the bank nor I control; the case of attacks on shared LANs at my site or the bank just isn't all that interesting to me because I don't perceive it as a significant additional threat compared to what my users or the bank's employees can already accomplish using other, simpler means.
The Gimp is a great program, well written, and very useful. But I'm afraid it isn't keeping up with technology.
One area is probably fairly easy to address: photo manipulation programs are used more and more for web design and page layout, and for that, they need features like better vector drawing support, page layout and text support, and output plugins for formats like Flash.
Another area is more fundamental. The Gimp right now uses bitmaps as its fundamental data representation. That makes even simple operations very compute intensive, and even simple operations take up a lot of resources to undo. Combining wavelet-based and multiresolution editing with edit lists provides a way out: it allows the results of operations to be displayed quickly, operations can be undone quickly, and often images (e.g., JPEG2000 compressed images) don't even have to be decompressed fully to be displayed or manipulated. I think addressing this issue will require a fundamental rewrite.
Anyway, for now, I'm really grateful to have the Gimp available: it's a reliable workhorse, and even most commercial programs are still behind the state of the art.
I suspect that operating systems like Linux will continue to be able to read and write "uncontrolled" content to such devices. Think about how DVDs work right now. What this technology most likely allows is compliant hardware and software that contains special keys to read and write data that cannot be accessed otherwise.
That's an annoying infringement on fair use, but it isn't as serious as the end to all free software. In the long run, I think this kind of technology is going to be a dud. It will cause lots of headaches to consumers and computer users alike. It will probably fall into disuse. It may actually be beneficial because it gives free content an advantage, since free content can spread unhindered, while the commercial junk is subject to all sorts of problems and limitations.
Nevertheless, I don't have much respect for people developing these kinds of methods. Apart from the violation of fair use rights that it enables, to me, it is simply poor judgement and in poor taste.
If it isn't defensible to outlaw posession of the code, its distribution shouldn't be outlawed either; otherwise, the legislators and judges are merely trying to hide what they are really doing behind some technicalities. If the US continues to go down this road, it will end up a police state.
IBM isn't doing this out of the goodness of their hearts, they are doing it to reduce their own software-related costs and generate more interest in UNIX. There is nothing wrong with that, but if you view every dusty deck anybody contributes as a valuable addition, you are endangering Linux.
Let me put it more concretely. Do you put every piece of discarded furniture someone offers you into your living room? Do you accept every "donation" to you of cute puppies and kittens from the humane society? Well, old proprietary code is like old furniture or stray kittens: it might fit your needs, it may be cute, but more often than not, you want to say "no" to maintain some room where you can live. There is nothing "ungrateful" about that, nor is there in telling them that you would prefer the black kitten over the puppy.
Slashdot Mirror
Gnome is still a C-based system with a variety of language bindings on top of it (Perl, Python, C++, etc.). There is no unifying runtime or unifying object model underlying Gnome.
If open source efforts want to compete with .NET, they'd have to adopt similar technologies. A Java runtime is the most obvious choice, though not necessarily with Sun's Java libraries.
(Intel's ORP sounds interesting in this regard.)
The fact is that there isn't a single piece of software that makes everybody happy. The problem with Windows is not that it's universally bad, but that it wants to be the one platform everybody uses. And I think it's not all that desirable that Helix/Gnome and KDE are trying to give us more of the same stuff. Using KDE2 is almost like using Windows now, down to the senseless editor bindings, and Gnome seems poised to follow suit.
Virtual folders have been around for a while, among other places, in the Emacs VM mail reader. It would be nice if open source projects would acknowledge other open source projects.
(Gee, Miguel is beginning to sound like he's making a venture capital pitch.)
That isn't to say that there aren't problems. The article points out correctly that preventive healthcare and public health is much more important to increasing life span than other medical advances. And economic opportunism and vested interests may well keep inventions from reaching their true potential for decades to come.
How superficial the article is, you can see from its concluding remarks. While Thomas Edison was cleary important in popularizing and marketing inventions, much of what he was successful with had been invented many years prior to him--including the light bulb.
Of course, that's completely bogus and runs counter to decades of experience with computer security. If Windows were so full of holes that people with access to the source code could break in, Windows would be compromised a lot more than it is. Besides, lots of people have access to Windows source code already, and such security holes would be hard to keep under wraps. If Windows wants to become more secure, it needs more public exposure of its source code, not less.
It is scary to think that people like Hamre and his think tank are considered authorities when it comes to "cybersecurity", as they call it.
Sorry, I am most unimpressed. Macromedia has a legal right to do this sort of thing, but for users, it's a good idea to turn this sort of thing off and complain to any web master whose site it is an important component of.
It is quite evident that Clancy lives by his word: he appears to produces book to make money, not out of literary or artistic motives.
And that amounts to trying to make an end-run around fair-use doctrines through collusion among participants in the market. I actually consider that immoral.
Far from depriving good authors of their well-deserved compensation, a thriving, efficient market in used books finally restores some real economic feedback into the book market. Maybe this will finally serve to weed out the bad stuff from the good stuff and have publishers pay more attention to quality than to marketability again.
The same is true for telephone conversations or financial transactions. Thousands of people have opportunities to intercept either, yet there seems to be fairly little actual fraud by employees. My point is that ISPs and backbones carry important personal data, and their employees must live up to a similar level of responsibility. This isn't a burden the consumer should have to carry.
SSH and SSL are clearly designed to protect against MITM attacks as well as passive eavesdropping.
Well, I suppose you are right that the intent is arguable. However, the actual product is clearly ineffective in preventing them. And that's hardly a surprise: without secure key distribution via a route other than the Internet, there is no way you can guard against man-in-the-middle attacks.
Seems to me they are trying to do roughly what SashXB from IBM is doing, just less well, using less standard components, and in closed source form.
Without technical expertise there would be no technical company. Managerial expertise, on the other hand, may or may not be necessary to keep things running smoothly.
For example, in many professional offices (doctors, lawyers, engineering consulting), there is no separate management. And a 6-8 person office with technical experts may well operate more like a professional office than a big, old-style hierarhical company. And it will fail if its technical talent isn't top notch.
The architecture of the current Linux kernel served it well over the first few years of its existence: it allowed a lot of features and reasonable performance to be implemented quickly. But it may not serve as well in the current environment.
Can we solve this problem? Maybe one of the open source microkernels, or maybe the use of some other programming language for the kernel that couples different parts of the kernel less tightly and isolates the kernel from problems in individual modules would help. Or maybe it will be possible to move there incrementally, without starting from scratch.
Since XML/XHTML and the DOM give you a widely-used and pretty well defined way of doing just that, why not just build tools that conform to those standards?
You don't need to use XSLT to use the XML related standards for building web applications. You can implement transformations using a DOM API, you can take the xmlc approach used by Enhydra, or you can take any of a number of other approaches.
The essence of such an approach is that both the presentation (possibly in the form of XHTML) and the content are represented as data structures. XSLT is only one way of putting the two together. Manipulating the two data structures via a custom-written servlet is another, which is what I was suggesting.
nobody reccomends that you use JSP like PHP or ASP.
There is nothing in JSP, after all, that restricts people from doing full programming, including conditionals and loops. In fact, many JSP examples do just that, just the same way ASP and PHP programmers do it. That's fine for quick hacks (PHP is great for that), but it isn't good for large projects in my opinion.
That's the old style of writing servlets, not what I am referring to.
If you build your web application out of XML and servlets, there is no markup or content in methods. The whole point of using XML (including XHTML and DOM) is to separate processing from presentation. In such a system, servlets only contain logic.
Consider using some form of XML or template system instead. For Java, you can get several servlet-based template systems, as well as a number of XML implementations (check xml.apache.org).
Well, I have implemented image processing routines of both types myself. Yes, implementing filters on the full resolution image is simple and well understood. It is also the most general, and you can implement a great variety of filters easily that way.
But the most common operations can be implemented in a pretty straightforward way in a compressed multiresolution representation as well. I'm pretty sure that a system that performs such operations would help a great number of people doing day-to-day operations much more efficiently. I also think that it is possible (with on-the-fly decompression) to reuse many of the full resolution filters in such a system without rewrite (but also without the associated performance gain).
Speaking as a user, I think there is nothing wrong for the authors of free software to be aware of what users think and what limits they hit. The Gimp is really hitting its limits for me, and I suspect for many other users as well, when it comes to dealing with the kind of data digital cameras and scanners spit out these days.
Now, let me emphasize again that I think the Gimp authors have been doing and are doing a great job, they are under no obligation to even consider this issue.
But even as the step towards a new free software project, talking about the limits of existing systems and possible new approaches in the context of an excellent and established free software system like the Gimp seems like the right place to start: that's where people with similar interests are likely to be found, after all.
A readable reference is Stollnitz, DeRose, and Salesin: "Wavelets for Computer Graphics".
Depends on what you want to do with it, how much time you have, and how much you are willing to pay for the hardware. You can edit a single 2000x3000x8 image on a PentiumIII with a few hundred megabytes just fine. If you want to composite six of those images, it's going to be painful. If you want to color correct a hundred of them, it's going to be painful as well. If you want to edit a 600dpi 16 bit scan, you are talking 210Mbytes just for a single image: a lot of data to move around, and a big chunk of address space.
Done right, there should be no difference in quality. Not all operations can be done fast in the compressed domain, but enough common ones can be to make this useful.
Who is doing it? I think you are going to see a lot more of that coming pretty soon in systems like Photoshop. In part, they are probably waiting for JPEG2000. There are also a number of research packages (downloadable) that do wavelet-based image processing, although often with different applications in mind.
Incidentally, the fact that the commercial market hasn't picked it up doesn't mean it isn't mature. Photoshop users for years thought that "scripting" was an obscure and advanced functionality.
See my other response; basically, what I mean by it here is being able to perform many image operations without touching every pixel (I should perhaps have said more properly "compressed domain editing" or "wavelet-based editing", but those terms have their own problems).
Let me emphasize again that I'm not complaining about the Gimp: I think it's a great and useful program and its developers have done a terrific job. However, I regularly hit its limits and there aren't any good commercial alternatives out there either. I think this is a good opportunity to start applying some pretty well understood computer graphics technology in an open source project.
If multiresolution representations are implemented well, you perform the image processing operations directly in the compressed domain and often never have to touch most of the coefficients in the image. Many forms of color adjustments (with or without masks), sharpening, smoothing, and painting fall into that domain. There is no need to replay anything, and you can inspect full resolution results instantly.
Tools like dsniff seem mainly designed for use on non-switching LANs. Unless you manage to subvert the infrastructure of a major ISP, I don't see how they would help you with hacking the traffic between me and my bank using a man-in-the-middle attack. But the infrastructure problems that allow man-in-the-middle attacks are much easier to exploit for denial-of-service, so it seems likely that major ISPs already have a strong incentive to guard against them.
So, before getting all pushed out of shape about the possibilities, I would like to hear more discussion about the possibility of man-in-the-middle attacks on the Internet infrastructure itself--the part between my site and the bank's site which neither the bank nor I control; the case of attacks on shared LANs at my site or the bank just isn't all that interesting to me because I don't perceive it as a significant additional threat compared to what my users or the bank's employees can already accomplish using other, simpler means.
One area is probably fairly easy to address: photo manipulation programs are used more and more for web design and page layout, and for that, they need features like better vector drawing support, page layout and text support, and output plugins for formats like Flash.
Another area is more fundamental. The Gimp right now uses bitmaps as its fundamental data representation. That makes even simple operations very compute intensive, and even simple operations take up a lot of resources to undo. Combining wavelet-based and multiresolution editing with edit lists provides a way out: it allows the results of operations to be displayed quickly, operations can be undone quickly, and often images (e.g., JPEG2000 compressed images) don't even have to be decompressed fully to be displayed or manipulated. I think addressing this issue will require a fundamental rewrite.
Anyway, for now, I'm really grateful to have the Gimp available: it's a reliable workhorse, and even most commercial programs are still behind the state of the art.
That's an annoying infringement on fair use, but it isn't as serious as the end to all free software. In the long run, I think this kind of technology is going to be a dud. It will cause lots of headaches to consumers and computer users alike. It will probably fall into disuse. It may actually be beneficial because it gives free content an advantage, since free content can spread unhindered, while the commercial junk is subject to all sorts of problems and limitations.
Nevertheless, I don't have much respect for people developing these kinds of methods. Apart from the violation of fair use rights that it enables, to me, it is simply poor judgement and in poor taste.
If it isn't defensible to outlaw posession of the code, its distribution shouldn't be outlawed either; otherwise, the legislators and judges are merely trying to hide what they are really doing behind some technicalities. If the US continues to go down this road, it will end up a police state.
Let me put it more concretely. Do you put every piece of discarded furniture someone offers you into your living room? Do you accept every "donation" to you of cute puppies and kittens from the humane society? Well, old proprietary code is like old furniture or stray kittens: it might fit your needs, it may be cute, but more often than not, you want to say "no" to maintain some room where you can live. There is nothing "ungrateful" about that, nor is there in telling them that you would prefer the black kitten over the puppy.