Defending copyleft
Please consider subscribing to LWNSubscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.
For some years now, Bradley Kuhn has been the face of GPL enforcement. At LibrePlanet 2017, he gave a talk about that enforcement and, more generally, whether copyleft is succeeding. Enforcing the GPL is somewhat fraught with perils of various sorts, and there are those who are trying to thwart that work, he said. His talk was partly to clear the air and to alert the free-software community to some backroom politics he sees happening in the enforcement realm.
Most of the work that Kuhn's employer, the Software Freedom Conservancy (SFC), does is not dealing with licensing issues. But people love hearing about copyleft, he said. In addition, free-software developers like those at LibrePlanet have a right to know what's going on politically. There is a lot of politics going on behind the scenes.
Kuhn works for a charity, not a traditional company or a trade association. That means he has the freedom and, in some sense, the obligation to give attendees the whole story from his point of view, he said. He is lucky to be able to work in that fashion. Kuhn then took a bit of a spin through his history with copyleft and why he decided to step up for it.
He studied computer science, but at a liberal arts college, which has given him something of a interdisciplinary approach. He was the first to bring a laptop to class there (a Sager from 1992); it had a battery that lasted all of 25 minutes, so he had two to last for a whole class. He noted that in those days, people read Computer Shopper magazine and would order systems out of it by dialing companies on rotary phones.
He read Linus Torvalds's famous email, more or less in realtime (which, for Usenet, meant "within a few days"). The "just a hobby" phrase really struck him, because he was a part of that culture. In those days, that's who read Computer Shopper and bought computers. He needed an operating system, so he installed GNU/Linux on his computer. That meant he had the source and could make patches to fix problems that he had. He did not send his patches upstream, though, which is unfortunate because he could perhaps have become a Linux developer and could enforce his own copyrights, rather than others', if he had.
A strategy
Copyleft is simply a strategy, he said; it is a tool to try to ensure software freedom for everyone. It is not a moral principle, so if it doesn't work, we should switch to another strategy that does. There is no harm in asking whether copyleft is working, but we should avoid the "truthiness and revisionist history" about GPL enforcement that has become common.
For example, he pointed to a response
from Greg Kroah-Hartman in the contentious
discussion about GPL enforcement prior to the 2016 Kernel Summit. In it,
Kroah-Hartman said that he did want companies to comply with the license,
but didn't think "that suing them is the right way to do it, given that we
have been _very_ successful so far without having to do that
". Kuhn said
he did not know what "quantum reality" Kroah-Hartman lives in, but that
the GPL has been enforced with lawsuits a number of times along the way.
The enforcement of the GPL directly resulted in the OpenWrt distribution for wireless routers. The first commit to OpenWrt was the source release that Linksys and Cisco made due to the GPL compliance efforts. That has resulted in one of the most widely deployed Linux systems in the world. In an aside to Richard Stallman, Kuhn noted that he said "Linux", rather than "GNU/Linux", because these systems mostly consist of the Linux kernel plus BusyBox and not the GNU system.
Kuhn admitted that most of the code released did not go into the upstream projects, which has led to some criticism of those efforts. One persistent critic has been former BusyBox developer Rob Landley who said that the BusyBox compliance efforts had never resulted in any code that was useful to the upstream project. According to Kuhn, that idea is based on a misunderstanding, which he and Landley resolved at linux.conf.au 2017.
Getting code upstream is only a secondary effect of copyleft's primary goal, Kuhn said. Whether the projects get the code is not the fundamental reason that copyleft exists; instead, it is meant to ensure that downstream users of the software can get access to the code so they can become upstream developers. They may not do so, but they will have the opportunity to; that will also provide plenty of learning opportunities for those users.
Stallman said that getting contributions for upstream is a focus of the open-source movement, while getting the code into users' hands is what free software is all about. There is another concern, though, even when the source code is available, Kuhn said. Devices like those for the Internet of Things (IoT) and other embedded use cases often fail to release the "scripts used to control compilation" (from the GPLv2), which means that users cannot build and install the code onto their devices. That is an important part of the software freedom that copyleft tries to ensure.
He pointed to another response in the Kernel Summit discussion thread: Matthew Garrett pointed out that getting companies to participate has some positive effects, but that there are other considerations:
Today's teenager does not have Kuhn's luggable laptop, but does have access to routers, tablets, refrigerators, televisions, and so on. He noted that the SamyGO project got its start from a lawsuit filed to "liberate TV firmware hacking". The base for the project came from the source code released by Samsung due to a BusyBox GPL enforcement suit.
In addition, Harald Welte filed at least fifteen GPL compliance suits in Germany over ten years starting in 2004. So, to say that Linux has been successful without lawsuits, as Kroah-Hartman did, is not an accurate summary of the history. Kuhn would argue that Linux and other software released under the GPL have been successful because enforcement actions and lawsuits have happened regularly over the years.
We can't go to a parallel universe and replay the experiment without lawsuits to see what the outcome would be, but it is political FUD to say that GPL enforcement and lawsuits are some newfangled idea that endangers Linux. If that is true, it has been that way since the first suits were filed back in 2002.
Less compliance
In the meantime, though, compliance has become less common as more and more devices with GPL-covered code are released. If you go to Best Buy and buy an IoT gadget or other device, it almost certainly will contain GPL-covered code and is highly likely to be in violation of the license. It is not just BusyBox and Linux, either; Samba, FFmpeg, and other projects are also having their code built into these devices.
Welte discovered that GPL enforcement is not particularly enjoyable work; he is no longer enforcing the GPL and has moved on to other interesting projects. That leaves SFC as the sole organization doing community-oriented enforcement. The principles that have been used for years to govern what it means to do community-oriented enforcement were refined and published in 2015. The principles embody the idea of using the tool of copyleft to maximize software freedom for users, he said.
The principles also clearly state that legal action is a last resort. It is the last tool to be used, not the first. He and Kroah-Hartman agree on 99.99% of GPL enforcement strategy, Kuhn said, but differ on one minor point. He talked with Kroah-Hartman about the VMware lawsuit at a conference recently and it became apparent what the difference between their positions is. SFC had talked to VMware for years and the company said that it did not agree that it was violating the license, so it would never comply. According to Kuhn, Kroah-Hartman believes that Christoph Hellwig (and SFC) should have just walked away and let VMware violate the license forever. Kuhn said, at best, that would turn the GPL into the LGPL; "at the worst we would have completely eviscerated copyleft".
Kroah-Hartman's employer, the Linux Foundation (LF), has a more aggressive position, Kuhn said. He thinks that is because it does not have software freedom as a priority. As an example of that, he mentioned a conversation he had with LF legal counsel Karen Copenhaver at LinuxCon 2013; she told him that the LF prioritizes Linux jobs. If allowing proprietary kernel modules creates more Linux jobs, that, to her, is an acceptable tradeoff. But Kuhn believes there are some jobs that shouldn't be done, especially if they are harmful to the community.
Criticism
There is a strange element to the criticisms about lawsuits, he said. Companies in the tech industry sue each other all the time—hundreds of times each year. But even if he uses "aggressive overcounting", he can only come up with about 50 lawsuits against GPL violators in the last twenty years. The SFC has remained under continuous attack though it has only funded one lawsuit in its entire history, he said.
The politics surrounding our community are nasty and not transparent; much of what happens goes on in backchannels that our community does not have access to. The policies that various organizations are pushing are not in the open. For example, the LF has declared war on copyleft, he said. It is a trade association that is run by big companies that would prefer that copyleft would go away. They would also like enforcement to cease because it scares their customers.
Others, like VMware, thumb their noses at the GPL. That is because companies are not really interested in software freedom, which is logical from their point of view, Kuhn said, even though he disagrees. This bias against copyleft licenses has been going on for a long time; copyleft projects get replaced with non-copyleft alternatives so that companies can make proprietary versions when they wish to.
But a talk by Eben Moglen the previous day (which hearkened back to his talk at Columbia Law School in November 2016) suggested that lawsuits are driving companies away from copylefted code and away from copylefted kernels in particular. Kuhn does not see how that can be true since there have been non-copylefted kernels available for decades. It is also another example of a lack of transparency in the politics, Kuhn said, because Moglen and the Software Freedom Law Center (SFLC) are working with the LF on its anti-copyleft work.
Kuhn said he doesn't think of the LF, SFLC, or Moglen as enemies, though he does think they are misguided and a bit hypocritical. He said he would like to end the rumor mill and the backchannel politics to give all of the free-software community the ability to weigh in on these issues.
For another example of these politics, Kuhn pointed to a particular section of a video [WebM] of a talk by former Debian project leader Neil McGovern. Some ways into the talk, McGovern noted that Debian had asked SFLC for advice about distributing ZFS; even though SFLC opined that Oracle would not sue Debian for doing so, the project decided not to distribute ZFS in binary form for reasons of morality. When McGovern was asked about releasing the advice publicly, he declined since it was not something Debian wanted to advocate, but shortly thereafter something eerily similar was published—with "Debian's name filed off".
If there is a non-copyleft kernel coming for Android, as Moglen had predicted the previous day, it is not all that different from where things are today, Kuhn said. He has a hard time finding a Linux kernel in an embedded device that is complying with the GPL. In effect, Linux is a non-copyleft kernel in most cases because of that.
Not magic pixie dust
Copyleft is not "magic pixie dust" that you sprinkle on your code and magically get software freedom. It only works if someone does the work to ensure that the copyleft license is complied with. By some historical accident, he and Karen Sandler are the ones doing that for the Linux project. Kuhn is not in love with GPL enforcement. It is truly boring work and is politically dangerous. It has had an effect on his career, since there are probably only two organizations that he can ever work for: the SFC or the FSF. He would much rather be a free-software developer, but that doesn't seem to be in the cards.
He would not be doing this enforcement work without a mandate, however. Linux copyright holders asked the SFC to do this work. The future of copyleft is in the hands of the copyright holders, which are increasingly for-profit companies. The interests of those companies may align with the free-software community at times, but may not at other times. He advocated that free-software developers demand that they hold onto their copyrights in the code they create, rather than allowing the companies that employ them to hold them. It is clear that many companies are willing to leave copyleft undefended, he said. In order to defend it, we will need to have our own copyrights in the code.
Overall, he is rather baffled by how things have worked out. The SFC has spent years trying to work with the LF and others on GPL enforcement issues, but new heights of criticism are regularly reached, he said. His best guess is that powerful entities are concerned that developers will be the ones to determine the future of copyleft rather than the entities. Historically, free-software developers have been good at defending software freedom, he said, so we should hold our own copyrights, license code under the GPL, and defend the GPL when it is violated.
In "half a minute" of his reactions, Stallman noted that it would be really nice if the GPL enforced itself. If companies could be brought into compliance without harsh words and actions, that would be great, but it might not be enough. There is a need for visible action so that would-be violators recognize that there are effective actions that can be taken. There is tremendous hostility to the GPL and copyleft, but it is counterproductive to not do enforcement as a way to fend off that hostility. It may well be that Google's non-copyleft kernel becomes successful and replaces Linux, but if we try to avoid that by not enforcing the GPL, the outcome is the same.
For those interested, Kuhn's slides and a WebM video of the talk are available.
[I would like to thank the Linux Foundation for travel assistance to
Cambridge, MA for LibrePlanet.]
Index entries for this article | |
---|---|
Conference | LibrePlanet/2017 |
Posted Apr 13, 2017 8:23 UTC (Thu)
by rakoenig (subscriber, #29855)
[Link] (15 responses)
That means, when I develop something that will run on Linux I have to get it through that process. In detail this means:
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
Posted Apr 13, 2017 10:08 UTC (Thu)
by xav (guest, #18536)
[Link] (2 responses)
Posted Apr 13, 2017 10:49 UTC (Thu)
by armijn (subscriber, #3653)
[Link] (1 responses)
Posted Apr 13, 2017 12:00 UTC (Thu)
by xav (guest, #18536)
[Link]
Posted Apr 13, 2017 11:11 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
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.
Posted Apr 13, 2017 21:09 UTC (Thu)
by branden (guest, #7029)
[Link]
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.
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.
Posted Apr 13, 2017 18:14 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (4 responses)
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.
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.
Posted Apr 13, 2017 23:34 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (1 responses)
"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").
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.
Posted Apr 14, 2017 5:57 UTC (Fri)
by pabs (subscriber, #43278)
[Link]
Posted Apr 15, 2017 20:03 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (2 responses)
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.
Posted Apr 19, 2017 11:51 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.
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.
Posted Apr 19, 2017 16:29 UTC (Wed)
by giraffedata (guest, #1954)
[Link]
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."
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.
Posted Apr 16, 2017 17:54 UTC (Sun)
by pombredanne (guest, #113982)
[Link]
> There are tools like Fossology around but at the moment for me Fossology seems like a
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
Posted Apr 13, 2017 11:27 UTC (Thu)
by k3ninho (subscriber, #50375)
[Link]
Er, Richard, wouldn't it be neat if there's some sort of digital rights-enforcement hardware that could do the enforcement/management it for you? ;-)
K3n.
Posted Apr 14, 2017 19:34 UTC (Fri)
by flussence (guest, #85566)
[Link]
Thanks to them we now have a billion internet-facing devices running blobbed, unfixable, barely maintained Linux 3.x in the wild. All credit to LineageOS here, they're the only ones trying to clean up Google's planet-wide oil spill.
Posted May 4, 2017 7:16 UTC (Thu)
by landley (guest, #6789)
[Link] (4 responses)
No, I still think what he's doing is probably useless. I just now understand that he was never _trying_ to get code upstream into projects, so he can't have failed at a goal he didn't attempt.
As far as I can tell, Bradley's trying to get build and install instructions because he's not an embedded developer and doesn't really understand the problem space, therefore it must be simple. (I watch videos like https://www.youtube.com/watch?v=8KNZsNTPlec and marvel at those guys.) Remember the GPLv2 vs GPLv3 argument about anti-tivoization? My understanding is that bradley's ONLY interested in the anti-tivoization part. Not in advancing the project's actual development. What's the point? Android phones still have a signed bootloader because they're worried about "evil maid attacks" (somebody gets your phone for 5 minutes and roots it and you can never tell). GPLv3 says the maid has to be able to install their software, so GPLv3 code will never ship on android or anything like it.
Way back when I inherited the busybox Hall of Shame, I launched GPL enforcement suits to try to get code upstream into busybox. I ran an experiment which empirically showed that lawsuits did not add useful code to the project, and then I tried to shut them down and couldn't because other people had other agendas. Here's an interview I gave at the time explaining that busybox developers like Glenn McGrath trying to do their _own_ GPL enforcement were burning out and leaving the project, and over at gpl-violations.org Harald Welte had given up on actual development to focus on license enforcement. I was partly trying to do it to protect the remaining busybox developers from burnout:
https://www.linux.com/news/sflc-files-gpl-lawsuit-behalf-...
Back then the GPL was synonymous with copyleft but since GPLv3 split copyleft into incompatible warring camps, there _is_ no "the GPL" anymore. The kernel and Samba can't share code and QEMU can't accept code copied from either project. Since then CDDL resurfaced, people are licensing code creative commons, there's a GPL-next project... It's https://xkcd.com/927/ and unlikely to end well.
For my own projects I've switched to public domain equivalent licensing, and got 0BSD (Zero Clause BSD) approved by SPDX. I haven't done a proper writeup on that, but here's two long emails I exchanged with somebody about it last month:
http://landley.net/notes-2017.html#26-03-2017
Rob
Posted May 4, 2017 8:28 UTC (Thu)
by aggelos (subscriber, #41752)
[Link] (1 responses)
I won't debate Google's motivations for not wanting to have GPLv3 code on Android, other than to say there are alternative narratives that do not rely on "market demand for anti-evil-maid measures ever since Google got into the smartphone OS business". That said, the GPLv3 does not say that anyone with physical access needs to be able to modify the software; only that the user needs to be provided with the appropriate "Installation Information" to be able to install and execute modified versions of the software on their device. If you have a different interpretation I'd be interested in hearing about it. Otherwise, this feels like a misrepresentation. GPL-next is not a thing. Copyleft-next (no FSF affiliation) is (was?) an experimental work that, last I checked, was adopted by a grand total of one project (though I haven't checked in years, their mailing list activity was sparse and has become sparser). In any case, it seems to me like accusing a developer for community splitting because they have a research branch in their copy of your repo :-) There's a lot to be said for avoiding needless barriers to the exchange of code. Needless being the operative word here.
Posted May 6, 2017 10:19 UTC (Sat)
by flussence (guest, #85566)
[Link]
Posted May 4, 2017 13:10 UTC (Thu)
by bkuhn (subscriber, #58642)
[Link]
Rob, I do sincerely appreciate the upgrade in opinion from you (and to be abundantly clear, I'm not being sarcastic here at all). Years ago, you used to say what I was doing was “harmful”, and then for a while you just said it was “useless”, and now you say it's only “probably useless”. I'm fine to agree to disagree at that assessment and we can let long-term history judge whether my and your work in life has been useful. I generally think it's probably impossible for anyone to know for sure if their work has actually been useful when we start talking about the 20-100 year time-frames (that are of most interest to me; I don't care so much about the 1-20 year time frame, as they are fleeting). I try my best to do what is right, and history can and should judge me. More importantly, I'm glad that after our friendly chat at LCA 2017, that you and I aren't at odds anymore, and we're content to leave each other alone to do the work we each feel is right. Thanks for that! I have embedded development experience, and I do understand the problem space. As you know, enforcement efforts that I have been involved with have launched multiple embedded projects (e.g., OpenWRT and SamyGo), precisely because, through GPL enforcement (and sometimes lawsuits), we assured release of the “scripts used to control compilation and installation of the executable” that GPLv2 requires. Embedded developers, no matter how skilled, need that to build and install software successfully. Of course, anything can be reverse engineered, and a good embedded developer can often reverse engineer the build process, but GPLv2 was specifically designed to assure developers need not reverse engineer to make use of the source code.
Posted May 4, 2017 16:07 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Plenty of Android phones (including those made by Google) can be configured to boot either arbitrary code or code signed with different keys. I don't think security is the reason here.
(Disclaimer: While I work for Google, I'm not involved in Android development or phone design and don't have any particular insight into the above matter)
A view from the "other side"
- 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
A view from the "other side"
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"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
A view from the "other side"
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.
A view from the "other side"
A view from the "other side"
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.
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"
because in that case you don't need permission from Harald Welte; the GPL gives you that permission already.
language in the GPL (section 5 of the GPLv2) that says that you don't get to distribute his work except under the GPL
A view from the "other side"
> file parser that hunts for keywords like "copyright" or "license" and just checks your
> sources, but not the runtime libs.
Defending copyleft
Defending copyleft
Defending copyleft
> which he and Landley resolved at linux.conf.au 2017.
http://landley.net/notes-2017.html#27-03-2017
Defending copyleft
What's the point? Android phones still have a signed bootloader because they're worried about "evil maid attacks" (somebody gets your phone for 5 minutes and roots it and you can never tell). GPLv3 says the maid has to be able to install their software, so GPLv3 code will never ship on android or anything like it.
Back then the GPL was synonymous with copyleft but since GPLv3 split copyleft into incompatible warring camps, there _is_ no "the GPL" anymore. The kernel and Samba can't share code and QEMU can't accept code copied from either project. Since then CDDL resurfaced, people are licensing code creative commons, there's a GPL-next project... It's https://xkcd.com/927/ and unlikely to end well.
Defending copyleft
Rob Landley wrote:
Defending copyleft
No, I still think what [bkuhn]'s doing is probably useless.
he's not an embedded developer and doesn't really understand the problem space, therefore it must be simple
Defending copyleft