Creation rights

Recently, I entered a discussion on licensing, specifically relating to usage of software applications. With the increasing popularity of Web 2.0 technologies, specifically web services, feeds, and mashups, it raised some curiosity in me.

Users can now create mashups of different sites. The content isn't explicitly hosted or created on the mashup site, but the mashup site aggregates the data from a number of other sites. What is the legal implication of this?

The original content (whether it be plain text, markup, source code) is not created on the mashup site. The mashup site creator does not own the content, but is merely collecting it from other sites similar to how a browser collects data from another site. If the content is permissive, then all is well. The authorship site (owner of the content) can give the ability for other users to grab content via feeds (RSS or Atom), web services, or otherwise if explicitly defined in the license for that content.

What if the content is not defined as permissive though? Take for example a random site that scrapes another web site for content and presents it as its own? An explicitly shareable content feed isn't used, but the content is parsed off another site in ways the original author did not intend to distribute his or her work. Is this legal?

What if the mashup site presents advertisements while aggregating content that they don't own or necessarily have permission for? What exactly qualifies as fair use in this context?

User experience

In an ongoing project, I heard the following in regards to user experience:

"It is good to maintain a consistent user interface between several related components even if the user experience is bad."

I understand the point being made, but is it really good to train the user to get used to a crappy user interface?

The possibilities:
1. Have a bad, but consistent user interface.
2. Have inconsistency in the user interface. One screen is a bad user interface and another similar screen is a good user interface. (Better or worse than #1?)
3. Switch all screens to have the good user interface (Best). The problem is that this won't happen due to lack of resources.

Workarounds

Lazy coders. I sympathize, but sometimes there are lines to be drawn.

Recently, a problem occurred in regards to a particular parameter sent to a method which resulted in a high severity defect against our application. The message was modified to include new information. The message could also come in different formats.

Problems...
1. The changes in the message were not documented.
2. The code handling the message was not generic.
3. The message parameters were not strongly typed.
4. The message could be formatted in one of two different ways.

There were two suggested solutions to solving this defect.

1. Document the message changes well. Make the message handling code more generic to handle this message more gracefully, yet generically to accomodate future changes. Consider separating the multi-formatted message into two separate messages in order to have a more strict definition for the message.

2. Add an additional guards for the new changes in the message.

Solution #1 was offered by me. This is why good programming and good developers are hard to measure. Adding new guards will solve the immediate problem. The downside is that when new parameters are added to the message in the future (which they inevitably will), the code will break yet again.

I, therefore, emote: *sigh*.

Think generically.