I agree. Isn't "duplication of functionality" by a 3rd party just a fancy word for COMPETITION? We can't have that in a free-market economy, now can we?

There are two camps using copyright law as protection:

1. Copyright law keeps source code non-proprietary (e.g. GPL)
2. Copyright law keeps source code proprietary, so you have to pay to use the product (e.g. most commercial software)

Now apply a 5 year expiration of copyright:

Result to 1:
The source code is already visible, and nothing protects the code anymore from someone stealing it and making it proprietary, despite the intention of the authors for it to remain non-proprietary.

Result to 2:
The source code is NOT already visible. Lack of copyright protection makes the product free-as-in-beer, but mere expiration of copyright does not force the authors to release the source code. So the result is that no one else can steal the source code like they could for expired FLOSS copyright.

So yes, there IS an imbalance of power. In no way does this help authors preserve the freedom to keep software non-proprietary.
And no, it's NOT just a simple case of each side has a right to keep their code open or closed as they see fit. It favors proprietary software to remain proprietary, but removes protections for software to remain non-proprietary. Stallman is right: the only way to keep it fair is if both sides must make the source code available.

THINK PEOPLE.

IANAL, but I thought that *one* essential reason laws waive the expectation of privacy in "public places" is because by the *nature* of that place, it is essentially not private. For example, there is too much of a practical burden of enforcing privacy when I go walk outside, because that's actually *me* walking outside. There's only so much identity-hiding I can do.

But for a blog, by its very *nature* it works the other way around. Anonymity happens by the fact that the blog posting doesn't see who is actually sitting at the keyboard, so identity has to be proactively required by settling for something that substitutes, such as using a valid email for login registration. Here, regarding the enforcement burden, it's the other way around: there is more effort required to identify someone than not identify someone (e.g. you could allow anonymous posts, etc.).

The point:
Although I am sharing *data* that becomes public, *I* am not personally in a public place, so I should reasonably assume I can have anonymity.
 

I get tired of hearing the same old discussion about whether or not the relational database is going to die. They're not. But the new breed of *specialized* databases work well for their *specialized* purposes. Big surprise. But all of them inevitably make a trade-off. Anyone who works seriously with database design knows that it's all about trade-offs.

One of the main motivations for the new breed of databases is that the standard SQL database relies on things such as foreign keys and other constraints for data consistency, but that requires the data to be directly managed by that running DBMS process. When you require data to be distributed over a network (i.e. over many separate processes), then the only way a *foreign key* can work is if the DBMS process has some sort of link over the network to the separate DBMS process and then use that somewhat as if it were local. (Other strategies involve using external application code for consistency rather than foreign keys, etc.) Of course, the DBMS process can't use it's usual local low-level optimizations behind-the-scenes in order to handle that query efficiently over the network, so it doesn't scale. Specialized DBMS's for distributed data focus on optimizing being distributed, while the typical SQL DBMS optimizes storage and retrieval of data as if it were local. The bottom line is that the traditional SQL database scales well vertically, but not horizontally concerning hardware. Or rather, when you scale horizontally, you forgo a lot of its advantages. The new breed of databases trade-off consistency and other assurances for the sake of "good enough" consistency and really fast retrieval of domain-specific data.

But not everyone is trying to be Google or Amazon. Financial institutions such as banks can't tolerate "good enough" consistency. The biggest problem with relational databases I see nowadays is that people are ignorant about why "relational" is such a good idea, and how SQL only gets you part of the way to "relational" and that SQL's shortcomings are a different issue. The second biggest problem is that most people are used to only one or two data usage patterns, and if it "works for them", then they assume it should *always* be done that way. For example, the hordes of people who barely know Excel (i.e. not a relational database) or Access, and then like to give "expert" advice. Or a web programmer that believes that ORM's are the One True Way because they abstract away choices of DBMS in order to keep favorite language X, despite the needs of other people are the opposite: perhaps we want to abstract away the choice of programming language so that we can keep the same database, and so maybe it's a good idea if the database itself can ensure data consistency rather than relying on the ORM, etc.

With a division of labor, the idea of the manager is to strictly keep to "managing people", right? What does that actually mean in real practice? If the techies are the ones with all the actual skill to implement technology, what happens when techs have a technological debate? If a team is designing a complex system and there is a difference of opinion between two or more choices with subtle but far-reaching consequences, in the real world, is the manager going to be hands-off and stick with the "people side" only?

I don't know about anyone else, but that's not how I've ever seen it happen. The manager must make a decision about the design of the technology. How is he/she to decide? Based on which developer is a snappier dresser, or which one kisses ass more? :-) The business world needs to get rid of this obsolete idea of a "manager" who mechanistically manages human "resources". We need to be more honest about human interaction. What most businesses need are LEADERS. You can't lead if you're not in front. You want quality code from your employees? Then can YOU recognize the difference between bad and good code? In practice, good managers in IT are technically proficient AND have people skills. It's out of necessity, businesses really don't have a choice unless they want to keep burying their heads in the sand and sticking with merely "managing" their employees who they have no idea what those employees actually do.