There are many reasons why enforcing the GPL is a good idea. Jeremy Allison, who has been working on Samba since the early 90s, makes the telling point that "the people who comply are subsidising those who don't. Compliance levels the playing field, and ensures everybody is competing fairly."
Even if this were not the case, there are moral reasons why users should comply. "By not complying you are ignoring the wishes of the people who wrote the code," he says, "and according to Linus' law, 'those who wrote the code get to make the rules.'"
If the user isn't willing to comply with the simple demand to make the code available, he or she shouldn't be using the code, or should be using code that comes under a different licence. "If you compare free software licence compliance to proprietary software there's nothing to it. So don't be lazy", he says.
"People don't comply because it gives them a mild competitive advantage. If you're not employing an engineer whose job it is to ensure compliance you have a small advantage over the company that is employing someone to do that job. It's a job you should be doing, and there is a small cost involved."
Some choose to ignore the licence but most infringements are not deliberate, and can probably be attributed to misunderstanding or ignorance. "People do make mistakes. The point is not to punish people for making mistakes, but to bring them into compliance. When people get into trouble it's usually down to laziness and inconvenience. It's usually a case of 'I can't be arsed, and it's too much effort to do it right, so I'll just use it.'"
In rare instances people have taken the code as their own, even with the BSD licence, "taking the copyright off and claiming they wrote the code themselves."
"But the truth is that if you're a manufacturer and are worried about this issue you're almost certainly not the person who needs to worry."
Obfuscating the code
In the past, Samba compliance work has been handled by Simo Sorce, who also has a regular job working for Red Hat and developing for Samba. "What this does is it allows him to have a framework in place to help him do the work", says Allison. "We still get to decide the actions that are taken. Compliance has not been taken away from Samba. We're still involved, but we get a lot more help."
"It's a service that Conservancy is now providing for us. They have been doing it for BusyBox for years, and we have an even longer history of dealing with compliance issues than BusyBox, because we've been around longer. But its a pain. It takes you away from the stuff you really want to do, and just as Conservancy handles our expense reporting and the other things it does for us, this is just another service that Conservancy helps us with."
Samba has only ever had "one really serious compliance issue, a very long time ago. These were the kind of people who, if they weren't violating copyright on software, they would be stealing the radios out of your car. They were just crooks. They took the code of Samba and put a proprietary licence on it, and started selling it as their own work."
"When they were caught," he remembers, "they tried to obfuscate the code. But because they were morons, they actually had an open NFS server on the internet. This was a very long time ago. So we were able to watch them in real time obfuscating the names of the functions, and periodically burn a CD and say 'Oh. They've got up to here now.'"
"They eventually went away and started ripping off the US government. They came out with a different product which was probably based on somebody else's free software, and started selling it to the government for lots of money. Picking on Samba was hard work because we were going to fight back, so they picked on someone else..."
"That's the only serious issue we've ever had. With everybody else its been, 'Oh, I suppose we need to fix that, don't we?' and they have."
Getting into Android
But non-compliance has a knock on effect, depriving both users and developers of the opportunity to take advantage of changes to the code. Matthew Garrett's take on this is that everyone benefits from compliance because compliance reduces duplication of effort, and opens up other possibilities.
"If I'm implementing support for a part then it's a great deal easier if I have source code for a working driver", he says. "For example, Netgear wrote support for journalled HFS+ filesystems for a NAS device they sold. Someone else has taken that code, ported it to current kernels and is working on cleaning it up for submission to upstream. That developer benefits from not having to write code from scratch, just as Netgear benefited from not having to write a networking stack from scratch."
"And in the past that was probably where users benefited most", he says. "They'd get features faster because developers could use existing code. But I think that's changing now. Android's a wonderful example of this. Phone manufacturers have little incentive to support hardware that they're no longer selling. Given fixed engineering resources, why would any vendor spend significant amounts of time on older phones rather than developing new features to help sell their new phones?" But if the code has been provided, others can get involved.
"And that's one of the reasons that projects like Cyanogenmod are so popular. People can run newer versions of Android on phones that are no longer supported by their manufacturer." This works to the advantage of users because "they get new features, they get compatibility with newer apps, and perhaps most importantly they get security fixes. Given how Android ties into the kernel, that would be almost impossible without GPL compliance."
Garret emphasises that "while almost all the press you see about compliance involves lawsuits, the vast majority of cases are handled entirely amicably and without publicity. The goal is to obtain compliance, not to punish anyone", because "everyone benefits from a Linux ecosystem where compliance is the default, not the exception."
The boring work
Kuhn makes the point that "compliance work is the activity of helping those who have failed to comply with the provisions of the relevant Free Software licences", and is a helpful and friendly process. "Developers pick their licences for a reason", says Kuhn. "Conservancy's GPL compliance work assures respect for the developers' desires and requirements regarding the licensing of their code", and "companies that fail to comply should actually want to talk to Conservancy" to make the process easier.
He suspects that the developers who get involved "will quickly discover what I already know: it sure is boring work to deal with Free Software licence compliance issues, and I suspect they will soon feel like Erik Andersen (of BusyBox) does: he'd rather have Conservancy take care of the boring work so he can focus on other things."
As both Linux and BusyBox are licensed under GPLv2, the compliance issues will be much the same, but Samba's involvement adds a new dimension. "For the first time, Conservancy will also be handling GPLv3 compliance issues, since Samba's licence is GPLv3-or-later."
Not all developers have the same opinion on compliance. But "each copyright holder has a right to assure compliance with his or her own copyrights", and other contributors are encouraged to get involved. Some copyright holders are companies, he points out, and as a non-profit, it isn't appropriate for Conservancy to work on their behalf, although they are welcome to "donate their copyrights".
In conclusion, he makes the significant observation that the "developers who signed up for compliance activity on their Linux copyrights hold enough copyright that the code can't be trivially written out of Linux by someone who doesn't want to comply."
- Enforcing the GPL with Judo moves, a feature by Richard Hillesley.
For other feature articles by Richard Hillesley, please see the archive.