Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re: ZFS is nice... (Score 1) 267

But it's combined by the user at runtime, not by canocal. The GPL allows an end users to do this.

This is a way that people kid themselves about the GPL. If the user were really porting ZFS on their own, combining the work and never distributing it, that would work. But the user isn't combining it. The Ubuntu developer is creating instructions which explicitly load the driver into the kernel. These instructions are either a link script that references the kernel, or a pre-linked dynamic module. Creating those instructions and distributing them to the user is tantamount to performing the act on the user's system, under your control rather than the user's.

To show this with an analogy, suppose you placed a bomb in the user's system which would go off when they loaded the ZFS module. But Judge, you might say, I am innocent because the victim is actually the person who set off the bomb. All I did was distribute a harmless unexploded bomb.

So, it's clear that you can perform actions that have effects later in time and at a different place that are your action rather than the user's. That is what building a dynamic module or linking scripts does.

There is also the problem that the pieces, Linux and ZFS, are probably distributed together. There is specific language in the GPL to catch that.

A lot of people don't realize what they get charged with when they violate the GPL (or any license). They don't get charged with violating the license terms. They are charged with copyright infringement, and their defense is that they have a license. So, the defense has to prove that they were in conformance with every license term.

This is another situation where I would have a pretty easy time making the programmer look bad when they are deposed.


Video Marijuana Growers Need Software, Too (Video) 85

Meet Kyle Sherman, founder and CEO of Flowhub, a company that makes software for marijuana growers. The company's website says Kyle "worked at a grow and experienced the problems with cannabis inventory management first hand. Frustrated by the software his grow was using, he searched for something better. When his search failed him, he became fueled by a passion to create a system that would accelerate workflows, increase accuracy, and simplify compliance."

Every state that legalizes marijuana will give Flowhub a new set of potential customers (and a new set of regulations their software must take into account). And Kyle talks about making easy-to-use enterprise software for other industries, based on his experience making super-simple software for marijuana people. It's possible that Flowhub will also make new versions of the NUG, the handheld "all-in-one device" Flowhub provides along with its subscription-based software. Are we talking about unbridled optimism here? Absolutely! This is America, where possibilities are endless, even in the not-100%-legal (yet) marijuana industry.

Comment Re:ZFS is nice... (Score 1) 267

Uh, that doesn't work. The problem is that doing exactly what you've written down is contriving to avoid your copyright responsibility by deliberately creating a structure in someone else's work which you believe would be a copyright insulator. If you went ahead and did this (I'm not saying that you personally would be the one at Ubuntu to do so), I'd love to be there when you are deposed. Part of my business is to feed attorneys questions when they cross-examine you. I have in a similar situation made a programmer look really bad, and the parties settled as soon as they saw the deposition and my expert report. See also my comment regarding how Oracle v. Google has changed this issue. You can't count on an API to be a copyright insulator in any context any longer.

Comment Re:ZFS is nice... (Score 1) 267

I think you need to look at this in the context of the appeal of Oracle v. Google. We had a concept of an API being a boundary of copyright based on 17 CFR 102(b) and elucidated by Judge Walker's finding in CAI v. Altai. That stood for a long time. But Oracle v. Google essentially overturned it and we're still waiting to see what the lower court does in response.

Comment Re:If I was Microsoft, here's what I'd do. (Score 1) 90

I think either yours or my idea or even both would be a good move to add more Windows Phone users.

Realize that I don't necessarily believe that more Windows phones are automatically a social good; I just believe that if that were Microsoft's goal, the way to achieve it would be for Microsoft to encourages developers to target them as a platform. This would incidentally benefit Microsoft by having developers target their code to Microsoft's IDE, rather than X Code or Eclipse.

Again, this is only about Microsoft's best interests in regard to establishing market share, and not about what I believe is necessarily a social good.

Comment Re:If I was Microsoft, here's what I'd do. (Score 1, Insightful) 90

I'm not sure if this is legal or not, but if they made an iOS and Android emulator so you could run both iOS and Android apps on the Windows phones, some people might get a Windows Phone then who'd otherwise be getting one or the other because they figure they get all types of compatibility.

This would be the third worst tactical blunder of all time. The most famous of which is "never get involved in a land war in Asia" - but only slightly less well-known is this: "Never go in against a Sicilian when death is on the line"!

The correct thing to do is build Windows emulators for iOS and Android, rather than the other way around.

This will cause developers to target their development for Windows, rather than targeting iOS or Android. This get Microsoft native apps, and at the same time, detracts from having those same apps native on iOS or Android.

FreeBSD made the mistake of building a Linux emulation layer for FreeBSD, instead of a FreeBSD emulation layer for Linux, which would have had developers working on FreeBSD native code, rather than Linux native code.

Comment CDDL and GPL don't mix (Score 3, Informative) 267

Regardless of what Ubuntu has convinced themselves of, in this context the ZFS filesystem driver would be an unlicensed derivative work. If they don't want it to be so, it needs to be in user-mode instead of loaded into the kernel address space and using unexported APIs of the kernel.

A lot of people try to deceive themselves (and you) that they can do silly things, like putting an API between software under two licenses, and that such an API becomes a "computer condom" that protects you from the GPL. This rationale was never true and was overturned by the court in the appeal of Oracle v. Google.

Comment Re:Documentation is rarely valued as a contributio (Score 1) 685

I can't speak for other people, but personally I do value documentation. Not that I want to spend all my time documenting someone else's work, but when I need to learn about something, documentation is invaluable. No, it isn't as fun as writing code, but that doesn't make it useless. If someone else wants to contribute to FOSS and isn't a coder, but can do tech writing, I for one would appreciate their contribution to documentation.

I value documentation as well.

The problem is that the people changing the code out from under the documentation, so that the documentation quickly becomes out of date, or, worse, incorrect and misleading, is those people who are doing that to the code *not appreciating* the documentation effort.

At worst, there needs to be an agreement that things will stay the same for a while, or for at least a major version number, before the documentation goes out of date. And as you've noted with git: when things grow organically and incrementally, it's going to be near impossible to keep the docs in lock-step with the code -- particularly if the only way to make them match up is reverse engineering the code until you know enough about it to document it accurately and completely.

At one point in time, I wrote a rather complete internals book on FreeBSD; but the OS changed out from under the book too quickly, and so it was inaccurate, except for a particular major revision. And even then, there were sufficient differences even in the point releases (to the odd minor version number) that, unless I'd included a CDROM set or DVD with the book itself, there was no way that it was going to be useful for its intended purpose as a college textbook.

So yeah, documentation would be nice, but it's only going to get there as a divided labor effort if we agree to write design documents up front, and then follow a cathedral model for both the docs and the code that come out of those designs.

I think one of the major problems is that when you make something understandable by documenting it ... it makes it a whole lot easier for someone to step in and know how to "improve" things, until the docs are out of date again. At least, that has been my personal experience.

Comment Documentation is rarely valued as a contribution. (Score 2) 685

If women don't care about making code faster and more compact, maybe they should work on other aspects of FOSS. For instance, most of it could use a lot of help in the documentation department.

Documentation is rarely valued as a contribution. We specifically had to go out of our way to hire a technical writer for Mac OS X to get the man pages covered for the UNIX Conformance requirement. And those were just command line commands, Libc, and the kernel interfaces that had coverage requirements.

It's definitely not valued nearly as well as code. The most common comment with regard to it is advice to "RTFS" and some variant of "If it was hard to write, it should be hard to understand". This is seen in the tools, as well. For example, git is written in such a way that you pretty much have to understand all of it to use any of it. This steepness of the learning curve appears to be intention, and viewed as a merit badge for when someone gets their head around it and Groks it. In the same way that you can do anything in Perl in half a dozen or a dozen different ways, the same is true of git.

Also, your verbal vs. visual thinking bias is showing. Personally, I process software in the same part of my brain that does auditory processing of music (meaning I have a hard time coding if I'm listening to music, as verified by FMRI of the dorsolateral frontal cortex and inferior frontal gyrus, Broca's, and Wernicke's areas, among other areas). Language centers tend to be common for processing both sound and software in many coders.

Ironically, if you are good with languages, you tend to be good with code as well, assuming you have a number of computer languages under your belt to generalize from. But if the tools have a crappy learning curve, then it takes a bit of OCD to be willing to invest the time necessary to overcome it. Staying overnight in a computer lab so that you can get time on the machines is not something most people do these days.

What this country needs is a dime that will buy a good five-cent bagel.