To have any kind of legal defensive as to why you are not liable, you'll need to have evidence that the user waived it anyway. If you allow for any method where the user can use your product without accepting, then that is a flaw of yours and you should still be liable.
This seems to be the crux of the problem right here. The burden should be on the consumer of software to show that there was some agreement gauranteeing that it was "safe" for them to run the software on their machine. Without such an agreement, it's their problem for even thinking about running the software.
This whole "default liability" and changing liability with licenses thing is BS. Default laibilities should be the lowest level that exist, any agreement should only increase liability on the side writing the document. Anything else is in an invitation to be eaten alive in legal red tape.
If software really were Free (as in speech) and open, then the GPL license (along with all other software licenses) would become invalid.
That said, the GPL does seem to push openness, fully using the "evils" of software licensing. I don't see how click-through can be any worse than language already accepted for "open" licenses. Still, it leaves a bad taste in the mouth. Some precedents blatently suck.
Personally I'll be flogging the public domain and sensible copyright over licensing in software for a long time to come.
Actually the very first section Ars has on Navigator looks like this:
Overall, it's a decent browser interface that has a clunky, unfinished feel to it. Ideally, a browser should be transparent - you want the program to operate so smoothly and so intuitively that you no longer notice the program itself, only the content you receive through it. Navigator does not reach this goal.
This doesn't say a thing about windows UI compliance. Last I checked, smoothly and intuitively weren't synonymous with "windows GUI". It's only later in the article that Kurt and Aeirould take the following stab at Navigator:
For some spectators, this is yet another example of how cross-platform ideals don't always play out in practice: a Windows application should have Windows' look and feel
Nowhere does it say not conforming to windows is a "sin". The point was, skinning and cross platform apps make a lot of promises, but they fail to deliver time and again. Pick your promise: Smooth and easy to use interface, or Ability to "fit in" on all (any) platforms as well as native apps. Neither one has been met by mozilla.
For the record, I'm running version 1.0 of mozilla and if I use it for more than 3 days strait on win2k with the "modern" theme I always experience the bug I've mentioned here at least once. (I'll be updating to 1.1 soon to see if that helps, but I'm doubtful.)
I'll give 1.1 a try, and I'll also give Kmeleon another try. I've been told this bug doesn't exist in 1.0. However, it and similar problems relating to keyboard/mouse focus, have existed to varying degrees in every version of mozilla I've ever used (which includes a lot of nightly builds).
I have yet to see a valid bug be ignored on Bugzilla, marked duplicate, yes, assigned to someone who is overloaded and can't handle the bug, yes, get lost in a long flame war, yes, but ignored, no.
I should have stated my point better. This was one that's been repeatedly turned into a flame war and marked as duplicate, or maked fixed when it wasn't. I've even tried to get involved with reporting on it, but each time I get disgusted and go use IE for another week. It just shouldn't be that tough to code a working address bar and the dancing around it really gets my goat.
I suppose the real solution would be to get involved with coding and fix the darn address bar myself since I seem to be one of the very few people able to reproduce these bugs on a consistent basis.
As far as the UI being ghastly, well I have trouble seeing that
I run mozilla 1.0 on win2k with the "modern" theme. 20% of the time when I start up mozilla and begin typing in the address bar the cursor just dies and nothing but a mozilla restart will allow me to type in the address bar.
This certainly fits my definition of "Ghastly" and is what keeps me using IE on windows instead of the more script-friendly mozilla.
The ratio goes up to 60% when I use the Lo-Fi mozilla theme, which happens to be my favorite, looks wise.
There are a couple conclusions here: 1) Skinning is really tough to do right, and has little benefit even when it works. 2) It's so difficult to write a decent XUL skin that even the XUL developers can't get their examples right.
The fact this and similar bugs get repeatedly ignored on bugzilla doesn't help matters either.
even a complete dumbass script kiddie...can't write code to interoperate with an established MPAA data format
Point was: He was a teenager (normally tough to prosecute). He was Norwegian (DMCA doesn't exist in Norway). He wrote the code. The code became illegal to distribute. He *still* came under legal fire.
I guess it didn't matter that the code didn't break any copyright or patent laws and was a first step in writing "interoperable" products.
So, we're left with a question. Who's allowed to interoperate, and who's not? Obviously Norwegian teenagers fall into the "who's not" category, at least in practice. The fact none of this even gets mentioned by legislators just underlines how foolish it would be to think these ammendments to UCITA actually mean anything.
Didn't the DMCA have some provisions that said it wasn't supposed to hurt interoperability?
We see just how much a provision like that really means when even a Norwegian teenager can't write code to interoperate with an established MPAA data format...
The problem with democracy is that democracy has to tolerate all oppinions and treat them in the same way.
How does "tolerance" fit in here? A Rebuplic may have rules about how individuals should be treated, but a Democracy is merely the will of the many. In a democracy if 51% of people vote to "kill all the Jews" that's exactly what happens.
Perhaps Turkey would swallow "democracy" better if we didn't try to shove our neo Darwinist-Christian laws and values down their throats? It took over 100 years to give up slavery, and the vote to women in this country. I expect some similar difficulties getting Muslim countries to "catch up".
Well, actually it does in a sence make it right if he is there by his own free will or as a consequence of a crime he has commited...
Exactly. It may or may not be right to kill the gladiator, but voting certainly doesn't effect that distinction...
I Particularly appreciate a headline sharing the page with this one on the MIT site called "When Patenting Works". This little ditty celebrates the fact a company called Intergraph was able to wipe the courtroom floor with Intel using "possibly invalid" patent claims.
Somehow I think these MIT guys are just missing the point...
Actuallly we seem to be moving more and more towards a strait democracy, which hasn't been shown to work as a form of government and is probably a lot scarier than technology...
Just cause 85% of people shout "kill him" at the gladiator, doesn't make it right.
XML is to the presentation layer as TCP is to the session layer. It strikes me that XML isn't the end all be all (just as TCP isn't) of its layer. However, it is a very compelling implementation against which all other implemenations can be measured. I expect great strides in the presentation layer in the next few years primarily because of XML.
This automatically allowed for sessions
Which is what I thought TCP was all about... though there is overhead of course.
it supported asynchronious request-reply paradigm... (think of RPC, for example)
I didn't manage to get through the whole specification, but this did seem to be one of the useful things in there... Of course, how useful is this really? It might be somewhat nice to have a tool I can use in my application to create an RPC mechanisms or the like, but what I'd much rather have is an RPC mechanim already built for me. (Like RMI in Java for example)
Don't get me wrong, BEEP will probably be useful in some applications, but I don't expect it to become a "canonical" implementation like XML or TCP.
Basically, I see a need for some level of tools to help in creating generalized TCP application protocols. In fact every TCP programmer I've met that does this for any length of time has created (or modified) their own toolset for this end. The problem with BEEP seems to be that it is a little too heavy and complex for many simpler applications. Also, the application protocol programmer, usually spends a lot more time writing code to communicate with legacy systems then coding new application protocols. I don't see a lot of functionality in BEEP for dealing with legacy issues.
There is a REASON that the Internet is based on IP
Amen Brother!
I should point out for those that might've missed your point that TCP, UDP, and GRE are all "session" layer protocols, which are lower level than application, but still we don't have *just one* of them. So why should there be *just one* application layer?
What's missing from this conversation is the presentation layer. IMHO, this is what XML is all about. Of course, what I think is really missing in industry is a new layer between presentation and application that all of us can ignore as we begin to focus on the presentation layer...
Isn't this why UDP and other protocols exist on top of IP (or other routing layers). So you can forgo the overhead that a fancy session layer (like TCP) incurs.
It seems to me that most of these new protocols are just trying to get a free ride through existing firewalls... Why can't we all just use IP the way it was meant to be used? (and move to v6 to alleviate addressing pinches)
No by definition the aplication layer protocol provides the application with access to the network stack through an API.
Um... You remember what API stands for right? That'd be "Advanced Programming Interface" or some variation. If you'd ever had to code using one of these, particularly a "new" one, you'd realize that "Interface" is a very relative term.
So, is it easier to just use sockets as your application's API to the network? In many cases yes... Interestingly enough, TCP already provides multiple streams of cummincation, and port numbers are supposed to tell you how to behave when listening or connecting. Adding another layer on top of this to do essentailly the same thing seems redundant. The only benefit I can see to this might be effects on performance(for wireless) or the ability to "sneak through" firewalls. But at what cost complexity and efficiency?
That said, if anyone ever comes up with a useful presentation layer, I'd be happy to give it a whirl. (XML has been kind of fun that way...)
by "pirating" it, you are proving that it is useful
Of course it's useful, just like a free alternative is (hopefully) useful. It just isn't useful enough to justify the price tag. Choosing a cheaper alternative sends a clear message to lower the price. "Pirating" sends a clear message asking for better copyright enforcement.
So the reason why software developers are chasing pirates is so that they can lower prices?
Don't buy the BS from either side. Software developers (like this Mr. Vold) charge money for what they create because like everyone else they must eat, but would like to do what they love (create software) to fill their needs. Large corporations(and governments?) are a different sort of entity. I don't think I need to go into what they care about or how far they will go...
Personally, my feeling is if you're going to charge big $$$ for a stream of bits, your support and other benefits should be good enough that piracy can never truly devalue what you sell. If you're selling to tons of people for low prices, there should still be that "something extra" between what you offer and warez. If you're missing that "something extra" prepare for a difficult time staying in business.
That said, speaking as a developer for a small company: I'd still throw the book (minus the DMCA) at anyone I might catch infringing our software. We've spent a lot of time and money on development effort, and the law currently says we control who has rights to own "a copy" and what price they will pay. Just don't expect me to make any corollaries with murder on the high seas, burning houses, or physical theft.
Bottom Line: Intellectual property is different than physical property but has meaning nonetheless. Further, information will eventually be free, or people won't be. The equation is that simple. History will decide the rest.
Good point, even with the friendliest license, things can always be changed after the fact. Especially in this legal climate.
I should be able to toss my own code easily into the public domain and it should be safe for everyone to use with no fear of lawyerly retribution. Anything less is a failure in education and our legal system, not a lack of certifications. (Main problem being that copyright rather than requiring application is now default...)
You want to fight the corporate abuse of copyright? Go GPL.
You want to maximize usability for everyone? Go BSD or public domain.
Every time someone has to change some code, you've just forced them to double their workload, and change some comments too.
Just think of all that time wasted finding requirements and writing specifications before coding can even begin!! Who can function with such a multiplied workload.
I wholeheartedly agree! Having to dredge through a few difficult functions doesn't take that much time. By contrast, trying to figure out what 50,000 functions do in a million line program can drive a developer (or maintainer) insane! Especially if only 10,000 functions do anything useful.
That said, every rule needs some limits. I've also waded through functions that required 4 source files (due to 32k compiler limits) and been ready to commit great voilence afterwards.
I find that combining your rule of functions matching abstractions with an effort to reduce total code size works the best for me. My guiding princible is this: "Will the next person to see this line of code, program, etc be glad it exists, or wish it didn't."
Having trouble reading your code? It's probably a better idea to break your code up into functions that are likely to be useful in more than one place. Instead of just breaking them up because they are too long.
If this doesn't seem to work for you, I'd have to see some specific examples...
Slashdot Mirror
To have any kind of legal defensive as to why you are not liable, you'll need to have evidence that the user waived it anyway. If you allow for any method where the user can use your product without accepting, then that is a flaw of yours and you should still be liable.
This seems to be the crux of the problem right here. The burden should be on the consumer of software to show that there was some agreement gauranteeing that it was "safe" for them to run the software on their machine. Without such an agreement, it's their problem for even thinking about running the software.
This whole "default liability" and changing liability with licenses thing is BS. Default laibilities should be the lowest level that exist, any agreement should only increase liability on the side writing the document. Anything else is in an invitation to be eaten alive in legal red tape.
You think I'm liable? Prove it.
If software really were Free (as in speech) and open, then the GPL license (along with all other software licenses) would become invalid.
That said, the GPL does seem to push openness, fully using the "evils" of software licensing. I don't see how click-through can be any worse than language already accepted for "open" licenses. Still, it leaves a bad taste in the mouth. Some precedents blatently suck.
Personally I'll be flogging the public domain and sensible copyright over licensing in software for a long time to come.
Actually the very first section Ars has on Navigator looks like this:
Overall, it's a decent browser interface that has a clunky, unfinished feel to it. Ideally, a browser should be transparent - you want the program to operate so smoothly and so intuitively that you no longer notice the program itself, only the content you receive through it. Navigator does not reach this goal.
This doesn't say a thing about windows UI compliance. Last I checked, smoothly and intuitively weren't synonymous with "windows GUI". It's only later in the article that Kurt and Aeirould take the following stab at Navigator:
For some spectators, this is yet another example of how cross-platform ideals don't always play out in practice: a Windows application should have Windows' look and feel
Nowhere does it say not conforming to windows is a "sin". The point was, skinning and cross platform apps make a lot of promises, but they fail to deliver time and again. Pick your promise: Smooth and easy to use interface, or Ability to "fit in" on all (any) platforms as well as native apps. Neither one has been met by mozilla.
For the record, I'm running version 1.0 of mozilla and if I use it for more than 3 days strait on win2k with the "modern" theme I always experience the bug I've mentioned here at least once. (I'll be updating to 1.1 soon to see if that helps, but I'm doubtful.)
I'll give 1.1 a try, and I'll also give Kmeleon another try. I've been told this bug doesn't exist in 1.0. However, it and similar problems relating to keyboard/mouse focus, have existed to varying degrees in every version of mozilla I've ever used (which includes a lot of nightly builds).
I have yet to see a valid bug be ignored on Bugzilla, marked duplicate, yes, assigned to someone who is overloaded and can't handle the bug, yes, get lost in a long flame war, yes, but ignored, no.
I should have stated my point better. This was one that's been repeatedly turned into a flame war and marked as duplicate, or maked fixed when it wasn't. I've even tried to get involved with reporting on it, but each time I get disgusted and go use IE for another week. It just shouldn't be that tough to code a working address bar and the dancing around it really gets my goat.
I suppose the real solution would be to get involved with coding and fix the darn address bar myself since I seem to be one of the very few people able to reproduce these bugs on a consistent basis.
nuff said.
As far as the UI being ghastly, well I have trouble seeing that
I run mozilla 1.0 on win2k with the "modern" theme. 20% of the time when I start up mozilla and begin typing in the address bar the cursor just dies and nothing but a mozilla restart will allow me to type in the address bar.
This certainly fits my definition of "Ghastly" and is what keeps me using IE on windows instead of the more script-friendly mozilla.
The ratio goes up to 60% when I use the Lo-Fi mozilla theme, which happens to be my favorite, looks wise.
There are a couple conclusions here:
1) Skinning is really tough to do right, and has little benefit even when it works.
2) It's so difficult to write a decent XUL skin that even the XUL developers can't get their examples right.
The fact this and similar bugs get repeatedly ignored on bugzilla doesn't help matters either.
even a complete dumbass script kiddie...can't write code to interoperate with an established MPAA data format
Point was:
He was a teenager (normally tough to prosecute).
He was Norwegian (DMCA doesn't exist in Norway).
He wrote the code.
The code became illegal to distribute.
He *still* came under legal fire.
I guess it didn't matter that the code didn't break any copyright or patent laws and was a first step in writing "interoperable" products.
So, we're left with a question. Who's allowed to interoperate, and who's not? Obviously Norwegian teenagers fall into the "who's not" category, at least in practice. The fact none of this even gets mentioned by legislators just underlines how foolish it would be to think these ammendments to UCITA actually mean anything.
Didn't the DMCA have some provisions that said it wasn't supposed to hurt interoperability?
We see just how much a provision like that really means when even a Norwegian teenager can't write code to interoperate with an established MPAA data format...
The problem with democracy is that democracy has to tolerate all oppinions and treat them in the same way.
How does "tolerance" fit in here? A Rebuplic may have rules about how individuals should be treated, but a Democracy is merely the will of the many. In a democracy if 51% of people vote to "kill all the Jews" that's exactly what happens.
Perhaps Turkey would swallow "democracy" better if we didn't try to shove our neo Darwinist-Christian laws and values down their throats? It took over 100 years to give up slavery, and the vote to women in this country. I expect some similar difficulties getting Muslim countries to "catch up".
Well, actually it does in a sence make it right if he is there by his own free will or as a consequence of a crime he has commited...
Exactly. It may or may not be right to kill the gladiator, but voting certainly doesn't effect that distinction...
The irony could not get any better!
I Particularly appreciate a headline sharing the page with this one on the MIT site called "When Patenting Works". This little ditty celebrates the fact a company called Intergraph was able to wipe the courtroom floor with Intel using "possibly invalid" patent claims.
Somehow I think these MIT guys are just missing the point...
In the end we live in a democratic republic
Actuallly we seem to be moving more and more towards a strait democracy, which hasn't been shown to work as a form of government and is probably a lot scarier than technology...
Just cause 85% of people shout "kill him" at the gladiator, doesn't make it right.
XML is to the presentation layer as TCP is to the session layer. It strikes me that XML isn't the end all be all (just as TCP isn't) of its layer. However, it is a very compelling implementation against which all other implemenations can be measured. I expect great strides in the presentation layer in the next few years primarily because of XML.
... (think of RPC, for example)
This automatically allowed for sessions
Which is what I thought TCP was all about... though there is overhead of course.
it supported asynchronious request-reply paradigm
I didn't manage to get through the whole specification, but this did seem to be one of the useful things in there... Of course, how useful is this really? It might be somewhat nice to have a tool I can use in my application to create an RPC mechanisms or the like, but what I'd much rather have is an RPC mechanim already built for me. (Like RMI in Java for example)
Don't get me wrong, BEEP will probably be useful in some applications, but I don't expect it to become a "canonical" implementation like XML or TCP.
Basically, I see a need for some level of tools to help in creating generalized TCP application protocols. In fact every TCP programmer I've met that does this for any length of time has created (or modified) their own toolset for this end. The problem with BEEP seems to be that it is a little too heavy and complex for many simpler applications. Also, the application protocol programmer, usually spends a lot more time writing code to communicate with legacy systems then coding new application protocols. I don't see a lot of functionality in BEEP for dealing with legacy issues.
Application
I believe that falls under *some variation*.
Either way, interface is still a very relative term...
There is a REASON that the Internet is based on IP
Amen Brother!
I should point out for those that might've missed your point that TCP, UDP, and GRE are all "session" layer protocols, which are lower level than application, but still we don't have *just one* of them. So why should there be *just one* application layer?
What's missing from this conversation is the presentation layer. IMHO, this is what XML is all about. Of course, what I think is really missing in industry is a new layer between presentation and application that all of us can ignore as we begin to focus on the presentation layer...
to erase the TCP connection negotiation overhead.
Isn't this why UDP and other protocols exist on top of IP (or other routing layers). So you can forgo the overhead that a fancy session layer (like TCP) incurs.
It seems to me that most of these new protocols are just trying to get a free ride through existing firewalls... Why can't we all just use IP the way it was meant to be used? (and move to v6 to alleviate addressing pinches)
for complex, two-way, stream-based communications.
I believe TCP already solves this problem, perhaps herein lies the lack of excitement...
No by definition the aplication layer protocol provides the application with access to the network stack through an API.
Um... You remember what API stands for right? That'd be "Advanced Programming Interface" or some variation. If you'd ever had to code using one of these, particularly a "new" one, you'd realize that "Interface" is a very relative term.
So, is it easier to just use sockets as your application's API to the network? In many cases yes... Interestingly enough, TCP already provides multiple streams of cummincation, and port numbers are supposed to tell you how to behave when listening or connecting. Adding another layer on top of this to do essentailly the same thing seems redundant. The only benefit I can see to this might be effects on performance(for wireless) or the ability to "sneak through" firewalls. But at what cost complexity and efficiency?
That said, if anyone ever comes up with a useful presentation layer, I'd be happy to give it a whirl. (XML has been kind of fun that way...)
by "pirating" it, you are proving that it is useful
Of course it's useful, just like a free alternative is (hopefully) useful. It just isn't useful enough to justify the price tag. Choosing a cheaper alternative sends a clear message to lower the price. "Pirating" sends a clear message asking for better copyright enforcement.
It's not up to Joe to tell Adobe how to price their product.
Sure it is. If he feels it is over-priced, he should vote by not using it or creating a free alternative.
When people start to confuse alternatives with piracy is where things get really scary...(DMCA et al)
So the reason why software developers are chasing pirates is so that they can lower prices?
Don't buy the BS from either side. Software developers (like this Mr. Vold) charge money for what they create because like everyone else they must eat, but would like to do what they love (create software) to fill their needs. Large corporations(and governments?) are a different sort of entity. I don't think I need to go into what they care about or how far they will go...
Personally, my feeling is if you're going to charge big $$$ for a stream of bits, your support and other benefits should be good enough that piracy can never truly devalue what you sell. If you're selling to tons of people for low prices, there should still be that "something extra" between what you offer and warez. If you're missing that "something extra" prepare for a difficult time staying in business.
That said, speaking as a developer for a small company: I'd still throw the book (minus the DMCA) at anyone I might catch infringing our software. We've spent a lot of time and money on development effort, and the law currently says we control who has rights to own "a copy" and what price they will pay. Just don't expect me to make any corollaries with murder on the high seas, burning houses, or physical theft.
Bottom Line:
Intellectual property is different than physical property but has meaning nonetheless. Further, information will eventually be free, or people won't be. The equation is that simple. History will decide the rest.
Good point, even with the friendliest license, things can always be changed after the fact. Especially in this legal climate.
I should be able to toss my own code easily into the public domain and it should be safe for everyone to use with no fear of lawyerly retribution. Anything less is a failure in education and our legal system, not a lack of certifications. (Main problem being that copyright rather than requiring application is now default...)
You want to fight the corporate abuse of copyright? Go GPL.
You want to maximize usability for everyone? Go BSD or public domain.
You want to make money? Go Copyright.
You want to write your own license? Go to hell!
Or am I the only person who read the rulling at the end of the article...
Of course, I didn't see much in the aticle talking about exactly what was/wasn't at issue in the case.
If the issue is: Should the "law" stop people from selling this game items, that's one thing.
If the issue is: Does Mythic have the right to erase player data on their servers, it's quite another.
Every time someone has to change some code, you've just forced them to double their workload, and change some comments too.
Just think of all that time wasted finding requirements and writing specifications before coding can even begin!! Who can function with such a multiplied workload.
I wholeheartedly agree! Having to dredge through a few difficult functions doesn't take that much time. By contrast, trying to figure out what 50,000 functions do in a million line program can drive a developer (or maintainer) insane! Especially if only 10,000 functions do anything useful.
That said, every rule needs some limits. I've also waded through functions that required 4 source files (due to 32k compiler limits) and been ready to commit great voilence afterwards.
I find that combining your rule of functions matching abstractions with an effort to reduce total code size works the best for me. My guiding princible is this: "Will the next person to see this line of code, program, etc be glad it exists, or wish it didn't."
Having trouble reading your code? It's probably a better idea to break your code up into functions that are likely to be useful in more than one place. Instead of just breaking them up because they are too long.
If this doesn't seem to work for you, I'd have to see some specific examples...