Russell v. Northeastern Pub. Co -- Use of the same language constitutes a derived work even with a change of context
Wouldn't "the same language" refer to copying code, rather than just conforming to an interface?
White v. Samsung Electronics -- Using original images whose ideas are taken from another work constitutes a derived work
I can't find the actual opinion in this case (only a dissent), but it appears to deal with likeness rights rather than ordinary derived works under copyright. In any case, there is a much higher need for interoperability in the software domain than in traditional copyright domains; it isn't clear that the same standards of derivation can be applied blindly.
Rogers v. Koons -- Change of medium doesn't invalidate derivative status
Writing code that conforms to an interface is not changing the medium of the interface's implementation.
The thing I really don't understand, though, is how a client of a server or library can be derived from that work merely by using the unique interface, but a re-implementation of that server or library's functionality using the same interface would not be derived from the original work for the same reasons? If a program that is written to work with Qt is derived from Qt, why wouldn't a free reimplementation of Qt be derived from Qt? Why wouldn't Linux (or BSD) be legally derived from Unix, or Compaq's BIOS be derived from IBM's?
Can you cite any court precedent or statute backing up this interpretation of what constitutes a derived work? It seems rather insane to me, especially the part about a work's derivedness changing based on the appearance of unrelated third party software (is it derived if I think such a thing will be written, or if I intend to write it in the future? If you sue me and win before the 3rd party implementation is written, can I sue once it is written for a reclamation of any damages I paid to you, since now it's not derived, and thus it was legal for me to have made and distributed it? If there is a 3rd party implementation, and I write a client that uses the interface in question, and you buy the copyright to all 3rd party implementations, does it magically become derived from all of them? What if you merely form an agreement with all of the copyright holders of the 3rd party implementations to deny me derived work rights? What if there was a BSD-licensed implementation when I wrote my client, but it got lost and the only remaining implementation is yours?), or my web browser being a derived work of your webserver because you changed it to require "GET2" instead of "GET" and I changed my browser to match without retaining the ability to send out the standard "GET" or changing a second server to accept "GET2" (but wait, wouldn't making such a change cause the second server to be derived from the first?).
I don't see where the GPL gives you permission to prepare a derivative work without causing the derivative to be released under the GPL.
Section 2 of the GPL grants the right to prepare derivative works. Clause 2b limits that by requiring "any work that you distribute or publish" to be licensed under the GPL.
Why can't the developer use whatever component she wants? The GPL doesn't restrict use.
By "use", I mean as a component of the software being developed for distribution. If a developer, for whatever reason, needs or wants to distribute under non-GPL terms, then that developer cannot include GPL components, which means that the user will not have the option of using what would have resulted if the developer were able to include those components. Thus, the user's choice of things to run is reduced because the GPL caused certain options to not be made available that might have been available had the components been under a BSD-style license.
So then if a program is written to be usable only with Windows, it's a derived work of Windows? And as such, Microsoft has substantial rights to the code if you copy it? Does code written in assembly for x86 require Intel's permission to be copied (or would it, if there were no x86 clones)?
If you write a server, and I write a client that can talk to it (and there are no other compatible servers), is my client derived from your piece of software? Does it magically cease to be a derived work if someone later writes a compatible server?
It's legal to create non-GPL derived works from GPL sources; you just can't distribute them. Thus, as long as you don't distribute a core file, running machine, or similar, you'd be fine.
The only real difference for a consumer is a trickle-down effect of the restrictions on developers; if the developer couldn't or wouldn't use a GPLed component for whatever reason, the user can't use whatever derived work would have resulted.
It's probably more indicitave of sloppy time accounting than the slowness of top or the OS, especially since top takes about the same percentage of CPU on every Mac I've tried it on (running at wildly varying speeds).
Many (most?) OSes charge time to processes statistically, by sampling which process is running at each timer interrupt. If top is being woken up at regular intervals, it may happen to show up on substantially more sample points than its actual CPU usage warrants (since the wakeup and the sample happen on the same interrupt).
The x86 OSes you used probably just do things in a different order when the interrupt comes in (and/or receive timer interrupts more frequently), so that top doesn't experience as much distortion (though other load patterns could still screw it up).
Actually, red and blue look quite distinct to the vast majority of color-blind people, even while engaged in sexual activity (unless you've got the lights off or something).
Dying at level 2 the 74th time in a row gets old (normally by starvation).
Yes, that's why one would try to figure out why one is starving, and do something about it. Such as, say, eating.:-) Most things you kill can be eaten, and if you are constantly not finding enough things to kill, you're either not looking hard enough, or not descending fast enough.
And yes, it's your own business whether you cheat in your own, single-player games. However, you'll enjoy the game much more if you learn to play it properly.
You can use the money that you save by not including obscene amounts of memory on the graphics card to increase the amount of system RAM you have; that way, you'll have as much available RAM as before when using 3D apps, and even more when not.
Furthermore, there hopefully would be some kind of user-controlled limit (as there is with AGP) on how much system memory is allowed to be used for this sort of thing. By insisting that the RAM be on the card itself, you merely take away the ability to change that limit without changing the hardware.
3) MPAA bribes ISP (or admin thereof) in Cambodia to receive
customer information
4) Your ass, which you did not move
to Cambodia, gets hauled into court.
Oh, and how many people are going to go to
the hassle and expense of setting up a server
(and getting enough international bandwidth to be worthwhile) overseas just in order to copy some movies for
free? Some, perhaps, but many wouldn't bother.
Having physical access usually means they can compromise
the local machine (though perhaps not without attracting the suspicion of others nearby, if any); it does not necessarily mean
they can compromise whatever network account,
PGP key, etc. that the post-it under the keyboard might contain
a password for.
If passwords absolutely must be written down,
a better way might be to keep half of the password
at the terminal and the other half in one's wallet, making sure that the password is long enough that neither half is easily guessable. Alternatively, rarely used passwords can be stored someplace that is protected (and preferably encrypted) by passwords which are more commonly used (and thus more easily memorized).
It isn't that difficult to create passwords (for example, by using a pronouncable-password generator, or using the initials of a long-ish phrase (or the phrase itself) that, while not as secure as line-noise-style passwords of equal length, are still substantially more secure than "12345", "letmein", or the name of the company. It helps when the system doesn't impose stupidly low maximum password lengths, of course...
I thought it was pretty obvious that the context
was the creation of ideas and other non-physical
things. Obviously a physical thing is owned
by its creator (as long as the creator owns the
materials it's made of, and hasn't made an agreement
that gives ownership to someone else); what does that have to do with
the ability of someone else to make something
that happens to be similar?
Besides, I never even claimed that "Intellectual" property is "theft", much less all property; there are situations where it is in the public good to grant such privileges. That doesn't mean, however, that one's rights are violated if such a monopoly is not granted.
If I spend time and money devloping
somthing why shouldn't I have a way to protect what I create?
The ability to protect what you create is not
a right; it is a privilege granted by the public
to the creator for a specific purpose. If the
public does not feel that a particular sort of creation
is sufficiently valuable as to warrant protection, then you don't get to protect it. Keep in mind that one of the major reasons for patents is to prevent secrecy from being used as an alternative; it's a lot harder to keep business methods secret, and thus the public is not getting as much out of granting such patents.
So I'm writting software for
buisness methods. A double whammy. According to a number of people on thee
forums I shouldn't be able to make money at what I do
You can protect the software itself with copyright. It's the methods themselves that require a patent to "protect".
Passwords? What century are you living in? If you have high speed 24x7 access to a network how long is it really going to take to run through a 16 character password guesser? A month, maybe. Then you are owned.
Even if you limit it to passwords with exactly 16 lowercase alphabetic characters, that's (26^16)/(30*24*60*60), or over 16.8 quadrillion, passwords per second. Somehow I think the guessing would be just a bit slower than that (not to mention the fact that I'd probably notice the blinking LEDs indicating constant traffic on the switch, although the average user wouldn't necessarily know what that means).
What I'd be worried about is not password guessing, but people using my connection for spamming and/or other network abuse that ends up getting traced back to my DSL line.
Nebraska and Maine divvy the votes proportionally to the popular vote.
No, they don't; they just push the winner-takes-all scheme down to the individual congressional district level. If both of Maine's districts vote 51% for Kerry, Kerry will get all 4 votes. Likewise, Nebraska's 5 votes will all go to Bush, even if 20-30% vote for Kerry, because Bush will win each district.
Those delays have always pissed me off... An automated attacker could just disconnect and reconnect rather than wait for the timeout. Even if this weren't the case, a shorter delay could be used that's just as good for stopping brute force attacks but isn't long enough for a real user to notice.
But the older ones are different patents, which cover different things. Do any of those patents which are older than, say, Debian's dselect (to which I can find usenet references as far back as 1995) cover such update mechanisms? There are too many of them to quickly check...
Re:v6 could help solve some net problems
on
IPv6 is Here
·
· Score: 1
Wouldn't DHCP still be useful for retrieving the
rest of the IP address, as well as such information
as nameservers and default router? It's just the
address leasing aspect that you wouldn't need.
Slashdot Mirror
Russell v. Northeastern Pub. Co -- Use of the same language constitutes a derived work even with a change of context
Wouldn't "the same language" refer to copying code, rather than just conforming to an interface?
White v. Samsung Electronics -- Using original images whose ideas are taken from another work constitutes a derived work
I can't find the actual opinion in this case (only a dissent), but it appears to deal with likeness rights rather than ordinary derived works under copyright. In any case, there is a much higher need for interoperability in the software domain than in traditional copyright domains; it isn't clear that the same standards of derivation can be applied blindly.
Rogers v. Koons -- Change of medium doesn't invalidate derivative status
Writing code that conforms to an interface is not changing the medium of the interface's implementation.
The thing I really don't understand, though, is how a client of a server or library can be derived from that work merely by using the unique interface, but a re-implementation of that server or library's functionality using the same interface would not be derived from the original work for the same reasons? If a program that is written to work with Qt is derived from Qt, why wouldn't a free reimplementation of Qt be derived from Qt? Why wouldn't Linux (or BSD) be legally derived from Unix, or Compaq's BIOS be derived from IBM's?
Can you cite any court precedent or statute backing up this interpretation of what constitutes a derived work? It seems rather insane to me, especially the part about a work's derivedness changing based on the appearance of unrelated third party software (is it derived if I think such a thing will be written, or if I intend to write it in the future? If you sue me and win before the 3rd party implementation is written, can I sue once it is written for a reclamation of any damages I paid to you, since now it's not derived, and thus it was legal for me to have made and distributed it? If there is a 3rd party implementation, and I write a client that uses the interface in question, and you buy the copyright to all 3rd party implementations, does it magically become derived from all of them? What if you merely form an agreement with all of the copyright holders of the 3rd party implementations to deny me derived work rights? What if there was a BSD-licensed implementation when I wrote my client, but it got lost and the only remaining implementation is yours?), or my web browser being a derived work of your webserver because you changed it to require "GET2" instead of "GET" and I changed my browser to match without retaining the ability to send out the standard "GET" or changing a second server to accept "GET2" (but wait, wouldn't making such a change cause the second server to be derived from the first?).
I don't see where the GPL gives you permission to prepare a derivative work without causing the derivative to be released under the GPL.
Section 2 of the GPL grants the right to prepare derivative works. Clause 2b limits that by requiring "any work that you distribute or publish" to be licensed under the GPL.
Why can't the developer use whatever component she wants? The GPL doesn't restrict use.
By "use", I mean as a component of the software being developed for distribution. If a developer, for whatever reason, needs or wants to distribute under non-GPL terms, then that developer cannot include GPL components, which means that the user will not have the option of using what would have resulted if the developer were able to include those components. Thus, the user's choice of things to run is reduced because the GPL caused certain options to not be made available that might have been available had the components been under a BSD-style license.
So then if a program is written to be usable only with Windows, it's a derived work of Windows? And as such, Microsoft has substantial rights to the code if you copy it? Does code written in assembly for x86 require Intel's permission to be copied (or would it, if there were no x86 clones)?
If you write a server, and I write a client that can talk to it (and there are no other compatible servers), is my client derived from your piece of software? Does it magically cease to be a derived work if someone later writes a compatible server?
It's legal to create non-GPL derived works from GPL sources; you just can't distribute them. Thus, as long as you don't distribute a core file, running machine, or similar, you'd be fine.
The only real difference for a consumer is a trickle-down effect of the restrictions on developers; if the developer couldn't or wouldn't use a GPLed component for whatever reason, the user can't use whatever derived work would have resulted.
It's probably more indicitave of sloppy time accounting than the slowness of top or the OS, especially since top takes about the same percentage of CPU on every Mac I've tried it on (running at wildly varying speeds).
Many (most?) OSes charge time to processes statistically, by sampling which process is running at each timer interrupt. If top is being woken up at regular intervals, it may happen to show up on substantially more sample points than its actual CPU usage warrants (since the wakeup and the sample happen on the same interrupt).
The x86 OSes you used probably just do things in a different order when the interrupt comes in (and/or receive timer interrupts more frequently), so that top doesn't experience as much distortion (though other load patterns could still screw it up).
Actually, red and blue look quite distinct to the vast majority of color-blind people, even while engaged in sexual activity (unless you've got the lights off or something).
Pink and purple, OTOH, can appear very similar.
Clearly, you'd be fined two million dollars for harrassing a major record label. Don't forget to use the Chewbacca defense...
The word "an" precedes vowel sounds, not letters. "X" in "XML" is pronounced "eks", and thus gets "an". Would you say "an unit"?
Dying at level 2 the 74th time in a row gets old (normally by starvation).
Yes, that's why one would try to figure out why one is starving, and do something about it. Such as, say, eating. :-) Most things you kill can be eaten, and if you are constantly not finding enough things to kill, you're either not looking hard enough, or not descending fast enough.
And yes, it's your own business whether you cheat in your own, single-player games. However, you'll enjoy the game much more if you learn to play it properly.
No, Earth's just poorly insulated.
You can use the money that you save by not including obscene amounts of memory on the graphics card to increase the amount of system RAM you have; that way, you'll have as much available RAM as before when using 3D apps, and even more when not.
Furthermore, there hopefully would be some kind of user-controlled limit (as there is with AGP) on how much system memory is allowed to be used for this sort of thing. By insisting that the RAM be on the card itself, you merely take away the ability to change that limit without changing the hardware.
3) MPAA bribes ISP (or admin thereof) in Cambodia to receive customer information
4) Your ass, which you did not move to Cambodia, gets hauled into court.
Oh, and how many people are going to go to the hassle and expense of setting up a server (and getting enough international bandwidth to be worthwhile) overseas just in order to copy some movies for free? Some, perhaps, but many wouldn't bother.
Having physical access usually means they can compromise the local machine (though perhaps not without attracting the suspicion of others nearby, if any); it does not necessarily mean they can compromise whatever network account, PGP key, etc. that the post-it under the keyboard might contain a password for.
If passwords absolutely must be written down, a better way might be to keep half of the password at the terminal and the other half in one's wallet, making sure that the password is long enough that neither half is easily guessable. Alternatively, rarely used passwords can be stored someplace that is protected (and preferably encrypted) by passwords which are more commonly used (and thus more easily memorized).
It isn't that difficult to create passwords (for example, by using a pronouncable-password generator, or using the initials of a long-ish phrase (or the phrase itself) that, while not as secure as line-noise-style passwords of equal length, are still substantially more secure than "12345", "letmein", or the name of the company. It helps when the system doesn't impose stupidly low maximum password lengths, of course...
Try here. 3dfx released a bunch of specs before they died.
I thought it was pretty obvious that the context was the creation of ideas and other non-physical things. Obviously a physical thing is owned by its creator (as long as the creator owns the materials it's made of, and hasn't made an agreement that gives ownership to someone else); what does that have to do with the ability of someone else to make something that happens to be similar?
Besides, I never even claimed that "Intellectual" property is "theft", much less all property; there are situations where it is in the public good to grant such privileges. That doesn't mean, however, that one's rights are violated if such a monopoly is not granted.
No, it's harder to keep business process ideas secret because of the way businesses work.
Uh, that's what I said. Did you mean to reply to someone else, or was there something specific in my post that you're saying "No" to?
If I spend time and money devloping somthing why shouldn't I have a way to protect what I create?
The ability to protect what you create is not a right; it is a privilege granted by the public to the creator for a specific purpose. If the public does not feel that a particular sort of creation is sufficiently valuable as to warrant protection, then you don't get to protect it. Keep in mind that one of the major reasons for patents is to prevent secrecy from being used as an alternative; it's a lot harder to keep business methods secret, and thus the public is not getting as much out of granting such patents.
So I'm writting software for buisness methods. A double whammy. According to a number of people on thee forums I shouldn't be able to make money at what I do
You can protect the software itself with copyright. It's the methods themselves that require a patent to "protect".
Even if you limit it to passwords with exactly 16 lowercase alphabetic characters, that's (26^16)/(30*24*60*60), or over 16.8 quadrillion, passwords per second. Somehow I think the guessing would be just a bit slower than that (not to mention the fact that I'd probably notice the blinking LEDs indicating constant traffic on the switch, although the average user wouldn't necessarily know what that means).
What I'd be worried about is not password guessing, but people using my connection for spamming and/or other network abuse that ends up getting traced back to my DSL line.
No, they don't; they just push the winner-takes-all scheme down to the individual congressional district level. If both of Maine's districts vote 51% for Kerry, Kerry will get all 4 votes. Likewise, Nebraska's 5 votes will all go to Bush, even if 20-30% vote for Kerry, because Bush will win each district.
Ye is plural as well, but is the subjective (rather than objective) pronoun. The singulars were thou (subjective) and thee (objective).
Those delays have always pissed me off... An automated attacker could just disconnect and reconnect rather than wait for the timeout. Even if this weren't the case, a shorter delay could be used that's just as good for stopping brute force attacks but isn't long enough for a real user to notice.
It's the default /bin/sh on recent versions of MacOS X
as well.
But the older ones are different patents, which cover different things. Do any of those patents which are older than, say, Debian's dselect (to which I can find usenet references as far back as 1995) cover such update mechanisms? There are too many of them to quickly check...
Wouldn't DHCP still be useful for retrieving the rest of the IP address, as well as such information as nameservers and default router? It's just the address leasing aspect that you wouldn't need.