Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Taking a GPL project closed-source in 3 easy steps

tomhudson (43916) writes | more than 2 years ago

Open Source 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

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 ... they simply are not protected. The same rules applied to Google using Apache Harmony - java class names and method signatures are not protected. They either lack the necessary creativity, or there is only "one way" to do it.

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.

cancel ×

8 comments

Sorry! There are no comments related to the filter you selected.

In other words (1)

DaleGlass (1068434) | more than 2 years ago | (#39234803)

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:In other words (1)

tomhudson (43916) | more than 2 years ago | (#39235063)

First, no, it would not be a complete rewrite. Pretty much just the function bodies.
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 compared to the original."

There are plenty of scenarios where a decent improvement in performance or a reduction in bugs would justify purchasing a closed-source version over an open one.

Re:In other words (1)

DaleGlass (1068434) | more than 2 years ago | (#39235199)

First, no, it would not be a complete rewrite. Pretty much just the function bodies.

"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, and coding your own app is a lot more enjoyable.

Somebody actually threatened me with your exact scheme once. 5 years later it has yet to materialize.

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.

Until development diverges, that is. Users mostly keep using what they were using before. You're going to provide something more impressive than "what you had before, only now you have to pay for it!"

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 compared to the original."

So you get a few corporate customers maybe. 95% of the userbase won't really care. See how many normal people (ie, not companies) bother with paying for RHEL vs the marketshare of the other distributions. Heck, most companies use CentOS when they can get away for it.

Your bug fixing and improvements probably will require changing the ABI.

Re:In other words (1)

tomhudson (43916) | more than 2 years ago | (#39242491)

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 revenue. The 5% that would pay get the stability they want. It's what RedHat does, and it works. How much is CentoOS pulling in, by comparison?

Also, when you can offer a 30% speedup, there are lots of scenarios where this would be incentive enough, just in hardware and energy savings when it's time to scale up.

Now let's take another scenario - a simple game. The open version is dependent on charityware ... the closed version can actually devote time to making add-ons and bug fixes (which they don't have to give back - but they might as wel, at least until the two fork too far apart to be compatible). Eventually, the original will look like a cheap knock-off ...

If the only way to advance a product is to close it off, it is what it is. This provides a way for developers to take their own product closed as a "pre-emptive strike", so that they can maintain both a closed and an open version. If they'd rather wait until someone else eats their lunch, that's their decision.

Re:In other words (1)

FoolishOwl (1698506) | more than 2 years ago | (#39244443)

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:In other words (1)

tomhudson (43916) | more than 2 years ago | (#39247075)

I'll try to explain it a bit better.

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-compatible as time goes on), so the fork eventually results in the pool of contribs you can use going down, nt up.

Also, your user base goes down, since it's now split with the fork(s).

So, you take and make a closed version, fix all the bugs in the closed version while improving the code, and release it as closed-source. You weren't getting the relevant code contributions anyway, so you don't really care. You'll continue to benefit from artwork and plugins (you've maintained binary compatibility), so now you can compete again.

More importantly, you can now sell the program on a per-copy basis, generating the revenues to continue development if the game is any good.

Both your old code base and the open forks can continue to exist, and you can even maintain the open version of your code if you so choose - that's your choice.

The problem is that open source isn't competitive for most projects when it comes to the financial side. Which is why there are so many bugs out there - nobody is being paid to do the dirty work of fixing them. In terms of percentages, open source is actually losing ground - compare the explosive growth in paid closed-source apps in the mobile field. Why? Follow the money ...

It's either adapt or die. I don't see any other way if improving the quality of the stuff out there, or of reducing the insane number of forks (how many linux distros are there out there now? Over 1,000?)

Re:In other words (1)

iMadeGhostzilla (1851560) | more than 2 years ago | (#39239487)

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 Harvard, as a Finnish novelist who’d won the Nobel Prize in literature, as a deposed president of Argentina married to—”

“And he got away with all that?” Arctor asked. “He never got caught?”

“The guy never posed as any of those. He never posed as anything but a world-famous impostor. That came out later in the L.A. Times —they checked up. The guy pushed a broom at Disneyland, or had until he read this autobiography about this world-famous impostor—there really was one—and he said, ‘Hell, I can pose as all those exotic dudes and get away with it like he did,’ and then he decided, ‘Hell, why do that; I’ll just pose as another impostor.’ He made a lot of bread that way, the Times said. Almost as much as the real world-famous impostor. And he said it was a lot easier.”

Re:In other words (1)

tomhudson (43916) | more than 2 years ago | (#39242525)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>