Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Re:Well past time... (Score 2) 117

Yeah? And imagine what it would be like if the crossing were run by a private company with financial incentive to discover contraband. We'd have 100% "bend and spread 'em!" I'll take good old-fashioned government incompetence over corporate goons with a financial interest in fingering my bunghole any day!

Comment Re:Sweet (Score 1) 286

Yeah, C++11 was a major improvement; much of the extra "complexity" actually ended up making a lot of things much simpler. The new "auto", the new lambdas, and the new "smart" for loops, between them, allow writing simple, straightforward code to do things which would have required a tangled, opaque, and fragile mess of barely-readable code in older versions of C++.

Rvalue-references and std::move are a little trickier to understand, but fortunately, they can provide benefits even if you don't use them directly, since they greatly improve the performance of the standard library container classes and such. Even if you don't change your code!

Comment Re:That's not how the three laws work (Score 1) 186

The Three Laws only apply to fictional robots. Because they're fictional! (The "laws", that is.) Expecting them to apply to actual robots is simply silly (to use a more polite term than it probably deserves).

Even if we had actual AI in the sense it's usually used in science fiction, that wouldn't make the Three Laws magically pop into existence. They'd need to be programmed, and to the best of my knowledge, nobody has written that code yet.

Comment Re:Who are we rooting for today? (Score 1) 106

Good API design is hard work, requires expertise to do it, is not trivial and does guide implementation.

None of which is a reason for something to be copyrightable! If hard work alone were copyrightable, every ditch digger in the world would be owed royalties from every ditch they've dug. If requires-expertise made something copyrightable, then I should be able to claim copyright on Poe's "The Raven" because I can recite it from memory. If guides-implementation made something copyrightable, then again, those ditch diggers should get royalties from the plumbers who laid pipe in those ditches.

In the case of designing a good API, most of the hard work comes from figuring out what people are likely to expect, and matching that as closely as possible. That's pretty much the opposite of "creativity", which is what gives something copyrightability. Figuring out what people are likely to expect and matching that as closely as possible falls under the category of "scenes a faire", which is explicitly excluded from copyrightability.

A sufficiently creative API might be copyrightable, but it would also almost certainly be a horrible API, not a good one, since by definition it wouldn't be using the obvious, expected choices.

Comment Internet Archive did it first! (Score 1) 74

Yahoo may be the first since "the reforms of the USA Freedom Act", but the Internet Archive fought and won back in '08. I'm pretty sure Slashdot covered it when it happened, but I'm too lazy to hunt down the link.

It's not clear to me if the USA Freedom Act made this harder (in which case, why are we calling them "reforms"?) or easier. That would make this story a lot more interesting.

(The EFF has the Archive's slightly-redacted NSL on file, for anyone who's interested in comparisons.)

Comment Re:Stallman might agree with Oracle (Score 1) 357

That's not the interface. That's linking with the actual code. Which can be (and is) copyright.

The reason using readline but not including the readline code is still a copyvio is that the only possible use for such code is to create a program linked with the (actually copyrighted) readline library. And the law takes intent into account. If you intend to give people a copyright-violating program, trickery of making them get the copyright-violating part on their own are considered just that: tricks. That's why NeXT gave up and released the code to their Objective-C back end after the FSF objected to their use of GCC. And that was a standalone binary!

Now, in the case of readline, you could get around the problem (and someone did, in a similar case involving a different library) by creating your own stub library which used the same (not-copyrighted) API. Then (and only then), the use of the API would no longer signal your clear intent to distribute a copyright-violating program.

Comment Re:They don't know what they're talking about (Score 1) 357

That actually does work. There was even a real-world example: someone created a plugin for some GPL'd app that used the (proprietary at the time) RSA libraries. FSF claimed the code couldn't be distributed, because the intent was clearly to link GPL'd and non-GPL'd code into a single app. So the guy made a stub library with the same interface as the RSA library, and the FSF dropped their objections. Even though the stub library did nothing.

Of course, in such a case, you couldn't distribute the complete system, because that would clearly still be mixing the GPL and non-GPL code--you would no longer be able to call it "mere aggregation"--but he was able to distribute the plugin by itself.

Comment Re:Bullshit ... (Score 1) 357

As anonymous coward said, the GPL is not an EULA, it's a distribution license. It's also completely optional. Unless you want to redistribute the code, you can completely ignore the GPL and simply use the copy under normal copyright terms. Therefore, until I actually distribute some of this software myself, there is no license!

Likewise, the BSD and MIT license, which simply say "you can copy/modify this as long as you preserve attributions" and not much else. That's not a user license; that's a distribution license.

Comment Re:Complete utter nonsense! (Score 1) 357

You asked a mouthful there!

Bottom line: copyright is supposed to protect creative and original works. You cannot copyright a simple list of facts, no matter how much research it took. Languages (computer or ConLan) are generally considered tools for expression; something written in Klingon can be copyrighted, but the Klingon language itself cannot be. A dictionary defining the meanings of Klingon words can be copyrighted, but not the language itself.

Note that no computer language ever has been copyrighted. Implementations can be copyrighted, of course, but the languages themselves are not.

APIs are simply the language you use to access the functionality of a library. The library may be copyrighted, like the dictionary of Klingon, but the interface is simply the words of the language of the library, used for creative expression by the application programmer. This is more-or-less the heart of the matter.

Beyond that, purely functional language (not a functional language, but language which is required for functionality) cannot be copyrighted. If there's only one way to describe something, you can't copyright that, because it's defined by the problem-space, so no creativity is required. In most languages, a simple swap function would probably not be copyrightable, because there's really only one, or maybe two, sane ways to implement that. Writing a word processor, on the other hand, allows all sorts of opportunities for creativity.

(The irony of this last point is that a really badly designed API would be more likely to be copyrightable than a sensible, straightforward one, since the sensible, straightforward one is constrained by the problem-space.)

In the case of macros, the names and arguments of the macros would not* be copyrightable, but the bodies would be (assuming they weren't trivial, like swap).

Anyway, I'm really not the best one to explain all this. If you want a really good explanation, I recommend reading the transcripts of the final judgment in the original suit. Its conclusion may have been overturned by the appeals court, but it clearly lays out the reasons why APIs until then had not been considered copyrightable. It also lists a number of applicable precedents, which are still quite relevant.

* At least, till Oracle v. Google, they would not have been. Now they're merely probably not copyrightable.

Comment Complete utter nonsense! (Score 5, Insightful) 357

Before Oracle v. Google, everyone assumed (based on extensive legal precedent) that APIs were not subject to copyright at all. Yet the GPL was just fine. Why would the GPL be threatened all of a sudden just because one more API turned out to be copyable?

The only tangible result of this case has been a very slight strengthening of copyrights, since the appeals court rules that APIs might be copyrightable under certain circumstances. How does strengthening copyright weaken a license that relies on copyright?

This is either monumental stupidity, or outright shilling. Hanlon's razor suggests I ought to go with the former, but I'm going to wait and see.

Comment Depends... (Score 1) 178

Hard to say, since it depends entirely on what sort of thing you like!

If you want technical stuff that isn't gory details, something like Fred Brooks' The Mythical Man-Month is probably worth a shot. A lot of stuff from this book has passed into common wisdom, but actually reading the first-hand accounts makes it far more real!

If you want lighter entertainment reading that's vaguely computer related, I can strongly recommend Charles Stross's "The Laundry Files" books. These are a mash-up of spy thriller and Lovecraftian horror with a hacker protagonist, in a world where computers are the ultimate key to summoning up tentacled creatures from beyond.

But if your favorite author is Dostoevsky, then this may not be to your tastes. As I say, it depends entirely on what sort of thing you like.

Slashdot Top Deals

"In order to make an apple pie from scratch, you must first create the universe." -- Carl Sagan, Cosmos

Working...