Journal tomhudson's Journal: Taking a GPL project closed-source in 3 easy steps 8
The FSF is at it again - claiming that usage of the GPL is on the rise, when its' share of the market is declining, both in F/LOSS, and in the larger software ecosystem.
So, time to let everyone in on a little secret - any gpl'd project can be taken closed-source by anyone willing to go through the exercise.
Summary
Copyright law only protects a limited portion of all creative works. What I mean by this is that neither portions of copyrighted works that lack creativity, nor those parts that are "scenes a faire" ("there's only one way to do it") are protected. APIs, for example, are one such "scenes a faire".
Remember the "linux headers" FUD the FSF put out? Even Linus agreed that the headers, simple macro definitions, enums
3 steps
1. replace all artwork, comments (comments are expressive, and as such, protected by copyright);
2. rewrite all function bodies that are not "scenes a faire"
3. PROFIT! (maybe).
You can release the result under any license you want - and you don't have to distribute your source. Better yet, you also maintain binary compatibility with the original.
Why?
Business A develops GPL software and sells support. Business B doesn't have the overhead of developing that software, so they spend the money and resources saved on things like marketing the crap out of how they are better at it, and developing a few plugins that require server-side services that only they provide.
So Business A says "the heck with this", does what I propose, forks their own software, and releases a new closed-source version that breaks only Business B's code.
Why wouldn't they?
More importantly, why wouldn't B do this first, as a preemptive strike? Once you have a "good-enough" code base, you don't really need community support for further development. In fact, releasing code "to the community" is now where software goes to die. It's the digital "elephants' graveyard."
There's really nothing legally preventing anyone from doing this and being able to sell the resulting code over and over again. Both businesses and consumers are used to that sort of arrangement.
So, can we expect to see a linux "clone" by the end of the decade? I doubt it - there's no need. BSD already runs linux programs. But I do expect to see closed versions of many open-source programs pop up once a few test cases make the rounds.
It's already being done
Sony is making a busybox clone, and there's nothing that can be done about it. So, people have a choice - do it themselves before companies like Sony do it and reap all the profits or stick their heads in the sand. In the age of "good enough computing", if it's "good enough" to clone, it's "good enough" to take private.
In other words (Score:2)
A complete rewrite.
Sure, you could do that. But at this point it'd be really easier and more convenient to rewrite from scratch.
Re: (Score:2)
Second, you get the advantages of compatibility with add-ons, plugins, etc., for free.
Third, you get binary and user compatibility, so you can get access to current users.
Fourth, unlike the open version, which even the original devs would have a hard time making money selling the code, you're free to optimize and sell the resultant binary code - "100% compatible but 30% faster!" Or "we've removed over 400 bugs compare
Re: (Score:2)
"just", yeah.
Also a lot harder than you think. GPL code is still under copyright. To protect you against chances of infringement, you'd have to pretty much start by reimplementing the app by following a header file, and spending a lot of time wondering "WTF does this function do?", "what does this function return when passed a null pointer" and "Argh, this part is horribly ugly".
It can be done, but it's a pain in the ass, an
Re: (Score:2)
Look at the current situation - how many forks of forks of forks are there out there? Nobody has a financial incentive to actually come to a concensus and fix the problems - they just make a fork and "scratch their own itch." Over the long haul, this is simply unsustainable from a financial point of view.
Under this scenario, who cares about the 95% that won't pay - they get the buggy original that is too busy adding new features to fix the existing bugs, because they're competing for "mind share" and not
Re: (Score:2)
I'm not entirely sure I follow the argument here. Are you talking about dual-licensing, as a means to secure a revenue stream, and to pre-empt someone forking the code and blowing off open source entirely?
Re: (Score:2)
Right now, there's this terrible tendency to fork, fork, fork - and every fork is competing for eyeballs, mindshare in the noosphere, or whatevr you call it. And they're all mostly starving for revenue, because there are just too many choices, and the quality is pretty much the same among all of them.
So, you created a game as open surce, someone else forks it, now you're both competing for code contributions (after all, there's no guarantee the fork will stay code-co
Re: (Score:1)
Or you can just *claim* that you did all that. ;-)
-- from Philip K. Dick's Scanner Darkly:
“—this guy,” Luckman was saying, manicuring a box full of grass, hunched over it as Arctor sat across from him, more or less watching, “appeared on TV claiming to be a world-famous impostor. He had posed at one time or another, he told the interviewer, as a great surgeon at Johns Hopkins Medical College, a theoretical submolecular high-velocity particle-research physicist on a federal grant at H
Re: (Score:2)
You don't have to claim it when in many cases it's not all that hard to do. One of the side benefits is that you can clean it up, make it run faster, and have fewer bugs - all selling points.
I think it's time for projects that are GPL to consider doing this themselves - create a for-profit derivative (not all derivative works infringe copyright) and use that to subsidize the open version.
It would reduce the insane number of forks we have, as well as improve quality overall.