In the US, to claim a copyright on a derivative work, the work must have substantive changes. Reformatting does not count as substantive, nor is transferring to a new medium.
If this had happened in the US, for sure, he wouldn't actually have a new copyright.
Yeah, but when it's a publicly traded company, you really need to focus your hate on the people who sell the stock at the slightest hint that the company won't be making those absurd profits in the near future. That's the reason that the corporate bigwigs whine--their value is dependant solely upon the speculation that they'll make more money this year than last year, since stock traders will dump the stock if they don't.
It's a terrible system that leads to inflation of the company's actual worth, and the need for short-term profits over long-term goals.
His argument that you can game the license by licensing the work, then revoking the license doesn't hold either. Once the work has been licensed under Creative Commons, the license is good indefinitely so long as its terms are met. You could decide to license the work under other terms later, of course, but the Creative Commons license would persist (you can't alter the terms after the terms are agreed upon and accepted by both parties). In the case of most of the licenses, you couldn't effectively terminate the licenses either. Once you've given permission for others to distribute a work under the same license terms, you've effectively passed on the authority to license the work under those terms. Even if you don't want to distribute the work under a CC license anymore, you've already granted the right for others to do so and can't revoke that right until they violate the terms of the license. Of course, how do you prove that the work was ever CC? Print out the web-page proving it? It can be faked.
Again, though, this isn't a problem specifically with CC licenses. It's a general problem with trying to apply contract law in this manner--where the parties never actually form an agreement and sign it.
Actually, one could argue that it increases the daemon's surface area. Instead of 1 port, 3 ports now forward to the listening service. Although a connection to a non-listening port will trigger a blacklist of the remote IP address, the same could be done with just one listening port.
Of course, since the port changes every minute, that gives very little time for the attacker to crack it before he has to find a new port. Nonetheless, if you're relying on this for security, it seems like a pretty bad idea. It's a lot of work to thwart a brute-force attempt, when using keys will work better.
It's not really a private key--at least, not in the same way that SSH public/private keys are used. Generally speaking, you don't transmit your private key all over the internet when you want to use it.
This secret doesn't have all of the properties of a password, though.
At the very least, it's shared. This makes it unsuitable for use on a multi-user system, but if that's ok with you, then fine. It also, ultimately, hashes down to a pretty small set of values (ports). All this to... what? Prevent logs from being filled with failed connection attempts? Protect your server against brute-force attacks? There are better ways to handle both of these problems.
Generally speaking, security through obscurity means that knowing the inner workings of the security system gives a hacker enough information to let said hacker in without much trouble. The common example is a case where knowing the algorithm is enough to let you in--if the hacker knows the algorithm, either through a corporate leak or by reverse engineering the software, then the system is said to be using security through obscurity.
Non-obscurity based security systems often have open algorithms--the user has a secret of some sort which he uses to authenticate himself to the system. It's perfectly true that the secret could be guessed or compromised, but this is true of nearly every security system on Earth. The simple point is that the system isn't relying on secrecy of the workings of the system itself.
It's entirely possible for a system which relies on security through obscurity to be more secure than an open system which relies on a secret. A black box with a chip and leads sealed in epoxy is unlikely to be hacked. A password system which requires that passwords be dictionary words will be hacked rather quickly. Yet the former is still security through obscurity (albeit with a layer of physical security which makes it harder to find the obscure component), and the latter still relies only on a mapping of a username and a secret.
The system described in the article really straddles the line, but not because the port is easily guessed. The obscurity portion of the system is in the fact that a single, shared secret is used (a secret which might be leaked and compromising the security of the whole system.) Shared secrets are fine when used to salt an actual authentication secret, but they're only barely better than worthless when used as the sole authenticator for a particular layer of your security model.
Frankly, the person who came up with this system was probably trying to avoid the rampant SSH brute-force attacks which clutter up all of our logs. There are much better ways of handling this, in my opinion.
Port knocking is neat, but it suffers from sniffing attacks. Anyone who can sniff the connection can determine the sequence being used. You can use something like one time passwords to make a new set of sequences each time, but then you have to calculate those sequences (one of the neat things about port knocking is that you can do it from pretty much any machine--not just one with a special client.)
Honestly, people spend way too much time worrying about hiding their SSH ports. Use public key authentication and disable password authentication, and no one's going to brute-force their way in.
Blu-ray has a lot going for it. Everyone who bought a PS3 assuming that it would be the best console ever got a Blu-ray player. Blu-ray has also been marketed like nobody's business, and it got Disney as a backer.
From a production studio perspective, it has better DRM. HD-DVD DRM was cracked pretty early on, and I bet that caused studio execs to wet their pants. Blu-ray (and BD+) were cracked later, but firsts often matter more.
HD-DVD has... very little to compete with Blu-ray. Independent examinations have shown slight quality differences favoring HD-DVD for films released in both formats, though there's no technical reason that this must be the case. They've also got pricing--HD-DVD players are cheaper than Blu-ray. Generally speaking, though, that's not going to matter much. The studios are going to do what they want, and they want draconian, difficult-to-break DRM.
Re:Morals aside - what's the end result?
on
Sony BMG Dropping DRM
·
· Score: 5, Insightful
But watching the films and listening to the music anyway just says you want the stuff but aren't willing to pay for it like everyone else. Well...yeah.
Here's the thing: copyright is a balance between the insanity of allowing ideas to be owned, and the insanity of few people creating art because we need to eat. To maintain that balance, the government (the people) struck a deal with content creators--they get a limited monopoly on their work in exchange for creating it in the first place. But eventually, the people get the work, as they should, because owning ideas is idiotic.
Unfortunately, the content creators don't feel the need to honor the deal--they just want to own the ideas outright, forever and ever. I don't particularly blame them--everyone's always looking out for number 1--but the fact remains that they're violating it every time they ask for extensions.
It's not unreasonabe to wonder why one side should agree to a deal that the other side is violating.
The key is that it has nothing to do with the content. A boycott is generally useful for when you don't like what someone is saying, or even how they're saying it. Copyright is a weird beast that really doesn't fall into either of these areas.
More likely, Fox will include "iTunes" versions of movies on their DVDs which can be imported. They'll probably use the same encryption that downloaded movies use to prevent them from being used in a non-authorized manner.
Look, his choices are not streaming Netflix because Vista, Netflix, and Unbox don't mix, or not streaming Netflix because Linux isn't supported. OS choice really isn't significant, here.
But that's not what they really want, is it? They want to be left alone. They want the US out of the Middle East. The US has stayed in the Middle East throughout all of this.
Don't believe the rhetoric. Al Qaeda does not hate our freedoms--they hate our meddling.
Point 2 is going to be hard to deal with. Generally speaking, statuatory damages are useful for discouraging infringement. If the cost to infringe is nothing more than the cost of the media, it never makes sense to buy the media. Worst case scenario, you end up paying for it, but best case, you get it for free. I think that the current statuatory damages are pretty obscene, though.
Point 3 will never happen in a million years, but it's a nice thought:)
Because if I give something away, that gives me the right to control the copyright forever? How would that be a beneficial law? It simply means you control into perpetuity who gets to use your work, and upon your death, that copyright devolves to your heirs, who may either completely disagree with what you believed, or who decide that they want to sell the copyright to someone else who then controls the work and can do with it what they will, including rescinding the free-as-in-speech part and charging everybody for the continued use of the work. Licenses like the GPL don't allow this. Perhaps I should have said perpetuous copyright for copylefted works?
I'd say that it should start when it is first published in any way. For software, each version would be a different copyright, so if you release a Beta, that copyright would expire before the copyright on 1.0 (though semantically, it may not be significantly different.)
That might work out. I'd expect to see pretty draconian licensing terms, though. With the right contract, Disney could get irrevocable rights to the work for the length of the author's life. They might even try to make the rights exclusive, and get the artist to agree to not publish his own work for the duration of the contract, effectively turning it into the system we currently have, now with added bureaucracy!
1. Funny, I don't remember corporate copyrights being part of international copyright law... I don't think that the Berne convention specifies either way for photographs or movies. For audio recordings, the requirement is "life of the author plus 50 years." For movies, it's 50 years after the first showing, and for photographs, it's 25 years after the photo is taken.
These are minimums, of course. In the US, I believe all copyright is for the same length of time--life of author, plus 50 years.
You can incorporate and then license your personal copyright to your company. So...Disney could license their animators' work for the length of the personal copyright?
There's a pretty good reason to let individuals have longer copyrights--they're less able to make money quickly from their work. Any given production studio probably makes 95% of their profits from a film within the first 5 years of its release (theatrical runs, initial DVD release, special edition DVD release.) An individual who is trying to market it without the help of a corporation will likely need to rely heavily on word-of-mouth advertising, which will be slower than a nationwide advertising campaign.
I'd be pretty happy with 5 years for corporations, 10 years for individuals, each with the option to renew for one more term. If you can't recoup your investment within this time frame, you don't need to be in this business.
Of course, I'd also like to see perpetual copyrights for free-as-in-speech works, but that's probably too much to ask.
I have to disagree.
If what you say is true, then NO open source software will EVER get past being a standalone package. Well, if you took my statements to an extreme, sure. You're suggesting that my statements were about every piece of FOSS. I said "many," not "all."
The concept of stringing pieces together is usually best explained on the command line with pipes/shell scripting, but it also applies to the use of libraries (which is not a concept unique to Unix/open source.) Most of the common command line utilities conform to the POSIX specification, sometimes with non-standard extensions. Most people use the standard features. Some rely on non-standard ones, and their applications break when ported to a system which has a different implementation (going to a BSD comes to mind, as they do not tend to ship with the GNU versions of these tools.)
Libraries tend to be more stable--or more specifically, they tend to only add interfaces. It's pretty rare that changes in a FOSS library will break the applications that depend upon it. Whether this is because the developers understand software development or just because they tend only to add functionality, I really can't say.
Mostly, I'm talking about end-applications that aren't complying to some standard. I've upgraded FOSS in the past to find that it did not, in fact, work as it previously did. My choices were to live with a buffer overflow or no longer use the software (or, in some cases, adapt to the change, though changing up the UI in a point release isn't a good idea, either.)
That's not to say that FOSS Is the only software susceptible to this. The latest Opera beta changed a lot of keybindings and functionality. Then again, it's a beta, so I guess it's only to be expected.
Perl is an interpreted language--nothing more, nothing less. There's nothing magical about it that requires Unix.
Now things like printing and reading (stdout and stdin) need something to connect to, but all of that is pretty abstract. Perl runs just fine on a Windows command prompt, although certain things don't function exactly like their Unix equivalents (fork() comes to mind.) What matters is that the person who implements the Perl interpreter on the OS does sane things. unlink() for example, needs to call the Windows equivalent system call.
I imagine that the thought being put forth is that without the ability to make money from software, investors are unlikely to pay for someone to create GPL software. Without that ability, it's hard to get someone with vision to step up and say, "Hey, this is the direction we're going, here's a release schedule, here's our target market, etc." Innovation won't occur--instead, OSS will just copy the competition.
I think there's some merit to the idea. Many open source projects don't have a concept of a development cycle. They do awful things like mixing security patches and new features (rather than having a separate security branch that can be tracked.) The products are often constantly evolving and changing functionality, even in minor releases. It's really quite a mess.
If the projects were more thought out, planned from the beginning with target features for the specific release, and with security fixes released for that milestone without having to add new (and potentially buggy) features, I think that the world of FOSS would be a much better place.
Slashdot Mirror
In the US, to claim a copyright on a derivative work, the work must have substantive changes. Reformatting does not count as substantive, nor is transferring to a new medium.
If this had happened in the US, for sure, he wouldn't actually have a new copyright.
Yeah, but when it's a publicly traded company, you really need to focus your hate on the people who sell the stock at the slightest hint that the company won't be making those absurd profits in the near future. That's the reason that the corporate bigwigs whine--their value is dependant solely upon the speculation that they'll make more money this year than last year, since stock traders will dump the stock if they don't.
It's a terrible system that leads to inflation of the company's actual worth, and the need for short-term profits over long-term goals.
Yeah, and you pray that they don't find it. I'm pretty sure that if they did, you'd be in for a lot of "scrutiny."
Again, though, this isn't a problem specifically with CC licenses. It's a general problem with trying to apply contract law in this manner--where the parties never actually form an agreement and sign it.
Actually, one could argue that it increases the daemon's surface area. Instead of 1 port, 3 ports now forward to the listening service. Although a connection to a non-listening port will trigger a blacklist of the remote IP address, the same could be done with just one listening port.
Of course, since the port changes every minute, that gives very little time for the attacker to crack it before he has to find a new port. Nonetheless, if you're relying on this for security, it seems like a pretty bad idea. It's a lot of work to thwart a brute-force attempt, when using keys will work better.
Neat idea, but impractical.
It's not really a private key--at least, not in the same way that SSH public/private keys are used. Generally speaking, you don't transmit your private key all over the internet when you want to use it.
This secret doesn't have all of the properties of a password, though.
... what? Prevent logs from being filled with failed connection attempts? Protect your server against brute-force attacks? There are better ways to handle both of these problems.
At the very least, it's shared. This makes it unsuitable for use on a multi-user system, but if that's ok with you, then fine. It also, ultimately, hashes down to a pretty small set of values (ports). All this to
Yeah, because no hackers have entire networks of zombie computers at their disposal.
Generally speaking, security through obscurity means that knowing the inner workings of the security system gives a hacker enough information to let said hacker in without much trouble. The common example is a case where knowing the algorithm is enough to let you in--if the hacker knows the algorithm, either through a corporate leak or by reverse engineering the software, then the system is said to be using security through obscurity.
Non-obscurity based security systems often have open algorithms--the user has a secret of some sort which he uses to authenticate himself to the system. It's perfectly true that the secret could be guessed or compromised, but this is true of nearly every security system on Earth. The simple point is that the system isn't relying on secrecy of the workings of the system itself.
It's entirely possible for a system which relies on security through obscurity to be more secure than an open system which relies on a secret. A black box with a chip and leads sealed in epoxy is unlikely to be hacked. A password system which requires that passwords be dictionary words will be hacked rather quickly. Yet the former is still security through obscurity (albeit with a layer of physical security which makes it harder to find the obscure component), and the latter still relies only on a mapping of a username and a secret.
The system described in the article really straddles the line, but not because the port is easily guessed. The obscurity portion of the system is in the fact that a single, shared secret is used (a secret which might be leaked and compromising the security of the whole system.) Shared secrets are fine when used to salt an actual authentication secret, but they're only barely better than worthless when used as the sole authenticator for a particular layer of your security model.
Frankly, the person who came up with this system was probably trying to avoid the rampant SSH brute-force attacks which clutter up all of our logs. There are much better ways of handling this, in my opinion.
Port knocking is neat, but it suffers from sniffing attacks. Anyone who can sniff the connection can determine the sequence being used. You can use something like one time passwords to make a new set of sequences each time, but then you have to calculate those sequences (one of the neat things about port knocking is that you can do it from pretty much any machine--not just one with a special client.)
Honestly, people spend way too much time worrying about hiding their SSH ports. Use public key authentication and disable password authentication, and no one's going to brute-force their way in.
Blu-ray has a lot going for it. Everyone who bought a PS3 assuming that it would be the best console ever got a Blu-ray player. Blu-ray has also been marketed like nobody's business, and it got Disney as a backer.
From a production studio perspective, it has better DRM. HD-DVD DRM was cracked pretty early on, and I bet that caused studio execs to wet their pants. Blu-ray (and BD+) were cracked later, but firsts often matter more.
HD-DVD has... very little to compete with Blu-ray. Independent examinations have shown slight quality differences favoring HD-DVD for films released in both formats, though there's no technical reason that this must be the case. They've also got pricing--HD-DVD players are cheaper than Blu-ray. Generally speaking, though, that's not going to matter much. The studios are going to do what they want, and they want draconian, difficult-to-break DRM.
Here's the thing: copyright is a balance between the insanity of allowing ideas to be owned, and the insanity of few people creating art because we need to eat. To maintain that balance, the government (the people) struck a deal with content creators--they get a limited monopoly on their work in exchange for creating it in the first place. But eventually, the people get the work, as they should, because owning ideas is idiotic.
Unfortunately, the content creators don't feel the need to honor the deal--they just want to own the ideas outright, forever and ever. I don't particularly blame them--everyone's always looking out for number 1--but the fact remains that they're violating it every time they ask for extensions.
It's not unreasonabe to wonder why one side should agree to a deal that the other side is violating.
The key is that it has nothing to do with the content. A boycott is generally useful for when you don't like what someone is saying, or even how they're saying it. Copyright is a weird beast that really doesn't fall into either of these areas.
More likely, Fox will include "iTunes" versions of movies on their DVDs which can be imported. They'll probably use the same encryption that downloaded movies use to prevent them from being used in a non-authorized manner.
Look, his choices are not streaming Netflix because Vista, Netflix, and Unbox don't mix, or not streaming Netflix because Linux isn't supported. OS choice really isn't significant, here.
But that's not what they really want, is it? They want to be left alone. They want the US out of the Middle East. The US has stayed in the Middle East throughout all of this.
Don't believe the rhetoric. Al Qaeda does not hate our freedoms--they hate our meddling.
Point 1 is ok (though the word is "hire.")
:)
Point 2 is going to be hard to deal with. Generally speaking, statuatory damages are useful for discouraging infringement. If the cost to infringe is nothing more than the cost of the media, it never makes sense to buy the media. Worst case scenario, you end up paying for it, but best case, you get it for free. I think that the current statuatory damages are pretty obscene, though.
Point 3 will never happen in a million years, but it's a nice thought
I'd say that it should start when it is first published in any way. For software, each version would be a different copyright, so if you release a Beta, that copyright would expire before the copyright on 1.0 (though semantically, it may not be significantly different.)
That might work out. I'd expect to see pretty draconian licensing terms, though. With the right contract, Disney could get irrevocable rights to the work for the length of the author's life. They might even try to make the rights exclusive, and get the artist to agree to not publish his own work for the duration of the contract, effectively turning it into the system we currently have, now with added bureaucracy!
These are minimums, of course. In the US, I believe all copyright is for the same length of time--life of author, plus 50 years.
Sounds like a big loophole.
There's a pretty good reason to let individuals have longer copyrights--they're less able to make money quickly from their work. Any given production studio probably makes 95% of their profits from a film within the first 5 years of its release (theatrical runs, initial DVD release, special edition DVD release.) An individual who is trying to market it without the help of a corporation will likely need to rely heavily on word-of-mouth advertising, which will be slower than a nationwide advertising campaign.
I'd be pretty happy with 5 years for corporations, 10 years for individuals, each with the option to renew for one more term. If you can't recoup your investment within this time frame, you don't need to be in this business.
Of course, I'd also like to see perpetual copyrights for free-as-in-speech works, but that's probably too much to ask.
The concept of stringing pieces together is usually best explained on the command line with pipes/shell scripting, but it also applies to the use of libraries (which is not a concept unique to Unix/open source.) Most of the common command line utilities conform to the POSIX specification, sometimes with non-standard extensions. Most people use the standard features. Some rely on non-standard ones, and their applications break when ported to a system which has a different implementation (going to a BSD comes to mind, as they do not tend to ship with the GNU versions of these tools.)
Libraries tend to be more stable--or more specifically, they tend to only add interfaces. It's pretty rare that changes in a FOSS library will break the applications that depend upon it. Whether this is because the developers understand software development or just because they tend only to add functionality, I really can't say.
Mostly, I'm talking about end-applications that aren't complying to some standard. I've upgraded FOSS in the past to find that it did not, in fact, work as it previously did. My choices were to live with a buffer overflow or no longer use the software (or, in some cases, adapt to the change, though changing up the UI in a point release isn't a good idea, either.)
That's not to say that FOSS Is the only software susceptible to this. The latest Opera beta changed a lot of keybindings and functionality. Then again, it's a beta, so I guess it's only to be expected.
Perl is an interpreted language--nothing more, nothing less. There's nothing magical about it that requires Unix.
Now things like printing and reading (stdout and stdin) need something to connect to, but all of that is pretty abstract. Perl runs just fine on a Windows command prompt, although certain things don't function exactly like their Unix equivalents (fork() comes to mind.) What matters is that the person who implements the Perl interpreter on the OS does sane things. unlink() for example, needs to call the Windows equivalent system call.
I imagine that the thought being put forth is that without the ability to make money from software, investors are unlikely to pay for someone to create GPL software. Without that ability, it's hard to get someone with vision to step up and say, "Hey, this is the direction we're going, here's a release schedule, here's our target market, etc." Innovation won't occur--instead, OSS will just copy the competition.
I think there's some merit to the idea. Many open source projects don't have a concept of a development cycle. They do awful things like mixing security patches and new features (rather than having a separate security branch that can be tracked.) The products are often constantly evolving and changing functionality, even in minor releases. It's really quite a mess.
If the projects were more thought out, planned from the beginning with target features for the specific release, and with security fixes released for that milestone without having to add new (and potentially buggy) features, I think that the world of FOSS would be a much better place.