|
|
Subscribe / Log in / New account

A view from the "other side"

A view from the "other side"

Posted Apr 13, 2017 8:23 UTC (Thu) by rakoenig (subscriber, #29855)
Parent article: Defending copyleft

I work as a software developer for a PC company that once in history got sued by Harald Welte for not providing the sources for a router that they sold. Yeah, got some painful verdict and now everyone is afraid that we one day would get sued again for Billions of Dollars, so legal department has been setting up a very strict internal proces when it comes to the us of Open Source software inside our products.

That means, when I develop something that will run on Linux I have to get it through that process. In detail this means:
- checking the license of all included components
- avoiding GPL'd libraries without LGPL or library exception because that would require to publish our source code which contains company IP in some cases
- even checking the licenses of the dynamically linked libraries

I'm a software developer and not a lawyer so this is sort of a bureaucratic monster for me. A real pain in the ass, especially when you need to communicate with people that are not part of your software development realm.

So I want to make my part in that process as easy as possible, but there I start to get into despair. How do you determine licenses? There are tools like Fossology around but at the moment for me Fossology seems like a file parser that hunts for keywords like "copyright" or "license" and just checks your sources, but not the runtime libs.

On the other hand there is a very interesting project called SPDX which tries to introduce license tags for Open Source software so that the process of parsing for licenses information would be much easier to automate. Despite this project that is linked to the Linux Foundation somehow you don't finde much SPDX license tags in the wild. Go to gnu.org and get the latest sources for glibc and start looking around, there is nothing.

Yes, from a software developer point of view I have to confess that I didn't hear about SPDX before I needed to dig for license information because my internal process requested me to do so.

So the message from the "other side" is, yes, companies are struggling to be compliant to the license obligations, but its not easy and the Open Souce developers could make this job a bit easier by supporting those toolchains that try to autmate the process.

Disclaimer: Speaking for myself in this comment, its not an official statement of my company


to post comments

A view from the "other side"

Posted Apr 13, 2017 10:08 UTC (Thu) by xav (guest, #18536) [Link] (2 responses)

Thanks for the insight from the "other side" - and I share your pain, I've been on both sides, as many of us I guess.
But I think the point of Harald's talk was that what was thought to be on "this side" is apparently working for the "other side", and that it's a bit scary.
I'd like to know what e.g. Greg has to say about this (I know you read LWN Greg).

A view from the "other side"

Posted Apr 13, 2017 10:49 UTC (Thu) by armijn (subscriber, #3653) [Link] (1 responses)

I don't think it was Harald who gave that talk ;-)

A view from the "other side"

Posted Apr 13, 2017 12:00 UTC (Thu) by xav (guest, #18536) [Link]

Bradley, Harald ... all this foreigner names look the same to me :)

A view from the "other side"

Posted Apr 13, 2017 11:11 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> I'm a software developer and not a lawyer so this is sort of a bureaucratic monster for me.

Here's the thing -- When you're incorporating third-party *anything* into your products, you absolutely *need* this sort of process to keep track of what you are using or shipping, regardless if said third-party stuff is copyleft, opensource, or something else entirely.

Speaking personally, even the supposedly onerous requirements of the GPL are outright simple compared to some of the requirements of proprietary licenses I've had to deal with. Source code segregation -- to the point where separate revision control servers (and even *developers*, because "IP contamination") were required, per-shipped-unit tracking requirements, mandatory audit-everything-at-any-time clauses, and so forth.

While I'm all for improved tools to help automate things, identifying the license of a given component is the easy part; ensuring your product properly complies with *all* relevant licenses (and/or corporate "IP" policies) is going to require careful manual review at some point.

A view from the "other side"

Posted Apr 13, 2017 21:09 UTC (Thu) by branden (guest, #7029) [Link]

"Here's the thing -- When you're incorporating third-party *anything* into your products, you absolutely *need* this sort of process to keep track of what you are using or shipping, regardless if said third-party stuff is copyleft, opensource, or something else entirely."

This. Also speaking from the compliance-within-a-big-software-company perspective.

Having a comprehensive software bill-of-materials is also important for minor issues like, say, security vulnerabilities.

There are many reasons not to account for the components used in software construction.

In the commercial environment, all of those reasons are bad.

A view from the "other side"

Posted Apr 13, 2017 11:45 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

Out of interest, what would the process look like if you wanted to ship a few DLLs from Microsoft Office with your product? In other words, what would the policy make you do if you wanted to take part of Microsoft's proprietary code and ship that as part of a device you sell? Note that I'm not talking about shipping the full Microsoft Office product - just a small subset of the code - so it's not as simple as "buy an Office licence and ship that with the device".

My experience is that it's harder with proprietary code than with FOSS - proprietary companies don't like you splitting their product up like that, and want you to treat it as a giant blob. We've now got a generation of developers who grew up with a mix of pirate software and FOSS available, and who don't expect to have to go through this pain for their personal projects, and who thus don't know how to cope with it when it becomes an issue at work.

A view from the "other side"

Posted Apr 13, 2017 18:14 UTC (Thu) by iabervon (subscriber, #722) [Link] (4 responses)

The process for getting approval to ship some code from Microsoft Office is simple: get denied. It doesn't make sense to compare the difficulty of shipping code the owner doesn't want you to ship with the difficulty of shipping code the owner does want you to ship.

You should compare with the difficulty of embedding a proprietary codec implementation, where the owner wants to make arrangements for you to do this. That's generally easier for a business to do than legally using an open source codec because: (1) the legal department can rely on contract law, rather than a license grant, because your company is paying the other company, which creates obligations on the owner; (2) all of your company's obligations under the agreement can be satisfied at the time when you ship the product, not going into the future; (3) your company probably has a process in place to prevent distribution of any third-party code, and no process in place to support distribution of the correct third-party code.

A view from the "other side"

Posted Apr 13, 2017 22:21 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

Firstly, who says that open source software authors want you to ship it in your proprietary gadget?

Secondly, who says that proprietary software that they want you to ship is always that easy? The last proprietary codec I was involved in licensing required, among other things, that when they shipped us a new version, we updated the codec for all devices we had shipped in the last 10 years, and offered the upgrade to our customers at no more than the cost of shipping upgrade media - if the device was not field upgradable to the new codec (and, to be fair, they had to fit within pre-specified CPU, RAM and storage limits to invoke this clause), then we were expected to offer a trade-in program at no more than the cost of shipping the devices to and from our offices.

The rationale was that the licensor wanted to have just one variant of the codec in the field, and for everyone to have the latest version - thus, instead of having to have a formal spec (as MPEG does, for example), they knew that if they saw behaviour that didn't match the current codec, they could simply tell people to upgrade.

A view from the "other side"

Posted Apr 13, 2017 23:34 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

On the first point, from the preamble of the GPL (v2):

"Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things."

They're using a license designed to let you ship their code, so they probably want you to do so. They also want to give your users the ability to change it further. They generally don't want to encourage you to write your own thing that you're not even supposed to give the source of to users, or use a proprietary library instead. A lot of this discussion is about how to maximize the number of people with hardware whose firmware they can make changes to derived from the open source authors' code.

On the second point, I've only used proprietary libraries on occasion and not recently, so you'd have a better idea of what they're requiring these days. That still does sound a little easier than the GPL in terms of tracking: you can send out the latest version of the firmware for each device, and don't need to be able to produce the source of the old firmware that shipped on a device with a particular serial number, which is technically required and sometimes desired ("The manufacturer changed the UI in the latest firmware, and I want the old UI back along with the ability to combine that with security fixes").

A view from the "other side"

Posted Apr 14, 2017 7:01 UTC (Fri) by farnz (subscriber, #17727) [Link]

To the first, that's a conditional grant of distribution - taking away the verbosity it's "if you're producing free software, then I want you to be able to distribute my code, too"; what about it makes you think that an author using such language wants you to use it as a component in your proprietary product (even if that's legal)?

You're forgetting the compulsory audits that come with a proprietary codec, too; you must be able to produce full source and build system (and demonstrate that you can rebuild it from scratch) for any version of firmware that you've ever shipped for a long duration (last one I saw said 5 years) after you ship the last unit of a device - and note that this means that if you ship the same device for 3 years, but only ship the original firmware for 3 months before replacing it, you have to be able to reproduce the original firmware for 8 years, even though you've not shipped it for 7.5 years.

So no, I disagree that it's easier than the GPL; for the last fully proprietary codec I dealt with, it's harder in every respect, and the obligations last longer. This differs with commodity implementations of standard codecs (like a H.264 codec), where they're aiming to make it easy as long as you give them money, but in the open source world, that's the equivalent of choosing BSD licensed code instead of GPL licensed code - choose what works for you.

A view from the "other side"

Posted Apr 14, 2017 5:57 UTC (Fri) by pabs (subscriber, #43278) [Link]

(2) can be achieved for GPL code too, just ship the source with the binaries.

A view from the "other side"

Posted Apr 15, 2017 20:03 UTC (Sat) by giraffedata (guest, #1954) [Link] (2 responses)

By the way, you weren't sued for not distributing source code - you had no obligation to do that, and Harald knows that. You were sued for distributing the object code. Harald claimed to have copyright in that object code and that he hadn't given you permission to distribute it.

There's a difference. People shouldn't get it in their heads that a person can impose obligations on another person just by giving him some software with a copyright license attached.

A view from the "other side"

Posted Apr 19, 2017 11:51 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

By the way, you weren't sued for not distributing source code - you had no obligation to do that, and Harald knows that. You were sued for distributing the object code. Harald claimed to have copyright in that object code and that he hadn't given you permission to distribute it.

Distributing the object code is not a problem if you're distributing the source code, too (at cost, in the preferred form for modification, etc.) – because in that case you don't need permission from Harald Welte; the GPL gives you that permission already. Harald's contention is presumably based on language in the GPL (section 5 of the GPLv2) that says that you don't get to distribute his work except under the GPL, so distributing object code without fulfilling your obligations under the GPL is breaking copyright.

People shouldn't get it in their heads that a person can impose obligations on another person just by giving him some software with a copyright license attached.

Simply giving somebody some software doesn't create any obligations that the person would not already have been under, given copyright law. (The GPL explicitly does not cover use of software published under it.) What a license like the GPL does is give somebody permission, under certain conditions, to do various things relating to distribution of the software that would otherwise, by default, be forbidden by copyright law.

A view from the "other side"

Posted Apr 19, 2017 16:29 UTC (Wed) by giraffedata (guest, #1954) [Link]

because in that case you don't need permission from Harald Welte; the GPL gives you that permission already.

That's permission from Harald. Permission has to come from the copyright holder. Harald distributes a document that contains the GPL text, which says to anyone who should read it, "If you distribute certain source code, I permit to you to distribute my object code." That's how GPL licensing works. If you can't prove in court that the words of the GPL came to you from Harald, you have no defense to Harald's claim of copyright infringement.

So Harald's claim in his lawsuit was, necessarily, "You distributed my code without my permission."

language in the GPL (section 5 of the GPLv2) that says that you don't get to distribute his work except under the GPL

There is no such thing as a copyright license that says you don't get to distribute work. Section 5 doesn't even have legal effect; it's just a statement of the licensor's interpretation of copyright law, and maybe the licensor's intent (not binding) not to license the work any other way. It gives the reader the perspective to make sense of this theretofore unusual copyright license.

A view from the "other side"

Posted Apr 16, 2017 17:54 UTC (Sun) by pombredanne (guest, #113982) [Link]

rakoenig wrote:

> There are tools like Fossology around but at the moment for me Fossology seems like a
> file parser that hunts for keywords like "copyright" or "license" and just checks your
> sources, but not the runtime libs.

You may want to check tow tools of mine:

- https://github.com/nexB/scancode-toolkit/ is a modern alternative to Fossology. It does a bit much more and also looks into binaries. Upcoming features include more advanced analysis of binaries with some GSoC projects: https://fosdem.org/2017/schedule/event/whats_in_your_binary/

- https://github.com/nexB/tracecode-build is a build tracer. One of the applications is to get a detailed knowledge of which files are linked statically or dynamically. I presented it at FOSDEM: https://fosdem.org/2017/schedule/event/whats_in_your_binary/

/HTH


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds