You can sell or give away the copy you've received (first sale doctrine), but you can't transmit it to every visitor because you're making extra copies.
Most everything on TV is copyrighted. Even though it's just been transmitted to millions of strangers, there are limits on what you can do with a copy of it.
Laws generally apply to fraudulent information in messages, not spam as a whole. And even if sending the message was a crime or tort, the message itself is still copyrighted.
What's wrong with junk mail? Unlike spam, it's targeted and limited to sane volumes because the sender is paying the full cost of delivering it (and then some).
All works are copyrighted unless the holder places the work in the public domain (or the copyright expires, which isn't allowed to happen anymore). The notice just makes it easier to sue for infringement, since they can't claim ignorance (which isn't much of a defense anyway).
I don't think ISO C guarantees that zero will be regarded as a successful termination (much less that EXIT_SUCCESS equals zero), though POSIX probably does.
I'd argue that calling System.exit is a Really Bad Idea unless you are absolutely certain you are the only app. One of the design goals of Java was to confine untrusted code without relying on process boundaries, which means an ideal system would run just one JVM for all users with an elaborate security policy.
Anything an employee creates is a work for hire. Nothing a contractor creates is ever a work for hire, though it's common to require copyright assignment in the contract to get the same result.
"Open Source" and "Free Software" have very definite and widely-used meanings. Using them in unconventional ways is going to confuse and mislead people as to what you're really talking about. That's the best way I know of to determine whether a phrase is being used correctly.
Note that this means the word "hacker" cannot be used correctly these days (except to a known audience)--whether you use the classic meaning or the media's confused meaning, a lot of people are going to misunderstand.
Note that work for hire applies to employees but not contractors! A few clients have been burned because they didn't know or care about this, and their contractors neglected to raise the issue. Requiring the contractor to agree to assign the copyright to the work to you is the usual way of handling this.
In the US, willful copyright infringers are (always?) liable for treble damages, or you can elect $100,000 statutory damages if you registered the copyright. It's also a federal crime.
Modifying an interface leaves clients and objects disagreeing about which invocations are valid! Make a new interface, inheriting the old one if you want to remain compatible (that's what the major and minor version numbers in an "IDL:" RepositoryId are for). Objects can implement both (probably sharing most of the code). Clients can reject objects that don't implement the new interface, or fall back on the old one.
If you don't have a real IIOP proxy or a tunnel for arbitrary TCP (like HTTP's CONNECT method), you can wrap an IIOP request in HTTP and pass it through a HIOP proxy. Callbacks may not work, but that's also a defect in the HTTP binding for SOAP.
Build vs. buy is enjoyable but rarely worthwhile. That code will create a malformed request if certain characters (quotes, ampersands) appear unencoded, and an ad hoc pattern may fail to match if the response is extended in certain ways--does it handle namespace scoping, marked sections, and mustUnderstand headers? If you're paranoid enough it's possible to do it right, but even then all you have is an unmaintainable substitute for SOAP::Lite.
XML is a strict subset of WebSGML. They designed it carefully so that you could produce a DTD for any well-formed XML document and process it using any up-to-date SGML tool that implements the WebSGML TC extensions.
Thanks; I never noticed the potential legal minefields.
In CS theory, a language is just a set of strings of symbols. Interesting languages are infinite, so we use grammar rules to define them. XML is a grammar, and the set of all well-formed XML documents is a language. But a subset of those documents that are all valid using a schema (a more strict grammar) is more interesting because meanings can more easily be assigned to them.
They wrote a schema as well as a DTD (which has the usual namespace validity problems).
XSD may be big and ugly, but the designers would have noticed if it couldn't even describe itself.
It's RPC; you should have a client library whose job is to marshal requests and unmarshal responses. If using it for its intended purpose is so painful you're better off constructing requests manually, something is seriously wrong with your environment.
Every conforming ORB must implement IIOP (GIOP over TCP). Interoperability between ten major ORBs was tested and documented three years ago. If your vendor can't even handle that, they have little chance of getting Schema right.
Re:What, and lose Free Software's main advantage?
on
Software For Ransom
·
· Score: 2
Ad-hoc collaboration will have to wait until the code is freed, but then everyone will always be able to reuse it in all their own projects. You can also organize a team to collaborate and split the ransom.
Winamp merely stopped charging for binaries. They haven't published source.
Re: Good comments, but here are some responses
on
Software For Ransom
·
· Score: 2
Unless the copyright holder explicitly declares "this work is now in the public domain", even if they go bankrupt somebody still has the copyright. It may be hard to find out who or get their permission to redistribute, which is a big problem for library archives when the only known copies of out-of-print books, records, and movies are deteriorating.
there is NEVER a free version of decompression programs for Windows, only ever shareware
Info-ZIP and gzip have been ported for a long time.
Re:How is this any differnt from regular copy righ
on
Software For Ransom
·
· Score: 2
If I release a binary, its copyright will theoretically expire (75 years after the author's death, or 95 years after release for a corporate author, though in practice the US Congress won't let that happen), but the source will never be available unless I feel like releasing it also.
instead pays them for the effort they invested. That's unfortunate
Why? That's the economically efficient result. If $X persuades me to write something, giving me $2X is a waste of resources that could have been used to persuade me or someone else to write something additional.
If the ransom for V1 is paid, you can certainly ask people to pay another ransom for your work on V2 when it's ready, though you're competing with anyone else who's willing to charge less for their vision of V2.
use GPL [...] the author can at least get a couple hundred dollars
That's great if the software only took half a day to write, but it's not a real business model. Someday I want to continue working as a professional developer but give up the control over our customers (thou shalt have no maintainer but us) engendered by proprietary licenses.
Re:open source software eats programmer jobs
on
Software For Ransom
·
· Score: 2
Why would they compete with a project that'll soon be freed anyway, rather than compete with a proprietary project or do something unique?
It means you can have software that developers couldn't afford to write and give away, yet go to a competitive market for customization work (instead of being stuck with whatever the vendor charges because only they have the source).
Changing the ransom would be fraud, unless the vendor and customers agreed on a procedure (voiding the contract and refunding their money, for instance).
Plenty of consulting firms do work for which they're going to be paid well but only once. I worked at one that had been around for twenty years (they only went bankrupt because they expanded rapidly to serve dotcoms who went bankrupt). Your argument only applies to people who view software development as publishing.
Slashdot Mirror
Most everything on TV is copyrighted. Even though it's just been transmitted to millions of strangers, there are limits on what you can do with a copy of it.
What's wrong with junk mail? Unlike spam, it's targeted and limited to sane volumes because the sender is paying the full cost of delivering it (and then some).
All works are copyrighted unless the holder places the work in the public domain (or the copyright expires, which isn't allowed to happen anymore). The notice just makes it easier to sue for infringement, since they can't claim ignorance (which isn't much of a defense anyway).
I don't think ISO C guarantees that zero will be regarded as a successful termination (much less that EXIT_SUCCESS equals zero), though POSIX probably does.
I'd argue that calling System.exit is a Really Bad Idea unless you are absolutely certain you are the only app. One of the design goals of Java was to confine untrusted code without relying on process boundaries, which means an ideal system would run just one JVM for all users with an elaborate security policy.
Anything an employee creates is a work for hire. Nothing a contractor creates is ever a work for hire, though it's common to require copyright assignment in the contract to get the same result.
Note that this means the word "hacker" cannot be used correctly these days (except to a known audience)--whether you use the classic meaning or the media's confused meaning, a lot of people are going to misunderstand.
Note that work for hire applies to employees but not contractors! A few clients have been burned because they didn't know or care about this, and their contractors neglected to raise the issue. Requiring the contractor to agree to assign the copyright to the work to you is the usual way of handling this.
In the US, willful copyright infringers are (always?) liable for treble damages, or you can elect $100,000 statutory damages if you registered the copyright. It's also a federal crime.
Modifying an interface leaves clients and objects disagreeing about which invocations are valid! Make a new interface, inheriting the old one if you want to remain compatible (that's what the major and minor version numbers in an "IDL:" RepositoryId are for). Objects can implement both (probably sharing most of the code). Clients can reject objects that don't implement the new interface, or fall back on the old one.
If you don't have a real IIOP proxy or a tunnel for arbitrary TCP (like HTTP's CONNECT method), you can wrap an IIOP request in HTTP and pass it through a HIOP proxy. Callbacks may not work, but that's also a defect in the HTTP binding for SOAP.
Build vs. buy is enjoyable but rarely worthwhile. That code will create a malformed request if certain characters (quotes, ampersands) appear unencoded, and an ad hoc pattern may fail to match if the response is extended in certain ways--does it handle namespace scoping, marked sections, and mustUnderstand headers? If you're paranoid enough it's possible to do it right, but even then all you have is an unmaintainable substitute for SOAP::Lite.
XML is a strict subset of WebSGML. They designed it carefully so that you could produce a DTD for any well-formed XML document and process it using any up-to-date SGML tool that implements the WebSGML TC extensions.
Thanks; I never noticed the potential legal minefields.
In CS theory, a language is just a set of strings of symbols. Interesting languages are infinite, so we use grammar rules to define them. XML is a grammar, and the set of all well-formed XML documents is a language. But a subset of those documents that are all valid using a schema (a more strict grammar) is more interesting because meanings can more easily be assigned to them.
They wrote a schema as well as a DTD (which has the usual namespace validity problems). XSD may be big and ugly, but the designers would have noticed if it couldn't even describe itself.
It's RPC; you should have a client library whose job is to marshal requests and unmarshal responses. If using it for its intended purpose is so painful you're better off constructing requests manually, something is seriously wrong with your environment.
Every conforming ORB must implement IIOP (GIOP over TCP). Interoperability between ten major ORBs was tested and documented three years ago. If your vendor can't even handle that, they have little chance of getting Schema right.
Ad-hoc collaboration will have to wait until the code is freed, but then everyone will always be able to reuse it in all their own projects. You can also organize a team to collaborate and split the ransom.
Winamp merely stopped charging for binaries. They haven't published source.
Unless the copyright holder explicitly declares "this work is now in the public domain", even if they go bankrupt somebody still has the copyright. It may be hard to find out who or get their permission to redistribute, which is a big problem for library archives when the only known copies of out-of-print books, records, and movies are deteriorating.
Info-ZIP and gzip have been ported for a long time.
If I release a binary, its copyright will theoretically expire (75 years after the author's death, or 95 years after release for a corporate author, though in practice the US Congress won't let that happen), but the source will never be available unless I feel like releasing it also.
Why? That's the economically efficient result. If $X persuades me to write something, giving me $2X is a waste of resources that could have been used to persuade me or someone else to write something additional.
If the ransom for V1 is paid, you can certainly ask people to pay another ransom for your work on V2 when it's ready, though you're competing with anyone else who's willing to charge less for their vision of V2.
That's great if the software only took half a day to write, but it's not a real business model. Someday I want to continue working as a professional developer but give up the control over our customers (thou shalt have no maintainer but us) engendered by proprietary licenses.
Why would they compete with a project that'll soon be freed anyway, rather than compete with a proprietary project or do something unique?
Changing the ransom would be fraud, unless the vendor and customers agreed on a procedure (voiding the contract and refunding their money, for instance).
If most of your apps weren't even worth the labor that went into them, why would it be a good thing for your business to prosper?
Plenty of consulting firms do work for which they're going to be paid well but only once. I worked at one that had been around for twenty years (they only went bankrupt because they expanded rapidly to serve dotcoms who went bankrupt). Your argument only applies to people who view software development as publishing.