Hacker News Reader

Just to clarify - it's not illegal to sell GPL'd code, so long as you provide the source with the binary.

In fact, this is exactly what happened with Dosbox Turbo (https://play.google.com/store/apps/details?id=com.fishstix.d...). Dosbox is licensed under GPL, but here it's still being sold on Google Play. The author, fishstix, will send you the source if you've paid for the binary. This is completely legal.

https://sites.google.com/site/dosboxturbo/gpl

There were a couple of good discussions on this on SlashDot and VOGONS:

http://yro.slashdot.org/story/12/12/09/1721200/ask-slashdot-...

http://www.vogons.org/viewtopic.php?t=34107

What happens if your software haves 2 binaries that talk to each other and one of them contains the GPL'd code; can I just give the code for that one or do I have to release the source of both?

It's a bit of a grey area, but the FAQ states that so long as they're kept separate, and they communicate "at arms length", they should be ok:

https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySy...

http://programmers.stackexchange.com/questions/110380/call-g...

Disclaimer: IANAL

Sooner or later, laws will get interpreted by a judge/jury. You question is equal to asking at what point a work should be considered a derivative work.

The answer is sadly quite blurry, and country specific. US law say something like: "A “derivative work” is a work based upon one or more preexisting works, such as ... abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted."

What would a judge say about two separate programs that talk to each other? A lot of people and companies has their opinion about it, but there is not much of case law in existence. All one can say is that the GPL author does not consider IPC level of communication to trigger a derivative work.

> Just to clarify - it's not illegal to sell GPL'd code, so long as you provide the source with the binary.

This is, however, not much of a business model, because the customers get the code under a license that allows them to redistribute it. Your first customer could buy the binary and then start selling it on Google Play themselves or give it away to everyone. Selling GPL code is pretty much just syntactic sugar over asking for donations.

True. It's not illegal, but it's not a particularly good business model!

You underestimate the friction there I think.

Conversely you could also argue "it's not much of a business model to sell apps on app stores, because Chinese companies will copy and resell your app".

In my experience, dealing with GPL software that was sold for $5k+ -- no one ever bothered doing so. And this was a PHP app, so it's not like distribution would be difficult for the would be pirate, nor was there any copy protection. It's just, for those sorts of products, no one ever bothered. I thought it was interesting.

Could you really classify someone who has a GPL enforced legal right to distribute your code a 'pirate' though?

I'm not sure you can really classify someone who has no right to distribute your code a 'pirate' - real pirates kill people. Your point stands, though, to be sure.

Real pirates often try as hard as possible not to kill people. Crew are usually worth more money alive. If you do kill someone, often you get fined by your captain and have to continue piracy to work off the debt.

So real pirates and music "pirates" share that it's not their goal to kill people. The latter still kill far fewer people, and the former still engage in much more violence.

Sorry, I'm just being horribly pedantic, but I suspect that music pirates kill far more people than real pirates, purely because so many people are technically music pirates, wheras the real pirates are very few in number and are also quite likely to be pirating the latest sea-shanties, so there is a lot of overlap.

Sure, to be more precise... "real pirates are disproportionately more likely to kill people by virtue of being real pirates; the same is not true of music pirates."

Eh, I couldn't be bothered thinking of the right word, but I'm sure you knew what I meant :)

Well, I could guess your sentiment even though I thought it was wrong.

It just made me think of those stupid 'you wouldn't steal a car' ads before movies and I thought I'd point out that they have every legal right to re-sell GPL code if they want.

My feeling is that the fairness effect comes into play strongly with open source distribution models. People are willing to play fairly (i.e. not re-distribute source code that's probably only a google search away anyway) when the author does the same.

Frans De Waal demonstrates an experiment with Capuchin Monkeys showing this effect in action.

http://www.nature.com/nature/journal/v425/n6955/abs/nature01...

http://youtu.be/lKhAd0Tyny0

You can only strictly expect to sell the first copy. That's not a problem if selling the first copy covers your costs (contract work), but that can sometimes be a business model.

The QP framework does this through dual licencing, so they sell a commercial version of exactly the same code that they also release under GPL.

http://www.state-machine.com/licensing/faq.php

I was pondering what the key psychological difference between "product" and "infrastructure" is – why are people willing to pay for one and not for the other? I'm not sure, but I think that for products polish is paramount, whereas for infrastructure, maintainability is paramount. Proprietary software is a nightmare for installation, deployability and maintenance, whereas open source is great. This is why open source has won the hearts and minds of people who build and deploy websites and other computing systems everywhere while companies producing polished products still rule the desktop.

> The GPL was designed on the premise that it would be necessary to legally force people to contribute changes back

This is the rationale Linus gives for using GPL: Wanting to let people use your stuff while requiring them to give you access to any modifications. However, Richard Stallman (who wrote the GPL) has been very explicit that it is not the premise behind the license and that he disagrees with Linus on that point.

The premise behind GPL is to promote freedom[1]. In short, to ensure that the user always has complete control over the software they run. GPL ensures these freedoms, while permissive licenses that allow distribution of derivative binaries without sources do not.

[1] https://www.gnu.org/philosophy/free-sw.html

The argument that software that you're not allowed to use in certain ways is somehow more free just doesn't pass the sniff test for me. RMS's rationale is very much an "ends justify the means" argument: it takes away immediate freedoms to promote freedom at large. My point is that for many kinds of software the means of imposing legal restrictions simply isn't necessary to achieve the same ends – the freedom of the software maintains itself just fine for technical rather than legal reasons.

GPL ensures that your fork's users get the same freedom to use the software that you get from the original/base... If you don't like the license, don't use it. There are plenty of people that don't use any commercial software if they can avoid it.

> GPL ensures that your fork's users get the same freedom to use the software that you get from the original/base...

That phrasing presumes that the existence of a fork is not determined by the license terms.

GPL guarantees that the would-be users of a fork that would have been made by someone not interested in (or able to, because of conflicting requirements necessary to actually produce the fork in question) providing Free software on the particular terms in the version of the GPL used by the particular upstream provider on which the putative fork would depend get nothing at all.

Well, the way I understand RMS's fomulation of the 4 basic freedoms is that the right to keep your code secret is a freedom of the individual, not of the software, because no one can enjoy software that they couldn't have had if that right hadn't been granted. On the other hand, removing this right "frees" the software. You see, the FSF is all about "free software", not free people. Only indirectly do the people benefit from the software being free.

More practically, history has shown us that the GPL is necessary in order to ensure that companies don't short the community, suddenly improve everything and leave us with 99% of people using the proprietary fork. To illustrate my point, the clearest example (and the only large one) is the free distributions of BSD, mainly used by companies developing proprietary forks for it and contributing back very little. On the other side is Linux, used by companies for its freedom, security and reliability. The companies using it contribute back because they have to, continually making it stronger and always remaining free (unlike BSD, which can have many proprietary and untrusted libraries which cannot be used with security or reliability in mind). Linux is therefore getting larger only thanks to the GPL and its strong enforcement.

And this example can be applied to the entire copyleft vs permissive license debate, showing how software being free benefits the people more than people being free.

While it doesn't really changes the conclusions, you're a bit off the mark.

The FSF is about free people. Free software is just a mean, and they will use whatever licenses they think promotes freedom the most. That's why the GNU C standard library is in LGPL: the GPL itself would have prevented GCC from becoming popular, resulting in less freedom for the people. Also, looking at the history of GCC and the Hurd kernel, you can see they don't limit themselves to licenses.

You seem to imply that the GPL forbids you to keep your code secret. It doesn't. The right for private modification is preserved by the GPL. Only public modifications must be distributed in source form.

Companies don't contribute back to Linux because they have to. First, it's often more cost-effective to push changes upstream than maintaining them yourself. Second, monetizing private changes with GPL software is very very hard when the main distribution channel is gratis. Third people like to be good citizen. If I do changes for my company, and my company cannot possibly monetize the secrecy of those changes, why not contribute back?

If people and companies were forced to contribute back changes, they probably wouldn't use the software in the first place.

Now yeah, Linux is indeed larger than BSD thanks to the GPL.

you're not allowed to use in certain ways

What ways would those be? In what way does refusing to contribute the source code to your modifications qualify as using the software in certain ways?

> What ways would those be?

In the case of GPLv3, the development of software for hardware devices that are tamperproofed -- unless those devices are intended for "business" rather than "consumer" markets. [1]

The GPLv3 restricts the features of products made with software licensed under it based on how the products are intended to be used.

[1] "business" and "consumer" are rough descriptions, the actual definitions are more complicated and are contained in the GPLv3.

In the case of GPLv3, the development of software for hardware devices that are tamperproofed

This is not true. All the GPLv3 requires is for you to provide the means to modify or replace the software contained in the device. In the case of a tamper-proof device, this would entail providing the user with a master key or password which would allow her to unlock a developer mode of some kind.

Alternative, a tamperproofed device can be immune to any form of modification or replacement of the software contained in the device.

The issue GPL fixes is when device manufacturers exercise ownership control of the device after sale (ie, do things that the owner is not allowed/enabled to do). If the manufacturers can modify or replace the software, then the device owner must be able to do the same.

Alternative, a tamperproofed device can be immune to any form of modification or replacement of the software contained in the device.

Sure, you can develop one of those, as long as you subsequently provide a means to circumvent the tamper-proof mechanism. There is a critical semantic distinction that I think a lot of people are missing: the GPL does not restrict your ability to develop any sort of product you wish, it merely imposes additional obligations designed to ensure your users have the same freedom of development that you had when you developed the device.

> Sure, you can develop one of those, as long as you subsequently provide a means to circumvent the tamper-proof mechanism

No, you do not need to add a way to circumvent the tamper-proof mechanism. Thats the whole point of my comment.

Section 6, Conveying Non-Source Forms: "this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM)."

If the device is completely immune to software modifications, the anti-drm requirement of GPLv3 won't come into effect.

Last, a device which the manufacturer has ability to tamper with is not a device I would call tamper-proof. The attacker just need to get the developer key, so maybe Tamper-resistant is a better description?

If the device is completely immune to software modifications, the anti-drm requirement of GPLv3 won't come into effect.

Right, I had forgotten that. The reasoning behind it is that a non-programmable ROM chip might just as well be considered hardware for the purposes of programmability. Of course, the user might decap the chip and modify the code stored there with a scanning-tunneling microscope so the term tamper-proof in the absolute sense is probably not applicable to any device made by humans.

There is an old saying in computer security that the only secure program is one that is in a computer that is turned off, locked inside a safe, located in a bunker.

So maybe tamper-proof is not the best term, but at least physical security add something more than just a digital signature. The device owner has a much better chance to see if someone took apart the device, decapped the chip and then put it together. If I as the consumer want a tamper-proof device, I would go with physical security every time.

I guess you didn't read my post higher up. You cannot redistribute software that uses both GPL libraries and proprietary libraries. This is not an academic concern: we cannot distribute Julia with Intel's MKL even though we have developer licenses because we also use some GPL libraries (readline, FFTW) – the result would have to be GPL but we cannot provide the source for MKL because we don't have it. Lots of people would be very happy if they could download Julia and just flip a switch to choose between OpenBLAS and MKL; we can technically do that but we can't legally do it because of the GPL.

You cannot redistribute software that uses both GPL libraries and proprietary libraries.

But is redistribution a use? I would say no.

There is a way: acquire a GPL licensed copy of MKL.

Okay, you can't. Well, this is a textbook example of the GPL discouraging people from distributing proprietary software, and seeking free alternatives instead. This is its exact purpose.

I feel somewhat sorry for you, but this looks like a net win.

RMS's rationale is to protect the freedoms of the end users of the software: The freedom to run the software however you want, the freedom to modify the software however you want and the freedom to distribute your modifications of the software to whoever you want. The rationale is to ensure all users of GPL software have those freedoms.

The only restriction is that you cannot remove any of those freedoms from any users of your derivative works. That restriction is enforced by the license.

For example, if you create a derivative work, as long as you keep using it only yourself, you're not required to give the sources to your modifications to anyone (you are the only one using it and you have all the freedoms). However, if you wish to share your derivative work with someone else (which you always have the freedom to do), you cannot limit that user's freedoms. You cannot, for example, refuse to give them the source code because it would take away the user's freedom to modify the software. You also cannot attach a proprietary license that would remove the user's freedom to distribute copies of the software to whoever they want.

> The argument that software that you're not allowed to use in certain ways is somehow more free just doesn't pass the sniff test for me.

Intuition. If I may, you should learn to "shut up and multiply"[1]. The various costs and benefits (in terms of freedom) are pretty much nailed down: freedom at large is simply way bigger than immediate freedoms, for a simple reason: the only freedom the GPL doesn't give you, is the freedom to further restrict your users. (Contrary to how most comments are worded here,, you don't have to contribute back changes. You have to contribute back public changes.)

The end doesn't always justify the means, but sometimes it does.

[1]: http://wiki.lesswrong.com/wiki/Shut_up_and_multiply

"You have to contribute back public changes."

Even that isn't strictly true - you only have to contribute forward public changes. Of course, since your users have the ability to share things, and since your changes are probably "out there" you might as well contribute them back at that point and doing so usually eases development.

> ensuring that only the original author can sell forks of the product

I consider this the absolutely worst reason to use the GPL. Quite a few companies (large companies like MySQL/now Oracle or small ones like Macromates) require contributors to sign an agreement that allows the company to distribute the code under a different, proprietary license.

Doesn't this circumvent everything the GPL stands for? If I contribute to such a project, what guarantee do I have that the owner doesn't just distribute the software, including my contributions, under a proprietary license and stops making improvements public?

You don't. And that's why people stop contributing to such projects and forks are created (see MariaDB). But that's not really a fault of the GPL. You could require contributors to agree to whatever you want regardless of the license you choose. Contributing to proprietary software (often as a result of an employment) sure comes with requirements other than the code itself.

I didn't mean to imply that it was a good thing that the original author could sell forks but rather that it was better that only the original author(s) could. This is one of the reasons I'm not fond of CLAs (contributor license agreements) and why Julia doesn't have one – the code belongs to the whoever wrote it and we can't relicense their contributions any more than they can relicense ours.

>> ensuring that only the original author can sell forks of the product

> I consider this the absolutely worst reason to use the GPL.

I think rms is right here. Selling exceptions is a good thing. It's certainly no worse than selling proprietary forks of non-copyleft free software:

http://www.gnu.org/philosophy/selling-exceptions.html

Why would it be ok to take non-copyleft software like clang and make proprietary forks with it, but not ok to sell exceptions in order to fund copyleft software?

EDIT: As an Octave developer, I greatly respect how FFTW's copyleft is used, for example. Matlab buys a license exception to use FFTW. Octave gets FFTW under the terms of the GPLv3, just like Octave itself, which we in turn contribute back to everyone else. Matlab and Octave are both using the exact same library for Fourier tranforms.

I like this model. Everyone is paying one way or another, no freeloaders, just lots of freedom.

Thanks for the link, those were some good thoughts on the topic. However, I disagree with Stallman. (probably because I make a living from selling something that he might call a 'proprietary extensions')

I think the problem I have with the practice of selling exceptions is that it gives more rights to the owner. I feel that open source licenses should give equal rights to everyone. Dual licenses undermine that equality. I understand that people want to stay in control of their software, but for me the words 'free' and 'open' somehow imply 'equal rights for everyone'.

I see. You would like it if anyone could sell exceptions, not just the copyright holders. Hm. I'd have to think about this.

This is what permissive licenses allow for.

But they provide no hard incentive for someone to pay in order to benefit non-freely from free software. I prefer to attack the problem from the point of view of figuring out what proper revenue sharing would be with copyright assignments. What the MIT guys are doing with FFTW is doing is good. What Oracle is doing with MySQL and Virtualbox is bad.

I'll ask the FFTW guys what do they do about external contributions.

Also, thinking about it more, there is nothing wrong with copyright holders having extra rights as long as they do not use these rights abusively. After all, they did the work, so they deserve to be compensated for it. Nobody would dispute that. It is problematic if they use these extra rights to try to make people pay for proprietary software that is not otherwise available freely. This is what I dislike about what Oracle does.

> After all, they did the work, so they deserve to be compensated for it.

The problem is that many Open Source projects aren't created by an individual, or even a single company. Large projects have hundreds of contributors. If a project requires copyright assignment, all these contributors have fewer rights than the maintainer of the project.

If a project doesn't require coypright assignment, and uses a single license, all contributors have equal rights to the collective work.

> The problem is that many Open Source projects aren't created by an individual, or even a single company. Large projects have hundreds of contributors.

It's some sort of empirical law that almost all of the code in free projects is written by at most a handful of all contributors. If this law holds, and I can think of only few examples where it doesn't, it seem fair for the tiny minority to benefit the most from selling exceptions.

What the FSF does when requesting copyright is a two-way agreement. The FSF drafts a contract that promises that they will never use the copyright aassignment for creating non-free software. Similar contracts could be drafted that agree to share revenue proportionally and provides clauses for arbitration if this proportion is in dispute.

The GPL is meant to preserve equal rights for everyone other than the owner. A more permissive license allows freeloading, while the GPL does not.

I wasn't talking about GPL, but the combination GPL+copyright assignment.

> If I contribute to such a project, what guarantee do I have that the owner doesn't just distribute the software, including my contributions, under a proprietary license and stops making improvements public?

None. But if they do that then you can fork the latest free release and carry on improving that (e.g. OpenOffice -> LibreOffice), and from then on the company's version receives no more contributions from the community.

And it's unambiguously better for the principles of the GPL than the alternative of licensing the project under a BSD-style license and requiring contributions to be made under such a license, which allows not only the original maintainer but anybody whatsoever to do the thing you're objecting to.

| Using a viral open source license like the GPL

A common misconception. Copyright law is viral.

> For projects like libraries, compilers or programming languages, it turns out that proprietary forks don't happen because of simple economics.

Apple's/NeXT's compilers were a high profile counterexample for many years.

Great post!

For those interested, GNU's Lesser General Public License (LGPL) was created to address these concerns.

It's not a particularly good one unless a static linking exception is included (dylibs on OS X are a pain for no serious benefit, it's not viable at all on Android or iOS).

LGPL is just fine in this regard – you can ship with and link against an LGPL library together with proprietary libraries because the combined result need not be under the LGPL. Whether you link dynamically or statically is irrelevant from a legal perspective.

Except that's not actually true. See, the point of the LGPL is not just that the user has access to the source, but that the user can modify the source and run it. Dynamic linking allows the user this freedom. Static linking generally does not, so unless you provide a way for users to delink your binary then you have to distribute the entire binary as LGPL.

The parent poster is talking about static linking against a third-party LGPL library, not your own library. In such a case, failing to provide the complete source code, or the original compilation dependencies (.o, .a, .so) and the build chain, is very much against the LGPL.

(Edit: I can't seem to quote the LGPL section 4, so here is a link to it: https://www.gnu.org/licenses/lgpl.html#section4)

There is a massive reluctance in the QT community over this currently -- people want to distribute single-binary applications, and they are told to be careful about doing it.

This exactly. And you straight-up can't do it on Android or iOS.