The D programming language is grossly under specified and only runs on a subset of machines that C supports. I'm not even going to bother mentioning all the design decisions that I believe Walter Bright got wrong that keeps me from using D.
Please do bother. This is the first time I've heard of this language, and I'm trying to decide if I should take an interest in it. From a quick glance, it looks pretty interesting, but if there's known problems with it, I'd like to know that up-front instead of having to discover them on my own after investing time and energy into it...
No formatting, no fonts, no graphics, certainly (even the dot matrix printers generally didn't have any graphics capability whatsoever--it just wasn't included; only the ability to accept a stream of ASCII and dump it out to the page was in the ROM).
The ImageWriter was hardly the first dot-matrix printer with graphics support. I remember when I was in middle school (1981-1983), the school had an Epson dot-matrix printer with full graphics capabilities -- I remember poring over the manual figuring out how to control the output pixel by pixel.
I think the printer in question was a successor to the MX-80, maybe an FX-80? From a Google search, I found that the MX-80 was released in 1980, evidently with some simple graphics characters in the character set, and a later graphic chip upgrade allowed for full bitmapped graphics capability. I believe the FX-80 had this full graphics capability out of the box, and it was released in 1982.
Granted, the Mac was the first to really take advantage of this graphics capability to generate more readable fonts for everyday documents, but the hardware capability already existed for years before the Mac was released in 1984. And as I recall, PrintShop generated high-quality fonts using printer graphics before the Mac was around, but that was used more for signs...
Back in the mid-80's when I was in high school, my computer was an Atari 800. Eventually, I scraped together enough pennies to buy a crappy little CAL-ABCO Legend 808 Printer, a printer so obscure that a Google image search turns up empty, but a web search turned up someone selling one now for $5! It was a poor 9-pin Epson clone with a wax ribbon and bad print quality, but it did have graphics capability.
Years later, when I owned an Amiga but could not afford a new printer, I decided to see just how far I could push this crappy little printer. I actually wrote my own Amiga printer driver for it, based on an example driver and the codes from the manual. Once that was working, I was able to print anything from my Amiga to my Legend 808 in graphics mode. I then used Ghostscript to render PostScript and output it to the printer.
I daresay that my Legend 808 was probably the only one in the world that ever rendered outline fonts using PostScript!
(These days, I still have the Legend 808 sitting in a box for nostalgia reasons, but I have 3 laser printers on my desk: a LaserJet 4050, a LaserJet 8000 (both with built-in PostScript support), and a cheap Brother multifunction fax machine that just happened to be a laser model...)
What's truly ironic is that I took a net hit to my karma for utilizing my karma to draw attention to the parent comment, which was ultimated modded up to 5 in the end.
You must be referring to Veeck vs. SBCCI, wherein a 5th Circuit Court of Appeals decision held that "the law" is in the public domain, including such portions of a model code as are incorporated by reference. (The U.S. Supreme Court denied certiorari.) Note that the model codes still retain their copyright as model codes, but once incorporated into "the law" (even by reference), the incorporated portions are in the public domain as "the law" of that jurisdiction. (I am not a lawyer, but I did read the full text of the decision.)
It's significant to note that this was an en banc review of the case, and the earlier 3-judge panel had come to the opposite conclusion, upholding the copyright. Be thankful that the full appeals court reached the correct public policy conclusion!
Note that the important point was that the model codes had been adopted as law, not the fact that SBCCI had encouraged such adoption. The latter fact was what kept it from being a "takings" case. As I read the decision, the incorporated model codes would have still become public domain as "the law", even if incorporated by reference without permission, but SBCCI presumably would have had grounds to sue the government for damages in a "takings" case, for the impact on the value of their copyright...
It's also important to note that this case does not place standards referenced by "the law" into the public domain. It specifically distinguishes such cases from this one, where a model code was written for the express purpose of being enacted into law.
I'd say they're exactly the same as the odds that FOX will suddenly have totally new management.
Never say never. After all, Family Guy just returned to FOX. They finally came to their senses on that one, why not for Firefly? (Okay, it's still a long shot...)
For anti-spam laws to have any teeth, jail time is necessary. Perhaps not 9 years, but at least a year or three. Monetary penalties are meaningless -- this guy was grossing $750,000 per month. He can probably afford to pay a million-dollar fine and continue his business. Banning Internet access is pretty hard to enforce, and spammers are already in the business of cloaking their activities. Jail time is the only deterrent that will actually cause a spammer to think twice about what he's doing.
And they may be making an example out of this guy (what do you expect for the first conviction?), but it's a stretch to call him a "victim" -- the true victims were the people receiving his 10 million spam messages every day. Even if it only takes you 1/2 a second to delete each message, that's over 1,388 hours per day of time his spam cost other people. This spammer is hardly an innocent victim.
Also, he forged return addresses to hide his identity, because he knew what he was doing was wrong. That is not innocent behavior, and it's the reason he received this sentence -- the Virginia law he was convicted under does not criminalize mass email unless you mask your identity as well. If he used a valid return address (which could be easily filtered), he would have been immune to this law. RTFA.
If you paid cash (or if you've paid by a check which has cleared), you deserve to be refunded in cash, and the retailer should make every effort to do so. How many $20 bills does a Best Buy store receive in a day? They shouldn't have to give you their stock of $1/$5/$10 bills, which they need for making change, but they don't need tons of $20 bills, nor the occasional $50 and $100 bills they get. If they don't have enough cash at the customer service counter, they can collect larger bills from the cashiers.
If there really isn't enough cash available to refund your money, they should offer to give you what cash they can and a check (on the spot, not weeks later in the mail) for the difference. Or they can offer to have the full cash refund available the next business day when you return for it.
This has nothing to do with whether or not one ought to have a checking account. (For the record, I have several.) This is about sleazy refund policies by a huge corporation who wants to take advantage of the "float" of keeping your money for a couple months longer than they deserve to.
Meanwhile, people with checking accounts who dare to try to take advantage of just a day or two of "float" are now going to start getting burned by checks being cashed instantly, now that Check 21 is the law -- even though the bank will still put a 2-5 day hold on any check you deposit! Why is it that individuals who take advantage of "float" are viewed as trying to cheat the system, yet the system itself is allowed to do the same and worse, and everyone turns a blind eye to it?
I've read the license (many times), and you entirely missed my point.
A third-party document (the GPL) is claiming that you can use any version of the GPL if it's not specified. By what right can they make such a statement? Only the copyright holder may choose the licensing, not the author of the GPL.
Just because the GPL says "If the Program does not specify a version number of this License, you may choose any version ever published", doesn't mean much. That language has no authority unless that version of the GPL is the license intended by the author. If that is the case, then the version of the GPL is already fixed, despite that clause. If that version of the GPL isn't the license being used, then that clause in the license is just as irrelevant as any random clause in Microsoft's EULA.
The GPL isn't magic. It's only a legal tool. The clauses in any given version of the GPL can only apply if that version of the GPL license is used by the copyright holder. Otherwise those clauses are meaningless with respect to that particular copyrighted work. Even if every version of the GPL contains that clause, the one you (as the recipient) are relying on has to come from a particular version of the GPL, being the one which the author has actually licensed his code under! All other versions (despite identical language) are irrelevant because the author didn't release the code under those versions of the GPL.
So the question is which version of the GPL did the author intend to release the code under? Most likely, the most recent version of the GPL at the time of the license grant. At that point, the selection of which version of the GPL to use is locked -- the language of the GPL itself cannot usurp the copyright holder's privilege of determining the license to use.
If the author explicitly states "any version", then go ahead and use whichever version you want -- the author has granted multiple alternative licenses. But if the GPL version is unspecified, the presumption must be that one version of the GPL was intended, and I don't see any legal basis for the recipient to claim the freedom to arbitrarily select any version of the GPL, especially versions not released at the time of the license grant.
I'm not a lawyer, but this seems pretty obvious, once you think about where the authority of the GPL derives from in the first place -- the rights of the copyright holder.
The GPL explicitely includes later licenses only if the program does not reference a specific version of the license.
I'm not convinced this would stand up in court. How can the language of one version of the GPL authorize the assertion that a different version of the GPL applies to the code? Unless the copyright holder explicitly offered the code under any version of the GPL, it seems necessary that one version of the GPL would have to be considered the "right" one, based on the author's intent. This would probably mean the latest version at the time of the license grant.
IANAL, but I'm not convinced that language in GPLv2 can really authorize the use of GPLv1 in its stead, as that would mean that the terms of GPLv2 wouldn't apply after all. (But someone could try to argue that GPLv1 was the intent all along.) It becomes a chicken-and-egg problem -- either version A controls or version B controls, but to pick and choose clauses from multiple versions seems wholly inappropriate.
It seems even more tenuous to read the license grant as authorizing GPLv3 or GPLv4 when GPLv2 was the latest version at the time of the grant. How can you license something under terms which don't even exist yet? And again, I don't know that you can leverage terms in GPLv2 to claim that GPLv3 retroactively applies instead.
It will be interesting to see what happens if this is ever tested in court. If GPLv2 is the most recent version at the time of the license grant, it seems probable that an unspecified GPL version would be interpreted as GPLv2 only. In the absence of any clear indication of intent from the author, I doubt the GPL's "any version" language would be held to be controlling...
That's the theory. Ideally, all the BT traffic would be labelled as bulk data, while the HTTP traffic would not, and ideally the TCP/IP stacks would be smart enough to give the non-bulk HTTP packets priority.
In theory, the HTTP traffic would be only slightly slower than it would be without the BT traffic. Obviously there's some inevitable delay required when waiting to finish transmitting a low-priority packet before the next higher-priority packet could begin, especially if the low-priority packet is large relative to the bandwidth of the link...
Your empty statement example only reinforces my point. You aren't putting that semicolon on its own line because the semicolon syntax is of any particular interest. You're doing it because the empty statement is of interest. The bare semicolon just happens to be a required part of the syntax of an empty statement, and the only visible indication of the empty statement, but the semicolon itself isn't interesting per se. For non-empty statements, you don't give the terminating semicolon its own line, do you?
As for indentation, if you have improperly indented code, it obscures the structure of the code. Braces alone don't really help visualize the code structure, it's the indentation that does it. Seeing the braces only serves as a confirmation. Try eliminating all indentation and newlines and rely on the braces alone to see where the blocks lie. Just how well does that work?
As for your form of commenting out an "if" block being easier, I didn't deny that it was. I just disputed the claim that you need to find the closing brace to comment it out. I don't think the ability to comment out the if conditional conveniently is sufficiently important to drive the decision of what brace style to use.
As for the "logical" conclusion of using this style:
if (condition) {
function(); }
That style is just as bad as this style:
if (condition) { function(); }
The reasons are much the same. You can't operate on statements as lines anymore. If you insert, delete or rearrange lines where the brace is merged with a line of the block, you have to repair the brace, which is a major nuisance. If you keep the opening brace at the end of the "if" line, it never needs to move, so it's not an issue.
And I'm not advocating reserving a line for the closing brace. It's the end the "if" statement as a whole that calls for the newline after that closing brace. When "else" blocks are used, you merge the lines quite efficiently:
if (condition1) {
function1(); } else if (condition2) {
function2(); } else if (condition3) {
function3(); } else {
function4(); }
That's certainly more space-efficient and easier to read than this annoying style:
if (condition1)
{
function1();
}
else
if (condition2)
{
function2();
}
else
if (condition3)
{
function3();
}
else
{
function4();
}
I'd rather read code using K&R's "One True Brace" style any day...
Richard Stallman may protest that "free software" is about "free speech" rather than "free beer", but that's not true. It's about both, "free speech" and "free beer". But RMS cleverly hides the "free beer" part by pretending it's a necessary consequence of "free speech", rather than admitting that he really wants both. (After all, that smacks of Communism, which is a societal taboo...)
I've personally heard Stallman speak in public, addressing the reasons why he started his crusade. One of the points he made was that he felt it was immoral for him to refuse to oblige when a friend asks for a copy of any software in his possession. Since proprietary software makes it illegal for him to follow his moral code, he refuses to use proprietary software at all.
Stallman always makes a point of distinguishing "free software" from "open source" software, even though the latter is basically a marketing term for the former. Stallman emphasizes freedom very loudly, but he's really about the "free beer" just as much. The justifications for "open source" are more pragmatic and driven by quality issues, even though the definition is basically the same.
"Free beer" was not a necessary part of the Open Source Definition!
Granted, if the "free beer" requirement is dropped, "open source" really would differ from "free software", but that's not really a problem. It would even give Stallman a better justification for advocating the "free software" term besides just tilting at windmills. (Doesn't he get enough of that with his "GNU/Linux" tirades?)
On a practical basis, the only really useful goal is to ensure users can freely share patches when they want to. With the "free beer" requirement, obviously they can, but that's not the only way to achieve that goal. All the license really needs is to require that authorized users may freely modify and share (or sell) their modifications to other authorized users.
If this were the requirements of the OSD, we could have practical proprietary commercial software with open source code. Suppose you buy Quicken for Windows under such a license, and therefore the CD comes with the source code. You still can't legally give it to all your buddies and undercut Intuit's market -- that would still be a copyright violation. (And if you're going to violate the copyright, you'll probably do that with the current binary-only version anyhow.)
However, if you and a bunch of other Quicken customers want that version of Quicken to run well under Wine on Linux, you might want to share patches that help it to run better. The license would allow you to share your source code patches (and resulting binaries), but only with others who had already paid Intuit for their copy of Quicken for Windows. Intuit's market is still intact; people who want to use the software still have to pay for it -- but those who need to tweak the software aren't prohibited from doing so.
Now, let's suppose a company wants to port Quicken to Linux. They need to spend significant amounts of money to pay developers to port the source code, so they can't afford to give it away. The license could allow this company to produce a "Quicken for Linux" (probably not using the Quicken trademark however) and sell licenses to people who have already paid for a Quicken for Windows license, or even to sell the product directly to anyone, where Intuit's license fee will be sent to them as part of the sale. End users could still share patches for the Linux port, but only with other users who had paid for both the Quicken for Windows license and the license for the Linux port as well.
In this way, almost all of the practical real-world benefits of open source software could be available even in the realm of proprietary software, rather than forcing this "us vs. them" mentality. (Which exists because Stallman's goal is to exterminate proprietary software development!)
Braces are important to code flow, but they don't require a line by themselves any more than semicolons do. The fact that you're inside a conditional (or loop) is important, and made quite clear by proper indentation. The braces delimit the block, but they're not actually interesting in and of themselves, so they don't deserve to take up all that extra space.
By your argument, we might as well write code like this:
if
(
condition
) {
function() ; }
The interesting part of the code is the part that implements the program logic. The braces are syntax, no more. They're not interesting and shouldn't be highlighted.
Also, if you want to comment out the conditional in K&R style, you don't have to comment out the ending brace; you can just add an opening one:
{//if (condition) {
function(); }
That's not a compelling reason to put the brace on a line by itself.
I've only seen this done a few places, but I find the format
if(test) { statement1 } else { statement2 }
works very well.
Never use this style!
No offense, but this is the most retarded brace style I've ever seen. While you may think it looks good on paper, it's much harder to maintain. I've had the misfortune to be stuck maintaining such code, and invariably I find myself needing to insert a new statement at the start of a block, or delete the first statement in the block, or otherwise rearrange the statements. But you still need to keep the brace at the start of the block (and indent properly), so it becomes a real pain in the ass to modify the code now that line-oriented editing operations won't work.
It's just not worth it. The K&R brace style saves just as much room on paper or screen and remains maintainable. Moreover, proper indentation makes it quite easy to see where the blocks are -- there's no reason to highlight the braces by giving them a line of their own unnecessarily. (But Python takes it too far by eliminating the braces entirely.)
The rule I use is simple. If a nested statement (the body of an if/else, while, for, etc.) is not on the same line as the control structure, then always use braces even if they're not logically necessary.
Thus, this is acceptable:
if (condition) function();
or this:
if (condition) {
function(); }
but never this:
if (condition)
function();
There was a time when I didn't worry about this issue, but one day I spent hours debugging a problem in someone else's code (a Unix Appletalk implementation) that broke because a line of code had been added to the start of a loop body which didn't contain braces. Of course, this pushed the original loop body out of the loop! But because both were indented as if they were in the loop, and logically belonged there, it was a very subtle and difficult bug to track down.
Ever since that experience, I automatically use braces if the statement spans multiple lines. I don't ever want to have to debug something so stupid again.
In order for users to voluntarily mark their packets as "bulk data", there has to be a benefit for them. That benefit is supposed to be higher overall transfer rate.
No, the benefit is that their Internet connection remains usable for interactive traffic instead of slowing to a crawl due to the BitTorrent traffic. (The overall transfer rate is likely to be the same either way.) You don't stop using the Internet just because you're downloading something, do you?
If you're not using your connection for anything else, BitTorrent can max out the bandwidth, with or without the bulk data flag. If you have other traffic, the TCP/IP stack will have to make room in the stream of data for those other packets sooner or later -- and when those packets go through really won't affect the final download time because latency is of little importance. However, it may be critical to the other traffic, so it's best to label the bulk data to keep it from being prioritized before more urgent packets.
Really, the only reason not to use the flag is because such traffic could be easily singled out for blocking. However, such action would be foolish, since people would just stop marking the data as "bulk" if that caused it to get dropped. This would cause all the bulk data to be transferred as if it were time-critical interactive traffic, defeating the value of the flag altogether. (Email can be marked as bulk email, but do spammers use that flag? Of course not! They know they'll be blocked.)
It's best for everyone if all bulk data is labelled, the routers prioritize it intelligently, and nobody blocks bulk data transfers.
The reward for creating inventions and works of authorship is the "copyright bargain" -- society allows the creator exclusive rights for a limited period for the sole purpose of encouraging the creation and dissemination of such works, which otherwise might not be created at all.
Sweat equity has never been a defining factor in copyright issues -- the Supreme Court ruled in the Feist case that some minimal standard of originality is required. A data compilation which takes lots of labor to compile but contains no originality does not become eligible for copyright protection merely because of the work required to create it.
As for the time it takes for a work to become profitable, consider that most businesses operate on a 5-10 year horizon. How many businesses are investing their time, money and efforts into endeavors calculated to pay off in 30 years? Very few indeed.
My thinking is that the original copyright term (14 years) should be very cheap, easily affordable by any starving college student. Getting to the original copyright limit (28 years) should be only moderately more expensive (maybe a few thousand dollars). Getting to current limits (95 years) should be prohibitively expensive. That's just too long.
But it should take 40-50 years before the fees start reaching into the million-dollar range. If you can't build a market after decades, you shouldn't still be keeping your work from the public anyhow -- it's obviously not going anywhere anyhow.
If you could pay in advance for future years, it would save on paperwork. For the sake of example, imagine that the first 3 years of copyright is free and automatic -- no registration required (as now). But then you have to pay a $10 fee to renew for another 3 years, and register the copyright (as used to always be required). Then double for every 3-year period after that. (If registrants pay in advance, they should still have an affirmative duty to maintain current contact information with the Copyright Office, or risk losing their copyrights if they cannot be contacted by someone who might want to license their works...)
You would get 3 years of copyright for free; 6 years for $10; 9 years for $30; 12 years for $70; 15 years for $150; 18 years for $310; 21 years for $630; 24 years for $1,270; 27 years for $2,550; 30 years for $5,110; 33 years for $10,230; 36 years for $20,470; 39 years for $40,950; 42 years for $81,910; 45 years for $163,830; 48 years for $327,670; 51 years for $655,350; 54 years for $1,310,710; 57 years for $2,621,430; 60 years for $5,242,870; 63 years for $10,485,750; 66 years for $20,971,510; 69 years for $41,943,030; 72 years for $83,886,070; 75 years for $167,772,150; 78 years for $335,544,310; 81 years for $671,088,630; 84 years for $1,342,177,270; 87 years for $2,684,354,550; 90 years for $5,368,709,110;...
As you can see, anyone could afford a few years of copyright protection, and it would take several decades before coming anywhere close to the development cost for commercially-created works. By 60 years, the costs are substantial, and prohibitive by 90 years.
If you can get 21 years of protection for $630 total, and most money is made on works in less time than that, is the cost really such an obstacle? And for the few works which are still profitable after such time, it remains affordable for quite a while longer for moderately profitable products.
Go back and read the amici briefs by economists by economists in the Sonny Bono Copyright Term Extension challenge -- almost ALL of the value of copyrights is in the first few years, and virtually none at the end. I don't see that this scheme would be such a disincentive to creation.
However, I do agree that it would be nearly impossible to pass, given the political system and the amount of influence content providers have.
P.S. Those example numbers would have to be very different for patents, since they preclude independent invention. Patents should be getting prohibitively expensive by 20 years, not 90 years.
Can I use my donated time to firefox dev as a tax deduction, ie 10hrs a week = 200$ a week tax discount? perhaps...? is that possible?
Not possible. The IRS does not allow the value of "personal services" to be taken as a tax deduction, even if they're performed for a 501(c)(3) non-profit organization.
If fewer patents are sought, that's great. Let the inventions be in the public domain from the start if they're not worth patenting. We have way too many patents as it stands.
But I don't really see a need to couple the fee structure to the original investment. The issue isn't as much about what it cost to create the work, but what the public is losing by keeping it exclusive to the author/inventor. Like I said, a nominal fee should give you protection for a few years, but eventually the cost should be become noticable, then subtantial, and finally exorbitant.
If Disney wants to pay $1 billion to keep their copyrights on Mickey Mouse for another year or three, let them! They'll only do that if they can reasonably expect to get at least that much money out of the public for it. If the public is going to pay billions of dollars for the creative work that we (as a society) have allowed Disney to keep us from using, why shouldn't the public get some payback for the privilege?
It sure is a better source of government revenue than income taxes! And I bet there's enough copyrighted works and inventions that are profitable enough to justify quite a lot of such revenue...
But Mozilla's problem is that they're under-manned. Where are they supposed to find spare people to hand-hold Ian ? If this RFE was a high priority someone would have already fixed it rather than waiting for Ian to slowly pick his way through the code.
Why is Mozilla under-manned? Because they don't help to bring new developers into the fold. The attitude seems to be "figure it out for yourself, don't bother us until you know all the basics." Not exactly welcoming. If they bothered to find someone to hand-hold Ian for a while, they might now have a new developer who would probably be happy to help hand-hold other new developers.
If manpower is an issue, turning away new developers for lack of manpower is penny wise, pound foolish, isn't it?
Mozilla's attitude problem in this respect is nothing new. This has literally been a problem since day one. Less than 24 hours after Mozilla's initial release (almost 7 years ago now), I wanted to implement an integrated, cross-platform TELNET client for Mozilla (having already implemented the TELNET protocol from scratch before), so I posted an inquiry about it:
Silence. No response whatsoever! I believe I even tried contacting existing developers using IRC as well, but nobody was interested in helping me get started working with the codebase, so I gave up. I simply did not have the time to read through 1,000,000 lines of code to figure out how to get started. Discouraged, I wandered away and found other things to do with my time.
A couple months later, I decided to try it anyway. I checked out all the code over CVS and tried to build it. All I remember is that the build took many hours on my (admittedly slow) computer, and many megabytes as well. Again, the code was too large and unwieldy to work with, and I gave up again.
Later, still wanting to help, I started reporting some bugs to Bugzilla. Over the years, I've participated in 3 dozen bugs, and originated over a dozen myself. The first bug I reported was bug #7617, "apprunner reformats during mouse click on or tabbing to link", reported June 4, 1999. This bug was later resolved as a "duplicate" of a newer bug, #28212, "{table-reflow} Clicking on URL dynamically resizes table cells", reported February 17, 2000.
Since well over 6 months had passed without the bug being fixed, in early 2000, I decided to try again to dig into the massive volume of Mozilla code, reasoning that tracking down a specific bug would allow me to ignore most of the code and focus on the part where the bug was being caused.
Unfortunately, the bug I chose (the first one I had reported) turned out to be incredibly difficult to track down, because the problem was buried in the incremental reflow code for HTML tables, and the rendering engine was extremely complex and little documented. Nevertheless, I spent countless hours tracking down this bug, and was actually getting close to understanding the source of the problem when I ran out of time to work on it. I returned to the problem a month or two later, but by that time, the bug had been closed as WORKSFORME, and the new nightly build wasn't exhibiting the behavior anymore.
Most likely, the bug wasn't actually fixed, but rather masked by the fix for bug #28522, "Clicking or tabbing to link causes incremental reflow". This is probably why the original bug was closed as WORKSFORME -- because nobody actually found and fixed the bug. This means that the incremental reflow bug probably still existed, and just wasn't obvious anymore. That bug may still exist today!
I wanted to go back and verify whether the bug was really fixed or not, but I never found the time and energy to expend on such an effort, when the bug was no longer being manifested as it once was. Regardless, this experience convinced me that Mozilla was too fast-m
I have a better solution. Require an exponentially-growing maintenance fee to keep patents and copyrights out of the public domain. Companies with valuable "intellectual property" can keep them as long as the fee is less than the expected benefit.
Fees should be higher and grow faster for patents than copyrights, since they're more exclusive. Eventually, the fee will be ridiculously expensive (but it's all relative), and the work will be allowed to enter the public domain where it belongs.
Copyrights should start with a free period of automatic copyright protection without registration, but require registration and fees after a year (or several) for continued protection. Modest copyright terms should be affordable to all, while excessive terms will eventually be prohibitively expensive to everyone.
This would be a fair system. The public would be increasingly compensated for the sacrifice it makes to honor the exclusive rights, while abandoned works would enter the public domain far more quickly.
Meanwhile, it would provide another revenue stream for the government that doesn't involve arbitrary taxes. Only those who feel it's in their best interest to maintain the protections would pay these fees. With "intellectual properties" that are worth hundreds of millions to billions of dollars, this could be a substantial revenue stream indeed.
Such a system would truly be in the public interest, but the content industry would abhor such a reform -- they're too used to the free ride they've had so long at the public's expense...
Slashdot Mirror
The D programming language is grossly under specified and only runs on a subset of machines that C supports. I'm not even going to bother mentioning all the design decisions that I believe Walter Bright got wrong that keeps me from using D.
Please do bother. This is the first time I've heard of this language, and I'm trying to decide if I should take an interest in it. From a quick glance, it looks pretty interesting, but if there's known problems with it, I'd like to know that up-front instead of having to discover them on my own after investing time and energy into it...
No formatting, no fonts, no graphics, certainly (even the dot matrix printers generally didn't have any graphics capability whatsoever--it just wasn't included; only the ability to accept a stream of ASCII and dump it out to the page was in the ROM).
The ImageWriter was hardly the first dot-matrix printer with graphics support. I remember when I was in middle school (1981-1983), the school had an Epson dot-matrix printer with full graphics capabilities -- I remember poring over the manual figuring out how to control the output pixel by pixel.
I think the printer in question was a successor to the MX-80, maybe an FX-80? From a Google search, I found that the MX-80 was released in 1980, evidently with some simple graphics characters in the character set, and a later graphic chip upgrade allowed for full bitmapped graphics capability. I believe the FX-80 had this full graphics capability out of the box, and it was released in 1982.
Granted, the Mac was the first to really take advantage of this graphics capability to generate more readable fonts for everyday documents, but the hardware capability already existed for years before the Mac was released in 1984. And as I recall, PrintShop generated high-quality fonts using printer graphics before the Mac was around, but that was used more for signs...
Back in the mid-80's when I was in high school, my computer was an Atari 800. Eventually, I scraped together enough pennies to buy a crappy little CAL-ABCO Legend 808 Printer, a printer so obscure that a Google image search turns up empty, but a web search turned up someone selling one now for $5! It was a poor 9-pin Epson clone with a wax ribbon and bad print quality, but it did have graphics capability.
Years later, when I owned an Amiga but could not afford a new printer, I decided to see just how far I could push this crappy little printer. I actually wrote my own Amiga printer driver for it, based on an example driver and the codes from the manual. Once that was working, I was able to print anything from my Amiga to my Legend 808 in graphics mode. I then used Ghostscript to render PostScript and output it to the printer.
I daresay that my Legend 808 was probably the only one in the world that ever rendered outline fonts using PostScript!
(These days, I still have the Legend 808 sitting in a box for nostalgia reasons, but I have 3 laser printers on my desk: a LaserJet 4050, a LaserJet 8000 (both with built-in PostScript support), and a cheap Brother multifunction fax machine that just happened to be a laser model...)
What's truly ironic is that I took a net hit to my karma for utilizing my karma to draw attention to the parent comment, which was ultimated modded up to 5 in the end.
Oh well, I have excellent karma, I can afford it.
You must be referring to Veeck vs. SBCCI, wherein a 5th Circuit Court of Appeals decision held that "the law" is in the public domain, including such portions of a model code as are incorporated by reference. (The U.S. Supreme Court denied certiorari.) Note that the model codes still retain their copyright as model codes, but once incorporated into "the law" (even by reference), the incorporated portions are in the public domain as "the law" of that jurisdiction. (I am not a lawyer, but I did read the full text of the decision.)
It's significant to note that this was an en banc review of the case, and the earlier 3-judge panel had come to the opposite conclusion, upholding the copyright. Be thankful that the full appeals court reached the correct public policy conclusion!
Note that the important point was that the model codes had been adopted as law, not the fact that SBCCI had encouraged such adoption. The latter fact was what kept it from being a "takings" case. As I read the decision, the incorporated model codes would have still become public domain as "the law", even if incorporated by reference without permission, but SBCCI presumably would have had grounds to sue the government for damages in a "takings" case, for the impact on the value of their copyright...
It's also important to note that this case does not place standards referenced by "the law" into the public domain. It specifically distinguishes such cases from this one, where a model code was written for the express purpose of being enacted into law.
Mod parent up!
That sounds like a GPL project that's begging to be forked and run by more neutral, reasonable people...
I'd say they're exactly the same as the odds that FOX will suddenly have totally new management.
Never say never. After all, Family Guy just returned to FOX. They finally came to their senses on that one, why not for Firefly? (Okay, it's still a long shot...)
They get really impressed if you start handing out that currancy that doesn't have a dead president on it.
What's so impressive about $10 bills?
For anti-spam laws to have any teeth, jail time is necessary. Perhaps not 9 years, but at least a year or three. Monetary penalties are meaningless -- this guy was grossing $750,000 per month. He can probably afford to pay a million-dollar fine and continue his business. Banning Internet access is pretty hard to enforce, and spammers are already in the business of cloaking their activities. Jail time is the only deterrent that will actually cause a spammer to think twice about what he's doing.
And they may be making an example out of this guy (what do you expect for the first conviction?), but it's a stretch to call him a "victim" -- the true victims were the people receiving his 10 million spam messages every day. Even if it only takes you 1/2 a second to delete each message, that's over 1,388 hours per day of time his spam cost other people. This spammer is hardly an innocent victim.
Also, he forged return addresses to hide his identity, because he knew what he was doing was wrong. That is not innocent behavior, and it's the reason he received this sentence -- the Virginia law he was convicted under does not criminalize mass email unless you mask your identity as well. If he used a valid return address (which could be easily filtered), he would have been immune to this law. RTFA.
I agree, the situation is ridiculous.
If you paid cash (or if you've paid by a check which has cleared), you deserve to be refunded in cash, and the retailer should make every effort to do so. How many $20 bills does a Best Buy store receive in a day? They shouldn't have to give you their stock of $1/$5/$10 bills, which they need for making change, but they don't need tons of $20 bills, nor the occasional $50 and $100 bills they get. If they don't have enough cash at the customer service counter, they can collect larger bills from the cashiers.
If there really isn't enough cash available to refund your money, they should offer to give you what cash they can and a check (on the spot, not weeks later in the mail) for the difference. Or they can offer to have the full cash refund available the next business day when you return for it.
This has nothing to do with whether or not one ought to have a checking account. (For the record, I have several.) This is about sleazy refund policies by a huge corporation who wants to take advantage of the "float" of keeping your money for a couple months longer than they deserve to.
Meanwhile, people with checking accounts who dare to try to take advantage of just a day or two of "float" are now going to start getting burned by checks being cashed instantly, now that Check 21 is the law -- even though the bank will still put a 2-5 day hold on any check you deposit! Why is it that individuals who take advantage of "float" are viewed as trying to cheat the system, yet the system itself is allowed to do the same and worse, and everyone turns a blind eye to it?
I've read the license (many times), and you entirely missed my point.
A third-party document (the GPL) is claiming that you can use any version of the GPL if it's not specified. By what right can they make such a statement? Only the copyright holder may choose the licensing, not the author of the GPL.
Just because the GPL says "If the Program does not specify a version number of this License, you may choose any version ever published", doesn't mean much. That language has no authority unless that version of the GPL is the license intended by the author. If that is the case, then the version of the GPL is already fixed, despite that clause. If that version of the GPL isn't the license being used, then that clause in the license is just as irrelevant as any random clause in Microsoft's EULA.
The GPL isn't magic. It's only a legal tool. The clauses in any given version of the GPL can only apply if that version of the GPL license is used by the copyright holder. Otherwise those clauses are meaningless with respect to that particular copyrighted work. Even if every version of the GPL contains that clause, the one you (as the recipient) are relying on has to come from a particular version of the GPL, being the one which the author has actually licensed his code under! All other versions (despite identical language) are irrelevant because the author didn't release the code under those versions of the GPL.
So the question is which version of the GPL did the author intend to release the code under? Most likely, the most recent version of the GPL at the time of the license grant. At that point, the selection of which version of the GPL to use is locked -- the language of the GPL itself cannot usurp the copyright holder's privilege of determining the license to use.
If the author explicitly states "any version", then go ahead and use whichever version you want -- the author has granted multiple alternative licenses. But if the GPL version is unspecified, the presumption must be that one version of the GPL was intended, and I don't see any legal basis for the recipient to claim the freedom to arbitrarily select any version of the GPL, especially versions not released at the time of the license grant.
I'm not a lawyer, but this seems pretty obvious, once you think about where the authority of the GPL derives from in the first place -- the rights of the copyright holder.
The GPL explicitely includes later licenses only if the program does not reference a specific version of the license.
I'm not convinced this would stand up in court. How can the language of one version of the GPL authorize the assertion that a different version of the GPL applies to the code? Unless the copyright holder explicitly offered the code under any version of the GPL, it seems necessary that one version of the GPL would have to be considered the "right" one, based on the author's intent. This would probably mean the latest version at the time of the license grant.
IANAL, but I'm not convinced that language in GPLv2 can really authorize the use of GPLv1 in its stead, as that would mean that the terms of GPLv2 wouldn't apply after all. (But someone could try to argue that GPLv1 was the intent all along.) It becomes a chicken-and-egg problem -- either version A controls or version B controls, but to pick and choose clauses from multiple versions seems wholly inappropriate.
It seems even more tenuous to read the license grant as authorizing GPLv3 or GPLv4 when GPLv2 was the latest version at the time of the grant. How can you license something under terms which don't even exist yet? And again, I don't know that you can leverage terms in GPLv2 to claim that GPLv3 retroactively applies instead.
It will be interesting to see what happens if this is ever tested in court. If GPLv2 is the most recent version at the time of the license grant, it seems probable that an unspecified GPL version would be interpreted as GPLv2 only. In the absence of any clear indication of intent from the author, I doubt the GPL's "any version" language would be held to be controlling...
That's the theory. Ideally, all the BT traffic would be labelled as bulk data, while the HTTP traffic would not, and ideally the TCP/IP stacks would be smart enough to give the non-bulk HTTP packets priority.
In theory, the HTTP traffic would be only slightly slower than it would be without the BT traffic. Obviously there's some inevitable delay required when waiting to finish transmitting a low-priority packet before the next higher-priority packet could begin, especially if the low-priority packet is large relative to the bandwidth of the link...
As for indentation, if you have improperly indented code, it obscures the structure of the code. Braces alone don't really help visualize the code structure, it's the indentation that does it. Seeing the braces only serves as a confirmation. Try eliminating all indentation and newlines and rely on the braces alone to see where the blocks lie. Just how well does that work?
As for your form of commenting out an "if" block being easier, I didn't deny that it was. I just disputed the claim that you need to find the closing brace to comment it out. I don't think the ability to comment out the if conditional conveniently is sufficiently important to drive the decision of what brace style to use.
As for the "logical" conclusion of using this style:That style is just as bad as this style:The reasons are much the same. You can't operate on statements as lines anymore. If you insert, delete or rearrange lines where the brace is merged with a line of the block, you have to repair the brace, which is a major nuisance. If you keep the opening brace at the end of the "if" line, it never needs to move, so it's not an issue.
And I'm not advocating reserving a line for the closing brace. It's the end the "if" statement as a whole that calls for the newline after that closing brace. When "else" blocks are used, you merge the lines quite efficiently:That's certainly more space-efficient and easier to read than this annoying style:I'd rather read code using K&R's "One True Brace" style any day...
Richard Stallman may protest that "free software" is about "free speech" rather than "free beer", but that's not true. It's about both, "free speech" and "free beer". But RMS cleverly hides the "free beer" part by pretending it's a necessary consequence of "free speech", rather than admitting that he really wants both. (After all, that smacks of Communism, which is a societal taboo...)
I've personally heard Stallman speak in public, addressing the reasons why he started his crusade. One of the points he made was that he felt it was immoral for him to refuse to oblige when a friend asks for a copy of any software in his possession. Since proprietary software makes it illegal for him to follow his moral code, he refuses to use proprietary software at all.
Stallman always makes a point of distinguishing "free software" from "open source" software, even though the latter is basically a marketing term for the former. Stallman emphasizes freedom very loudly, but he's really about the "free beer" just as much. The justifications for "open source" are more pragmatic and driven by quality issues, even though the definition is basically the same.
"Free beer" was not a necessary part of the Open Source Definition!
Granted, if the "free beer" requirement is dropped, "open source" really would differ from "free software", but that's not really a problem. It would even give Stallman a better justification for advocating the "free software" term besides just tilting at windmills. (Doesn't he get enough of that with his "GNU/Linux" tirades?)
On a practical basis, the only really useful goal is to ensure users can freely share patches when they want to. With the "free beer" requirement, obviously they can, but that's not the only way to achieve that goal. All the license really needs is to require that authorized users may freely modify and share (or sell) their modifications to other authorized users.
If this were the requirements of the OSD, we could have practical proprietary commercial software with open source code. Suppose you buy Quicken for Windows under such a license, and therefore the CD comes with the source code. You still can't legally give it to all your buddies and undercut Intuit's market -- that would still be a copyright violation. (And if you're going to violate the copyright, you'll probably do that with the current binary-only version anyhow.)
However, if you and a bunch of other Quicken customers want that version of Quicken to run well under Wine on Linux, you might want to share patches that help it to run better. The license would allow you to share your source code patches (and resulting binaries), but only with others who had already paid Intuit for their copy of Quicken for Windows. Intuit's market is still intact; people who want to use the software still have to pay for it -- but those who need to tweak the software aren't prohibited from doing so.
Now, let's suppose a company wants to port Quicken to Linux. They need to spend significant amounts of money to pay developers to port the source code, so they can't afford to give it away. The license could allow this company to produce a "Quicken for Linux" (probably not using the Quicken trademark however) and sell licenses to people who have already paid for a Quicken for Windows license, or even to sell the product directly to anyone, where Intuit's license fee will be sent to them as part of the sale. End users could still share patches for the Linux port, but only with other users who had paid for both the Quicken for Windows license and the license for the Linux port as well.
In this way, almost all of the practical real-world benefits of open source software could be available even in the realm of proprietary software, rather than forcing this "us vs. them" mentality. (Which exists because Stallman's goal is to exterminate proprietary software development!)
If the Open Source Definiti
By your argument, we might as well write code like this:The interesting part of the code is the part that implements the program logic. The braces are syntax, no more. They're not interesting and shouldn't be highlighted.
Also, if you want to comment out the conditional in K&R style, you don't have to comment out the ending brace; you can just add an opening one:That's not a compelling reason to put the brace on a line by itself.
No offense, but this is the most retarded brace style I've ever seen. While you may think it looks good on paper, it's much harder to maintain. I've had the misfortune to be stuck maintaining such code, and invariably I find myself needing to insert a new statement at the start of a block, or delete the first statement in the block, or otherwise rearrange the statements. But you still need to keep the brace at the start of the block (and indent properly), so it becomes a real pain in the ass to modify the code now that line-oriented editing operations won't work.
It's just not worth it. The K&R brace style saves just as much room on paper or screen and remains maintainable. Moreover, proper indentation makes it quite easy to see where the blocks are -- there's no reason to highlight the braces by giving them a line of their own unnecessarily. (But Python takes it too far by eliminating the braces entirely.)
Thus, this is acceptable:or this:but never this:There was a time when I didn't worry about this issue, but one day I spent hours debugging a problem in someone else's code (a Unix Appletalk implementation) that broke because a line of code had been added to the start of a loop body which didn't contain braces. Of course, this pushed the original loop body out of the loop! But because both were indented as if they were in the loop, and logically belonged there, it was a very subtle and difficult bug to track down.
Ever since that experience, I automatically use braces if the statement spans multiple lines. I don't ever want to have to debug something so stupid again.
In order for users to voluntarily mark their packets as "bulk data", there has to be a benefit for them. That benefit is supposed to be higher overall transfer rate.
No, the benefit is that their Internet connection remains usable for interactive traffic instead of slowing to a crawl due to the BitTorrent traffic. (The overall transfer rate is likely to be the same either way.) You don't stop using the Internet just because you're downloading something, do you?
If you're not using your connection for anything else, BitTorrent can max out the bandwidth, with or without the bulk data flag. If you have other traffic, the TCP/IP stack will have to make room in the stream of data for those other packets sooner or later -- and when those packets go through really won't affect the final download time because latency is of little importance. However, it may be critical to the other traffic, so it's best to label the bulk data to keep it from being prioritized before more urgent packets.
Really, the only reason not to use the flag is because such traffic could be easily singled out for blocking. However, such action would be foolish, since people would just stop marking the data as "bulk" if that caused it to get dropped. This would cause all the bulk data to be transferred as if it were time-critical interactive traffic, defeating the value of the flag altogether. (Email can be marked as bulk email, but do spammers use that flag? Of course not! They know they'll be blocked.)
It's best for everyone if all bulk data is labelled, the routers prioritize it intelligently, and nobody blocks bulk data transfers.
The reward for creating inventions and works of authorship is the "copyright bargain" -- society allows the creator exclusive rights for a limited period for the sole purpose of encouraging the creation and dissemination of such works, which otherwise might not be created at all.
...
Sweat equity has never been a defining factor in copyright issues -- the Supreme Court ruled in the Feist case that some minimal standard of originality is required. A data compilation which takes lots of labor to compile but contains no originality does not become eligible for copyright protection merely because of the work required to create it.
As for the time it takes for a work to become profitable, consider that most businesses operate on a 5-10 year horizon. How many businesses are investing their time, money and efforts into endeavors calculated to pay off in 30 years? Very few indeed.
My thinking is that the original copyright term (14 years) should be very cheap, easily affordable by any starving college student. Getting to the original copyright limit (28 years) should be only moderately more expensive (maybe a few thousand dollars). Getting to current limits (95 years) should be prohibitively expensive. That's just too long.
But it should take 40-50 years before the fees start reaching into the million-dollar range. If you can't build a market after decades, you shouldn't still be keeping your work from the public anyhow -- it's obviously not going anywhere anyhow.
If you could pay in advance for future years, it would save on paperwork. For the sake of example, imagine that the first 3 years of copyright is free and automatic -- no registration required (as now). But then you have to pay a $10 fee to renew for another 3 years, and register the copyright (as used to always be required). Then double for every 3-year period after that. (If registrants pay in advance, they should still have an affirmative duty to maintain current contact information with the Copyright Office, or risk losing their copyrights if they cannot be contacted by someone who might want to license their works...)
You would get 3 years of copyright for free; 6 years for $10; 9 years for $30; 12 years for $70; 15 years for $150; 18 years for $310; 21 years for $630; 24 years for $1,270; 27 years for $2,550; 30 years for $5,110; 33 years for $10,230; 36 years for $20,470; 39 years for $40,950; 42 years for $81,910; 45 years for $163,830; 48 years for $327,670; 51 years for $655,350; 54 years for $1,310,710; 57 years for $2,621,430; 60 years for $5,242,870; 63 years for $10,485,750; 66 years for $20,971,510; 69 years for $41,943,030; 72 years for $83,886,070; 75 years for $167,772,150; 78 years for $335,544,310; 81 years for $671,088,630; 84 years for $1,342,177,270; 87 years for $2,684,354,550; 90 years for $5,368,709,110;
As you can see, anyone could afford a few years of copyright protection, and it would take several decades before coming anywhere close to the development cost for commercially-created works. By 60 years, the costs are substantial, and prohibitive by 90 years.
If you can get 21 years of protection for $630 total, and most money is made on works in less time than that, is the cost really such an obstacle? And for the few works which are still profitable after such time, it remains affordable for quite a while longer for moderately profitable products.
Go back and read the amici briefs by economists by economists in the Sonny Bono Copyright Term Extension challenge -- almost ALL of the value of copyrights is in the first few years, and virtually none at the end. I don't see that this scheme would be such a disincentive to creation.
However, I do agree that it would be nearly impossible to pass, given the political system and the amount of influence content providers have.
P.S. Those example numbers would have to be very different for patents, since they preclude independent invention. Patents should be getting prohibitively expensive by 20 years, not 90 years.
Can I use my donated time to firefox dev as a tax deduction, ie 10hrs a week = 200$ a week tax discount? perhaps...? is that possible?
Not possible. The IRS does not allow the value of "personal services" to be taken as a tax deduction, even if they're performed for a 501(c)(3) non-profit organization.
If fewer patents are sought, that's great. Let the inventions be in the public domain from the start if they're not worth patenting. We have way too many patents as it stands.
But I don't really see a need to couple the fee structure to the original investment. The issue isn't as much about what it cost to create the work, but what the public is losing by keeping it exclusive to the author/inventor. Like I said, a nominal fee should give you protection for a few years, but eventually the cost should be become noticable, then subtantial, and finally exorbitant.
If Disney wants to pay $1 billion to keep their copyrights on Mickey Mouse for another year or three, let them! They'll only do that if they can reasonably expect to get at least that much money out of the public for it. If the public is going to pay billions of dollars for the creative work that we (as a society) have allowed Disney to keep us from using, why shouldn't the public get some payback for the privilege?
It sure is a better source of government revenue than income taxes! And I bet there's enough copyrighted works and inventions that are profitable enough to justify quite a lot of such revenue...
Oops, here's a proper link to that initial post:
6 .980401040150.13172A-100000%40escher.ties.org
http://groups.google.com/groups?selm=Pine.LNX.3.9
But Mozilla's problem is that they're under-manned. Where are they supposed to find spare people to hand-hold Ian ? If this RFE was a high priority someone would have already fixed it rather than waiting for Ian to slowly pick his way through the code.
.980401040150.13172A-100000%40escher.ties.org
Why is Mozilla under-manned? Because they don't help to bring new developers into the fold. The attitude seems to be "figure it out for yourself, don't bother us until you know all the basics." Not exactly welcoming. If they bothered to find someone to hand-hold Ian for a while, they might now have a new developer who would probably be happy to help hand-hold other new developers.
If manpower is an issue, turning away new developers for lack of manpower is penny wise, pound foolish, isn't it?
Mozilla's attitude problem in this respect is nothing new. This has literally been a problem since day one. Less than 24 hours after Mozilla's initial release (almost 7 years ago now), I wanted to implement an integrated, cross-platform TELNET client for Mozilla (having already implemented the TELNET protocol from scratch before), so I posted an inquiry about it:
http://groups.google.com/groups?selm=Pine.LNX.3. 96
Silence. No response whatsoever! I believe I even tried contacting existing developers using IRC as well, but nobody was interested in helping me get started working with the codebase, so I gave up. I simply did not have the time to read through 1,000,000 lines of code to figure out how to get started. Discouraged, I wandered away and found other things to do with my time.
A couple months later, I decided to try it anyway. I checked out all the code over CVS and tried to build it. All I remember is that the build took many hours on my (admittedly slow) computer, and many megabytes as well. Again, the code was too large and unwieldy to work with, and I gave up again.
Later, still wanting to help, I started reporting some bugs to Bugzilla. Over the years, I've participated in 3 dozen bugs, and originated over a dozen myself. The first bug I reported was bug #7617, "apprunner reformats during mouse click on or tabbing to link", reported June 4, 1999. This bug was later resolved as a "duplicate" of a newer bug, #28212, "{table-reflow} Clicking on URL dynamically resizes table cells", reported February 17, 2000.
Since well over 6 months had passed without the bug being fixed, in early 2000, I decided to try again to dig into the massive volume of Mozilla code, reasoning that tracking down a specific bug would allow me to ignore most of the code and focus on the part where the bug was being caused.
Unfortunately, the bug I chose (the first one I had reported) turned out to be incredibly difficult to track down, because the problem was buried in the incremental reflow code for HTML tables, and the rendering engine was extremely complex and little documented. Nevertheless, I spent countless hours tracking down this bug, and was actually getting close to understanding the source of the problem when I ran out of time to work on it. I returned to the problem a month or two later, but by that time, the bug had been closed as WORKSFORME, and the new nightly build wasn't exhibiting the behavior anymore.
Most likely, the bug wasn't actually fixed, but rather masked by the fix for bug #28522, "Clicking or tabbing to link causes incremental reflow". This is probably why the original bug was closed as WORKSFORME -- because nobody actually found and fixed the bug. This means that the incremental reflow bug probably still existed, and just wasn't obvious anymore. That bug may still exist today!
I wanted to go back and verify whether the bug was really fixed or not, but I never found the time and energy to expend on such an effort, when the bug was no longer being manifested as it once was. Regardless, this experience convinced me that Mozilla was too fast-m
I have a better solution. Require an exponentially-growing maintenance fee to keep patents and copyrights out of the public domain. Companies with valuable "intellectual property" can keep them as long as the fee is less than the expected benefit.
Fees should be higher and grow faster for patents than copyrights, since they're more exclusive. Eventually, the fee will be ridiculously expensive (but it's all relative), and the work will be allowed to enter the public domain where it belongs.
Copyrights should start with a free period of automatic copyright protection without registration, but require registration and fees after a year (or several) for continued protection. Modest copyright terms should be affordable to all, while excessive terms will eventually be prohibitively expensive to everyone.
This would be a fair system. The public would be increasingly compensated for the sacrifice it makes to honor the exclusive rights, while abandoned works would enter the public domain far more quickly.
Meanwhile, it would provide another revenue stream for the government that doesn't involve arbitrary taxes. Only those who feel it's in their best interest to maintain the protections would pay these fees. With "intellectual properties" that are worth hundreds of millions to billions of dollars, this could be a substantial revenue stream indeed.
Such a system would truly be in the public interest, but the content industry would abhor such a reform -- they're too used to the free ride they've had so long at the public's expense...