Bruce Perens On Combining GPL and Proprietary Software 218
jammag writes "Combining GPL and proprietary software is ever more common, especially in the world of embedded devices like cell phones. But the question is: how to combine them legally. As sticky as the issue is, there is an answer, as self titled "open source strategic consultant" Bruce Perens explains. The proper procedure entails fully understanding what type of open source software you're using, and knowing why you need to combine these disparate licenses. The problem, he notes, is that many companies don't know or care about doing this legally. 'They're used to just "clicking yes" with no regard to what they're committing themselves and their company to.' Hopefully Perens' guide can be read by more company execs — resulting in fewer lawsuits going forward (but we're not holding our breath)." update 21:31 GMT by SM: Bruce wrote in to make sure we knew he was not a lawyer, even though he is weighing in on a legal issue; updated to reflect.
Commitments? (Score:2, Interesting)
> no regard to what they're committing themselves and their company
Most employees aren't legally empowered to commit their company / organisation to anything. They don't have the authority to sign contracts on behalf of the company / organisation.
Re:Hi (Score:3, Interesting)
Any comments about the applicability of the LGPL? It used to be very popular in embedded systems.
Header files (Score:3, Interesting)
Can you #include header files from GPLed code in proprietary code?
Malice or stupidity? (Score:3, Interesting)
They're used to just "clicking yes" with no regard to what they're committing themselves and their company to.
This is a very subjective question for you to answer (so feel free to say "I'd rather not speculate"), but my question is: When these companies disregard the license, is their primary reason for doing so stupidity or malice? Is it usually because someone mistakenly thinks "hey, this is available online so I can do whatever I want with it" or is it more along the lines of "no one will ever catch me, so I'm just going to grab this code."
In any case, thanks for all your hard work for the community!
Tried and failed (Score:1, Interesting)
A while ago my company contacted the FSF with regards to some questions about correctly integrating some GPL and LGPL software with our own software. We got the runaround over a few e-mails with the FSF, and nobody ever got back to us. It would help if they would be more responsive when companies are *trying* to do the right thing. In the end we just gave up and wrote all the code ourselves, which was less full-featured than using the GPL software, but kept us on the right side of things. Very frustrating experience overall.
Re:Execs aren't going to read this (Score:5, Interesting)
When I visit a company to help them develop their Open Source strategy, I schedule a 50-minute talk for the top execs and the head of legal. This talk tells them what I am doing with the middle management, gives them some anti-propaganda to reset their opinions and expectations about Open Source, and establishes who I am working with in the company so that when they have issues about Open Source they know where to go.
That's about all I can get out of the top execs. But I get a lot of attention from the middle management folks who actually do the work.
Some of the recent lawsuits have got their attention. But what it often does is cause them to put a "no open source" clause in their default supplier contract. I signed a contract with a big phone company that promised I would not give them any Open Source! Of course, I was giving them advice.
Bruce
Re:easy answer (Score:5, Interesting)
It sounds easy, but it is actually very difficult to keep from distributing. You see, a distribution is a transfer between any two legal entities. So, for example, you hire a consultant and give him a copy of the software. Then you decide not to use the consultant any longer. He's annoyed, and he asserts his GPL rights on your entire product, and distributes it. You go to sue, and the copyright holder of the GPL piece gets involved and makes a case that you don't have the rights you think you did. Your NDA does not apply to GPL software because GPL prohibits you from adding incompatible terms.
In some cases, transfer between divisions, especially partnerships with one or more additional firms, are distribution. So, in practice, I think that purposefully not distributing is too difficult to do reliably. It also does not work against Affero GPL3. If you perform that as a service, you have to give up the source code.
So, it is much easier to keep your software separate as I advise.
Thanks
Bruce
The silly multi-processor workaround (Score:5, Interesting)
(AC because I work on what I'm talking about, and this problem hampers me continuously, at my current job and all previous).
I am dismayed that this is a possible loop-hole to the GPL. There is a very real examples of this today: the T-Mobile G1, and its slightly-unlocked Developer handset counterpart.
The trouble is, these devices are completely unusable without the binary blob loaded into the other processor. A lot of the functionality is still inaccessible, and worse still the manufacturers can get away without even providing a data sheet. Even worse still - these devices can be totally locked down, signed, and remove the ability to replace the GPL parts.
It's self-reinforcing, too. The ARM9/ARM11 split (in this specific case) is an increasingly inefficient thing to do, as ARMs are very good at low latency response (FIQs), and the partition is NOT as simple as multiple processors. In the Qualcomm MSM7200 part used in the vast majority of handsets (including the G1), it's another core and they share RAM and all peripherals. There's an awkward memory partition that has to happen, and that's inefficient use of memory. There's a duplication of ARM pipelines and caches. It's not as efficient as people would have you believe.
In short, it's a bad use of hardware resources just to work-around licensing.
I hold out little hope that manufacturers will provide access to radio layers, unlock devices, and generally provide data sheets so long as the "it's on another processor" work-around is an acceptable solution. Perhaps market forces will change their mind as soon as one big player decides that the hardware cost is no longer worth it. Perhaps not.
To be honest, though, I'm slightly happier that there is the workaround and we can see GPL software in handsets, rather than nothing at all.
Are you actually happy with this solution (or only somewhat happy, like me!), or is it just a recommendation?
Re:Hi (Score:3, Interesting)
What constitutes derivative works of GPL'd code?
Why is it that using a code's API makes something derivative work, but using a program's CLI is non-derivative work, and even allowed to be non-GPL?
Two processors (Score:3, Interesting)
I don't understand why you need 2 processors to combine proprietary and GPL code. Anything that can be done on two processors can be done on one processor at half the speed. So obviously, you don't need 2 processors.
So maybe using 2 processors makes it easier to combine proprietary and GPL code. Why and how? Are you arguing that code that runs on processor A can not possibly be a derivative work of code that runs on processor B?
Re:GPLSoftware in Consumer Products (Score:5, Interesting)
Some folks have written GPL equivalents without the preamble. They've not become popular. The problem these days is not really the GPL. It is that there have been thousands of meaningful court cases about software creating precedents helpful or harmful, and there is a lot of rather pernicious legislation like DMCA. So, we have to craft a license that will protect us from a tower of existing legal paper higher than I can figure. The fact that you can still read it in one sitting is pretty impressive. If you read the findings in recent court cases, especially the appeal in the JMRI case, it's pretty clear that judges like the GPL. And that's what we really need. If it doesn't protect you in court, why is it there at all?
Bruce
Re:IANAL (Score:3, Interesting)
Does anyone know why we always give those "IANAL" disclaimers?
In the United States, it is not legal for anyone but an attorney whom you have retained, and who is admitted to the applicable Bar Association, to give you legal advice.
How far does that go? I mean, in the extreme, wouldn't that mean it's illegal for a cop to tell kids that they need to obey the speed limit?
I guess what I'm asking is what rules, if any, prevent that (absurd) example from being actually illegal?
Dual licensing is good (Score:4, Interesting)
While the GPL purists might balk at this, it does make the product usable elsewhere (more usage == more testing == good for everyone) and also provides a revenue stream to help further development (good for everyone).
Being practical is far more important than being purist.
Re:IANAL (Score:4, Interesting)
There's a good explanation in Wikipedia:
Re:The silly multi-processor workaround (Score:5, Interesting)
Re:The silly multi-processor workaround (Score:3, Interesting)
Standard telco / WiFi manufacturer FUD... The responsibility to obey FCC regulations rests on the user of hardware, not on its manufacturer. There is no FCC-mandated obligation to lock down hardware. This is pure blithering bullshit from hardware companies that use this lie as an excuse not to publish datahseets, lock up functionality in binary blobs, lock down devices, break GPL (if not legally then at least in spirit), and generally be total assholes.
Re:The silly multi-processor workaround (Score:3, Interesting)
In general, FCC does not license manufacturers to sell transmitters until FCC issues a type approval. The purpose of the type approval is to assure that the device would not radiate unlawfully. There are a few exceptions: you can build your own equipment in the Amateur (ham radio) service, and I think some Part 15 (low power unlicensed) equipment.
Bruce
Re:easy answer (Score:3, Interesting)
You can develop a modified version for your consulting customer under an NDA in which you agree not to distribute your then-proprietary modification, because (in theory) you are not giving the customer any GPL software, only stuff that is proprietary at that time. But if either party gives the other BOTH the GPL software and the modification, together, then the NDA doesn't apply to that transfer and the whole thing is under the GPL.
In FSF's place I would not have given such a pat answer. I think this is harder to comply with in practice than they make it appear.
Bruce
Re:Hi (Score:3, Interesting)
Re:Hi (Score:4, Interesting)
The BSD license is GPL compliant, and you can link BSD and GPL code together. It's only licenses that make restrictions that the GPL does not make which are incompatible. The problem with allowing restrictions that the GPL doesn't make is that at some point you get enough restrictions it's not Open Source / Free Software any longer. While you can trust a license to always say the same thing, OSI has not always said the same thing and doesn't promise to do so in the future. So, "any OSI approved license" could be anything at all, at some time in the future.
Bruce