Clean GPL examples? - Page 1
Forum section: electronics / general

author: Someone
author_rank: Super Contributor
timestamp: February 20, 2019, 09:09:00 am
content: So its time again to visit the minefield of open source licensing. I've used plenty of LGPL sources in the past and contributed back any fixes/changes etc and fully support open source, but completing obligations under GPL seems wildly impractical. Take for example the simple case of distributing some software that runs on linux, easy to do and comply with GPL. But if you want to package that already installed on linux (for instance in an embedded product) you need to have complete source for everything that is being distributed:https://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinaryAfter much hunting around for an example of a Raspberry Pi image that meets this I'm still stumped. Even the "official" build processes use binary blobs:https://github.com/RPi-Distro/pi-genHow do high profile examples like this get away with not providing a way to pull all the sources? A end user accessible copy of all the GPL sources is required to be able to distribute the aggregate, and then provides the convenient base for customising where the user can then redistribute the modified form and the corresponding source.Does anyone have some good examples of linux repos that include the build flow so they are buildable to a booting image from source? Do any exist for Raspberry Pi?

author: agehall
author_rank: Frequent Contributor
timestamp: February 20, 2019, 09:35:53 am
content: As I understand it, the distribution can consist of software that is GPL or whatever. The individual pieces of software do of course retain their own licenses but the distribution as a whole can have it's own license on top of this as long as it does not contradict the other licenses.The whole discussion about GPL and how far it spreads with everything it touches is a lengthy one but I think distro makers are in the camp that says that it stops with the linking step in the binary and thus a single GPL software does not pollute the whole distro and therefore it is perfectly fine to include non-GPL software in the same distro. Another approach is to leave the combining of non-GPL and GPL to the end-user.If you are looking for something that always builds from source, I think you should look at Gentoo.

author: nick_d
author_rank: Regular Contributor
timestamp: February 20, 2019, 12:15:23 pm
content: It doesn't happen automatically, it's more of a demand thing. Like for example when a new mobile phone is released, eventually enough people will buy it that it starts to be targeted for open source Android distributions such as LineageOS. Then the LIneageOS developers will pester the manufacturer of the phone until they eventually come up with the GPL sources. I have done this for a router that I bought, it was a Billion BIPAC model and eventually I got hold of the Linux sources. It wasn't all that pretty and as you said, it included many binary blobs which was a bit disappointing. However, I think technically speaking those binary blobs were kernel modules. It is very much a grey area whether this constitutes combination with the GPL'd code. I would naively say it does, the manufacturer obviously thinks it doesn't. There was a high profile case where a LInux developer sued VMware over this issue. That's because VMware was distributing a closed source product which I think was VMware ESX Server or similar. Which is basically a cut-down LInux distributiuon that runs only the VMware hypervisor, and hence you load OSes underneath it. For the concept to work, the hypervisor needs to be able to control all devices attached to the computer, and they were using Linux device drivers to do so. They claimed that the ESX Server binary blob wasn't Linux, it only adhered to Linux interfaces and loaded Linux kernel modules (the device drivers which are GPL'd). I think this claim is bullshit and so did the Linux developer who sued them. It went on for years and I do not know the outcome in the end. I do know that when commercial stakes are high, companies are very incentivized to bend the rules.cheers, Nick

author: magic
author_rank: Super Contributor
timestamp: February 20, 2019, 01:28:29 pm
content: Quote from: Someone on February 20, 2019, 09:09:00 amNot a lawyer and didn't even read your linkThat being said, it's my understanding that some blobs are acceptable, such us:- binary applications running on top of a GPL kernel or even using GPL libraries with special exemptions (such as libc)- kernel drivers for hardware and filesystems, Linux copyright holders make it clear it is their intent to allow them- firmware for peripheral devicesQuote from: Someone on February 20, 2019, 09:09:00 amOpenWRT might be one, a third party firmware for various routers. You download a repo, choose your model, run make and get an image you can upload through the admin panel.I think ChromiumOS comes close too, save for binary driver blobs, but I never actually tried building it.Many hardware vendors don't bother, though. Reasons include:- it's an effort to publish and maintain such build system- their internal build system may employ proprietary tools they don't want or aren't allowed to publish- the code contains their patches which they want to (legally or not) withhold from competitorsQuote from: Someone on February 20, 2019, 09:09:00 amYou seem to believe this implies that any software contained in an embedded Linux system must be open source.However, the paragraph you link only talks about redistributing a binary of GPL software you obtained from someone else.I think more relevant is this one:QuoteSo you can argue that an embedded system is a self-contained program and none of it would be of any value to the end user without some particular critical GPL component, but the vendor will argue back that their embedded system is merely an aggregation of multiple "programs" communicating over usual inter process communication channels and go fight them now.

author: Someone
author_rank: Super Contributor
timestamp: February 24, 2019, 03:16:49 am
content: Quote from: agehall on February 20, 2019, 09:35:53 amYou've summed up the situation in those few sentences better than any other reference I have found, well done.The challenge still remains that if you want to distribute a system incorporating GPL code you need to be able to provide the source for those GPL parts (and the sources they extend to). After much more searching I did find one example for the Raspberry Pi that collects the sources of all the GPL components:http://www.arbetsmyra.dyndns.org/nard/index.htmlSomewhat comedically that flow which makes it easy to comply with the GPL is licensed in a way that it can't be freely distributed by others. It is utterly bizarre there isn't one (or possibly even any at all) widely used GPL build flow for maintaining compliance with GPL.

author: gamblingfetus
author_rank: Newbie
timestamp: March 03, 2019, 10:51:42 pm
content: For GPL compliance, sources of allmodifications you madeneed to be available, but not necessarily a complete dependency walk of all original sources.Also, a best practice is to concatenate all of the licenses from each included component into a Markdown file.In general, libraries that use AGPL, GPL3 or lack a license are radioactive to begin with. GPL2 is risky. MIT, Apache, BSD2/3 and similar are ideal.(IANAL)

author: janoc
author_rank: Super Contributor
timestamp: March 03, 2019, 11:27:47 pm
content: This site has a good run-down of which methods of distributing source code are acceptable and what you need to do:https://www.softwarefreedom.org/resources/2008/compliance-guide.htmlThey specifically cover also embedded devices. However, in practice if you distribute only source for things you have modified (kernel, etc.) and any required build scripts (which may e.g. pull in the official Raspbian sources) you will be likely fine.The RPi example you gave doesn't really apply - not everything in an RPi image is GPL licensed. So they need to distribute sources only for things that are (and they do, IMO). pi-gen is a distro generation tool, that it pulls in pre-compiled packages doesn't mean it uses "blobs" for which no source is available.Quote from: gamblingfetus on March 03, 2019, 10:51:42 pmIf it lacks a license, then it is all rights reserved by default and it cannot be used. AGPL you are very unlikely to encounter in embedded space (or even in general - it is so nasty that very few projects use it).The blanket statement on the rest is really unhelpful because then nobody could ever use any embedded Linux, for example (most of Linux kernel and userspace is GPL2/3 licensed). All of those licenses can be complied with, even in embedded code - and companies do it every day. Just make sure you understand the obligations being imposed and what they mean in the context of your product.I also don't understand why GPL3 would be "radioactive" and GPL2 merely "risky" - they impose the same obligations, only GPL3 makes some things more explicit, such as the patent grants and the anti-DRM/Tivoization clause (aka conveying the source code but making it unusable by cryptographically locking the product down). BTW, if the patents are your concern about GPL3, then the Apache license has a fairly similar clause ...

author: andersm
author_rank: Super Contributor
timestamp: March 04, 2019, 12:00:44 am
content: The GPLv3 requirement that the user must be able to install their own software onto the device is usually the sticking point. At best it's a hassle, at worst impossible to fulfil due to eg. certification requirements. It also kind of dovetails into the whole "right to repair" question. Where does the manufacturer's responsibility end when the user starts tinkering with the firmware?

author: magic
author_rank: Super Contributor
timestamp: March 04, 2019, 05:41:38 am
content: Quote from: andersm on March 04, 2019, 12:00:44 amTo be honest, the inverse is impossible to fulfill, i.e. preventing modifications to equipment by its owner. That kind of regulations are nonsense and should be pushed against.At the same time, a locked down device running Linux is still preferable to me to some proprietary invention so I'm glad Linux isn't GPL3 and that sentiment seems to be shared by many people, including most Linux (and BSD) developers.Quote from: andersm on March 04, 2019, 12:00:44 amWhen user's firmware causes a failure that wouldn't otherwise exist. I doubt courts would have doubts about it and few people are going to sue vendors who refuse repair on that grounds in the first place.People have been hacking embedded devices for decades (hey, bandwindth unlocks, anyone?) and that kind of controversies just don't seem to be a thing in practice.Most of the locked-down systems are either due to certification requirements as you say or for DRM and crap like that.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: March 04, 2019, 06:24:46 am
content: Tried to figure it out specifically in the case of fonts for an embedded system. It felt like an unterminating while() loop - effort without answer. The guides we did find never really answered the questions, and there were just too many ambiguities about how much the source was "polluted" by the font being imported, along with when obligations were triggered by the license.Finally threw it all out and bought a commercial font. Money very well spent.

author: janoc
author_rank: Super Contributor
timestamp: March 04, 2019, 08:24:24 pm
content: Quote from: andersm on March 04, 2019, 12:00:44 amWell, that's the anti-tivoization clause. The problem with this idea is that once you lock the device down, the entire point of GPL (being able to fix/improve/replace the code running on the device) is moot, because there is no way to upload and actually use that code.The certification part (radios, etc.) can be solved by simply locking only those parts down (e.g. a protected binary firmware blob to be loaded at runtime - a pretty common solution). If the entire device needs to be certified (e.g. safety-critical medical hw or avionics), then are you sure you want to use a bunch of open source software written by Joe Random you have no control over?And re manufacturer's responsibility - that's a very poor excuse for locking the hw down. It is trivial to log somewhere in an eeprom or something (e.g. blowing some sort of config. fuse) that the bootloader/whatever has been unlocked and then refuse warranty/responsibility if the user has tinkered with it. But this may not absolve you from fixing any actual hw faults - e.g. computer vendors tried to pull this off by refusing to honor warranties if someone has installed Linux on their laptop instead of the preloaded Windows. They got this thrown back in their faces by the various consumer protection agencies as unreasonable when the client was demanding repair for hardware problems, such as broken fans, GPUs and similar issues. Ultimately, you can't really prevent the user from tinkering with their own hardware and any such lock will get broken sooner or later.Instead of that certification/responsibility fig leaf, a way more common reason why companies want to lock the hardware down are purely commercial reasons - preventing the user from changing configurations to obtain something they didn't pay for or to lock out competition.

author: andersm
author_rank: Super Contributor
timestamp: March 04, 2019, 11:51:31 pm
content: Quote from: janoc on March 04, 2019, 08:24:24 pmThere's a ton of devices outside of medical or avionics that require certification too. And there's also a lot of common software that has switched to GPLv3 or LGPLv3, eg. Bash, which is quite reasonable to have installed in a Linux-based device. Though medical and avionics would not fall under the anti-Tivoization clause anyway, as neither is a user product as defined in the license. But that definition has its own issues that aren't clear at least to a layperson.Say you have a burglar alarm system, and it is sold and installed into a warehouse. That is clearly not a "dwelling", so the installation information clause does not apply. But if that same product is installed in a dormitory, does it apply then? And what about hotels, hospitals, office buildings?QuoteIt may be trivial if you have those features in your hardware. But the argument is that you wouldn't be allowed to refuse.QuoteThat's certainly part of it for some, but hasn't really been a concern in any discussions I've been involved in.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: March 05, 2019, 12:50:43 am
content: Decian is a linux distro that is pretty strict in what it finds acceptable to include.There is also a linux distribution that claims it build (almost?) everything from source. I think it's Gentoo, but I migh be wrong here.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: March 05, 2019, 03:19:08 am
content: Quote from: janoc on March 04, 2019, 08:24:24 pmSupport cost can be very high, if Joe Blogs screws his device you can be sure Joe's still going to try and get support. When you've invested support cost and found the root cause, you think Joe's going to front up with payment?Nope.

author: Someone
author_rank: Super Contributor
timestamp: March 05, 2019, 05:22:34 am
content: Quote from: janoc on March 04, 2019, 08:24:24 pmA very interesting point when more and more function is being off loaded into the higher level OS. But getting wildly off topic

author: janoc
author_rank: Super Contributor
timestamp: March 06, 2019, 08:26:59 pm
content: Quote from: andersm on March 04, 2019, 11:51:31 pmThat's actually explained directly in the license (https://www.gnu.org/licenses/gpl-3.0.en.html):QuoteSo unless you make an alarm system that is specifically designed, sold and used only for warehouses, it applies even if you have installed it in a place that isn't a "dwelling".And also:QuoteHowever, in the case of this clause it is in your own interest to consider the product as "consumer product", with the attached consequences (distribution of the source code, etc), because otherwise the license doesn't apply. Which means that in the absence of some other license (e.g. obtained separately from the sw's author) it defaults to all rights reserved - and you do not have any right to distribute it.That said, I do agree that this clause is weird - it would make much more sense to not restrict this to "consumer products", regardless of how are they defined.Quote from: andersm on March 04, 2019, 11:51:31 pmAnd how are you going to deal with the case that someone jailbreaks the device? Historically pretty much all of these protections have been bypassed as long as the hw was an interesting target. If you aren't allowed to refuse a warranty/repair for a modified device (which may well be the case in some situations), then the anti-tivoization clause is really the least of your concerns, because leaving the device unlocked would have the same consequences - most people don't hack and the few that do would do it regardless of your lock.

author: Marco
author_rank: Super Contributor
timestamp: March 06, 2019, 09:31:49 pm
content: Quote from: Someone on February 20, 2019, 09:09:00 amNo Linux contributor has ever decided to sue.Linus&co have not commented on the situation for over a decade now, so they seem to be pretty much at peace with distribution of binary modules with the kernel. I assume they keep their mouth shut because license wise they can't actually do anything to make it legal at this point and they don't want to put ideas in any other contributor's heads.

author: janoc
author_rank: Super Contributor
timestamp: March 06, 2019, 09:34:53 pm
content: Quote from: blacksheeplogic on March 05, 2019, 03:19:08 amYes, but people will screw with their stuff regardless whether or not you lock them. In that case it is actually less costly to keep it unlocked/make it unlockable and only keep track of it in some tamper-proof way. Because at the end of the day that is what you need to reduce the support costs - to be able to justify refusing the support/repair, not preventing the Joe from messing with it (they will find a way regardless). It is the same as the liquid detection strips - you can either make the phone waterproof (=expensive and difficult - and people will still go diving with it thinking waterproof means 40m under the surface waterproof!) or add a $0.01 detection strip inside.Of course if the company's goal is something else (such as locking out competition or forcing the customers to pay more), that's another matter. But then let's not pretend it is about support costs ...

author: janoc
author_rank: Super Contributor
timestamp: March 06, 2019, 09:43:36 pm
content: Quote from: Marco on March 06, 2019, 09:31:49 pmThat's completely wrong.https://wiki.fsfe.org/Migrated/GPL%20Enforcement%20Caseshttps://www.theregister.co.uk/2005/04/29/fortinet_settles_gpl_lawsuit/and many others. A lot of these cases have been led by Harald Welte (iptables author):https://en.wikipedia.org/wiki/Harald_WelteMost of these cases are actually settled out of court, before it comes to the actual process, so you may not be aware of them. The goal is to bring companies into compliance (= release the sources), not to wring money out of them.

author: Marco
author_rank: Super Contributor
timestamp: March 07, 2019, 09:24:46 am
content: No Linux contributor has ever decided to sue (within the context of closed source binary modules being distributed with the kernel).They got a bit upset about it when NVIDIA half-half did it, with shim and without packaged distribution ... and then when Android went full steam ahead and it started to be done a million times worse than anything NVIDIA did, not a peep. Funny that.

author: janoc
author_rank: Super Contributor
timestamp: March 07, 2019, 01:16:15 pm
content: Quote from: Marco on March 07, 2019, 09:24:46 amThat's also wrong.https://sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.htmlhttp://ipkitten.blogspot.com/2019/01/vmware-gpl-case-is-back-in-courtwill-we.htmlIt specifically concerns binary modules combined with the kernel. The first suit was dismissed, now it is in court again.And there were many other cases where the violation has been resolved after the vendor has been called out publicly on the kernel mailing list or elsewhere (e.g. Oracle was famous for trying to play games like that). Lawsuit is really the last resort - absence of court casesdoes not mean that the license isn't being enforced!Only that the violators realize that fighting this is futile and they would (expensively) lose unless they fix their mess.E.g.:https://plus.google.com/+gregkroahhartman/posts/6Zu4x37jv9GThere is no problem with binary modules per-se. They are frowned upon, because they are often unmaintained, cannot be audited and tested properly so are potential sources of stability problems and security issues (kernel drivers run with "root" access to anything on the machine).The Nvidia's shim was not designed to bypass GPL but to provide a "buffer" against changing kernel APIs (otherwise you would have to recompile everything every time you change kernel). Only the shim gets rebuilt. ATI/AMD has the same design. And plenty of others. It is tolerated because it is understood that these drivers were never derivative works of the Linux kernel, in some cases weren't even originally developed for Linux to begin with.The GPL issues get triggered only if there is a binary-only module/blob that uses kernel interfaces that are explicitly tagged as GPL-only (don't remember the symbol used for that from top of my head). Then the module becomes a derivative work of the kernel and must be GPL-ed too. That's the crux of the VMWare lawsuit above. If the module/driver doesn't need these interfaces, then there is no problem - it is not considered as a derivative work and GPL doesn't apply (using a public API doesn't make something a derivative work, that's why the kernel uses this kludge with the symbols being tagged as GPL-only to make it explicit).This way of delimiting the kernel boundaries was chosen many years ago following an incident with a webcam driver (I believe it was for Phillips webcams) that had some sort of closed source, proprietary compression scheme. The developer then included a "hook" in their driver to load this blob into the kernel. That was considered a GPL violation because that driver was developed specifically for Linux, as a derivative work of the kernel, using its files - and had closed source part. Which isn't allowed. I believe the hook in question was removed, along with the proprietary compression scheme and later a fully GPLed driver was made after someone reverse engineered that compression scheme.And re Android - I am not quite sure what are you talking about, given that the Android kernels are open source, the vendors ship the source (how would e.g. Cyanogen and the other modders get their kernels?). What may be in binary blobs are some device drivers but see above - as long as the driver doesn't need the GPL-only interfaces or it is a firmware for e.g. some radio (i.e. not a derivative work of the kernel by definition), it is fine. Also many drivers have an open part which is a part of the kernel that e.g. exposes the device to user space (e.g. as a special file or memory block) and then there is closed user space library to deal with it (cameras on Android are often like this).For example Samsung's page:http://opensource.samsung.com/Or Huawei's (!):https://consumer.huawei.com/en/opensource/What is often proprietary on Android is the user space stuff - but that has nothing to do with the kernel, it is not even Linux and most of those tools were either developed from scratch by Google or have permissive licenses allowing such distribution/use. Even in Linux you can (and do - e.g. Matlab) have closed-source proprietary applications.

author: Marco
author_rank: Super Contributor
timestamp: March 07, 2019, 02:10:38 pm
content: Mea Culpa, so someone is suing. It's just Linus and other major contributors who have almost certainly intentionally not spoken out about it for over a decade.The GPL only tags don't mean much, every contributor has as much right to make a copyright claim as another. The people who add the tag don't have the right to overrule the GPL for other contributors. Either distribution with a binary only module is okay, or it isn't ... the tags can't be relevant, except for the standing of the specific person who added them to sue. I think Linus&Co would like them to be relevant, but they can't go back in time to change the license to really make them so ... so instead they just stay intentionally quiet and try to maintain a status quo where nearly everyone pretends they overrule the license.Graphics drivers aren't user mode ... how many mobile GPU drivers are open source?

author: Gabri74
author_rank: Regular Contributor
timestamp: March 08, 2019, 09:59:28 am
content: QuoteI'm surprised no one mentioned Yoctohttps://www.yoctoproject.org/With Yocto you can build complete distributions from source, with really high grade of customization and granularity of what is built and shipped.It's based on recipes and will build everything from source: it will build a cross-compiler for your target (i.e. arm) to be run on your host machine (i,e, x86) using your compiler and then with this will cross-build all the packages.License management and compliance is a big part of Yocto: you can limit built packages based on licence type (GPL/LGPL 2/3, commercial, open source, etc) and once the build is done you'll have complete manifests and reports on all the used packages and licenses.It's de de-facto standard in the embedded industry, with official support by any serious vendor (NXP/Freescale, Intel, Texas, etc).The learning curve to use it extensively is really steep, but there are plenty of examples and the documentation is really good, so you can set up an example image that can run emulated in quemu in minutes (... for the setup.. the build process take hours depending on your hardware)Also worth mentining is BuildRoot:https://buildroot.org/Regarding GPL3 compliance, note that the mainstream interpretation is that you must only allow the end user to install/upload to your target the L/GPL libraries that you already ship and he wants to modify, You don't need to give complete access to your machine/product. I.e you can allow your end user to use an USB drive from which the libraries can be installed on your product using a script.See for example:https://www.embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/

author: magic
author_rank: Super Contributor
timestamp: March 08, 2019, 12:34:49 pm
content: Quote from: Marco on March 07, 2019, 02:10:38 pmNo doubt intentionally because those things have been decided over a decade ago and the legal landscape hasn't changed much since then.Everything I'm going to write below you could find yourself simply by reading mailing list archives from early 2000s.Quote from: Marco on March 07, 2019, 02:10:38 pmThey mean precisely that the authors and maintainers of given code consider it Linux-specific and you are likely to get sued for creation of a derived work if you link yourself with it. And finding your code a derived work is the only way you could possibly be in violation of the GPL if you wrote it all yourself.It is also believed that your module is unlikely to be found a derived work of the kernel if it is OS-agnostic and only calls basic interfaces which - in minor variations - exist on every general purpose OS out there and haven't even been invented in Linux. Hence EXPORT_SYMBOL for such interfaces and EXPORT_SYMBOL_GPL for everything else.The primary purpose of those tags is to document which parts are which and to aid in proving willful infringement if somebody chooses to circumvent them.Quote from: Marco on March 07, 2019, 02:10:38 pmNot really, contributors don't share copyright to the entire kernel. You only own what you wrote yourself. If you think that having contributed a network interface driver gives you any legal standing to sue NVIDIA for their use of MM or PCI subsystems, you are probably wrong.

author: Marco
author_rank: Super Contributor
timestamp: March 08, 2019, 12:46:39 pm
content: Quote from: magic on March 08, 2019, 12:34:49 pmIf NVIDIA distributes YOUR code in the process, of course it does. If they are distributing YOUR code under the GPL in a way which extends the GPL to their code, they have to obey it ... and there is absolutely nothing in the GPL about GPL only tags.Now the question of whether distributing a binary module with a Linux kernel with YOUR code extends the GPL to that module is undecided as of yet, but the GPL only tags can not matter. They are not part of the license, they are just some random text added by a bunch of geezers who can not change the license on YOUR code.That's the essence of the GPL, it tries to infect the whole project and make it impossible for any one contributor to limit the license without owning the copyright for the whole thing. Which Linus does not.

author: magic
author_rank: Super Contributor
timestamp: March 08, 2019, 02:44:23 pm
content: Okay, I was thinking about developing and distributing proprietary modules alone.When they ship a proprietary module preinstalled on a system, and many vendors do, perhaps NVIDIA too with their devboards nowadays, then it's again this question of whether it constitutes combining the two programs into one or merely putting them side by side in one memory device.And from FSF's own FAQ that I quoted before (emphasis added):QuoteSo I don't think it's a clear-cut as you say, particularly when the secret part of the module is really a multi-OS hardware driver which runs the same way on any OS you use it with and doesn't interact with the kernel apart from malloc/free, PCI access and maintaining a userspace API.I mean, if it were a clean-cut violation of copyright law as you suggest, there would be lawsuits already from FSF zealots who happen to have commited a single line of code to Linux twenty years ago and Torvalds could do jack shit about it.

author: Marco
author_rank: Super Contributor
timestamp: March 08, 2019, 03:04:15 pm
content: I'm not saying it's a clear cut violation, I'm saying the GPL only tag shenanigans are mostly meaningless because Linus&co are trying to claim copyrights for other people's code. The only thing Linus can do if he doesn't like the GPL any more and wants to truly carve out part of the kernel interface for binary only modules is to rewrite everyone else's code and relicense it under a different license, otherwise it's all bluster.From theTLDP module howto:QuoteLawsuits are an expensive and often unprofitable game even if you win, but it only takes one dogged individual (like with the VMWare case) and a single judge to make this house of cards collapse. So caveat emptor (even if Linux is "free").

author: janoc
author_rank: Super Contributor
timestamp: March 08, 2019, 03:32:21 pm
content: Quote from: Marco on March 07, 2019, 02:10:38 pmI guess you have to be living in a cave or something, then.These debates about the licensing and GPL violations are a regular staple on the kernel mailing list. Again -that you do not hear about lawsuits does not mean anything! Most of these things are settled outside of courts before any lawsuits are filled, with confidentiality agreements on both sides.The long standing policy of both Linux devs and FSF is to give people the benefit of doubt and chance to correct their mistakes.Only if they don'tthe lawyers get involved. Not to use a copyright as means to shake companies down for money by filing lawsuits all the time. That's pretty much the last resort.By this time pretty much everyone knows that Linux is not free for taking and that there are consequences, so companies mostly obey the rules.Quote from: Marco on March 07, 2019, 02:10:38 pmThat's not the point. The point of that tag is that if your module uses APIs that have this tag, then you can't claim ignorance anymore.Quote from: Marco on March 07, 2019, 02:10:38 pmThe tags are a tool to clearly delineate the boundaries of the space, that's all. The rest will be always for the individual copyright owners and their lawyers to deal with.Quote from: Marco on March 07, 2019, 02:10:38 pmAnd how many graphic drivers are derivative works of Linux kernel? Usually the same blob is used whether the board runs Linux or e.g. VXWorks, just the API shim is different. If you want to argue that this is a GPL violation, then you need to present some more evidence than this sort of hand-waving.BTW, there are open source graphic drivers for mobile GPUs too:http://linux-sunxi.org/Maliand a good summary here:https://nullr0ute.com/2017/09/the-state-of-open-source-accelerated-graphics-on-arm-devices/E.g. Tegra is open source, Vivante is, Qualcomm's Adreno has an official driver, there is even some work going on the Videocore from Broadcom.You really should do some research before posting this stuff - three posts and all three were trivial to debunk with 5 minutes of googling.

author: Marco
author_rank: Super Contributor
timestamp: March 08, 2019, 03:38:19 pm
content: The Chinese SOC manufacturers don't give a hoot about VxWorks ... they support Android, and sometimes half heartedly plain Linux on the side. Often with a whole bunch of kernel version specific blobs, no shims in sight. The open source versions of the drivers are not the ones bundled in most devices.Not that it matters if they are derivative, the project as a whole is derivative and the linking is intimate ... the GPL is designed not to allow anything intimately linked as a bundle without an offer for source code, no matter how many shims you put in between. You still need that GPL license to distribute Linux in the first place, derivation is irrelevant. NVIDIA's original workaround was acceptable because (at the time) they didn't bundle the distribution.Maybe the courts will at some point invalidate that intent, but that will make all binary modules okay. The GPL only tags as irrelevant as they are now.

author: magic
author_rank: Super Contributor
timestamp: March 08, 2019, 04:44:17 pm
content: Quote from: Marco on March 08, 2019, 03:38:19 pmThe Chinese are the Chinese, the same laws don't apply to them. Don't imagine you will be allowed to get away with any of that.Quote from: Marco on March 08, 2019, 03:38:19 pmIntimacy is not a concept in copyright law nor in the GPL and neither are virality or shims for that matter. What matters is not just the delivery format of the two pieces of code in question but also how they interact, how much have in common, what's their historic origin and so on.Such is the position even of FSF themselves and probably was since the dawn of time.Quote from: Marco on March 08, 2019, 03:38:19 pmNo such thing will happen. You can't violate copyright simply because you use the same executable file format as some other project which doesn't violate copyright. Nor can you get away with copyright violation in the West for the reason that somebody else is getting away with it in China.

author: Marco
author_rank: Super Contributor
timestamp: March 08, 2019, 05:10:16 pm
content: Quote from: magic on March 08, 2019, 04:44:17 pmTheir position is that any kind of linking (with bundled distribution) will mean the GPL covers the whole. Shims, static, dynamic ... it makes bugger all difference as far as FSF is concerned.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: March 08, 2019, 09:48:57 pm
content: It's not clear in my mind if the source has to be provided for a loadable kernel module/driver. I've chosen to keep the driver as stripped down as possible with a view that I will either publish the driver source or not release a final Linux based solution. I'm leaning towards the latter.

author: OwO
author_rank: Super Contributor
timestamp: March 10, 2019, 03:42:14 am
content: I don't get all this faff. The solution is pretty simple: if you develop and release software that is heavily based on a GPL component, such that it can be considered to be "developed for" or a "derivative work" of the component, then you must allow those who receive the binary to obtain your source code under a compatible license. Your license can be LGPL or MIT or BSD or whatever, it doesn't have to be GPL.If you want to release proprietary software then you better code everything yourself (or hire people to do it) rather than take advantage of volunteer effort and profiting off it.

author: Someone
author_rank: Super Contributor
timestamp: March 10, 2019, 04:36:38 am
content: Quote from: OwO on March 10, 2019, 03:42:14 amThe original question (answered very well in amongst all the noise) is how to meet GPL compliance when distributing a system that includes some GPL components. Its still not made easy and there are many examples of projects which are just ignoring the requirements, the solution is not simple.

author: blacksheeplogic
author_rank: Frequent Contributor
timestamp: March 10, 2019, 05:03:54 am
content: Quote from: OwO on March 10, 2019, 03:42:14 amIt's not that clear cut.If everything developed runs in user space there is no requirement to provide source code. However, if it is a kernel loadable module their possibly is. We not talking in either of these cases using other libraries, it just running on the platform.Development can more easily not support Linux, there's no really compelling reason in most case, it's much easier to develop for one platform - typically Windows with it's market share, and if a second platform is wanted OSX, together these cover the vast majority of the user base. Why should developers go to the effort of also providing Linux drivers & support? It's a small market, and it is far easier not too. The Linux community wants more mainstream support it's not development asking.If development want to support Linux which is not a main target market, they have a lot more considerations over where code is placed and how it structured in order to make the driver is a thin as possible which is not always ideal and it' compromises ALL platforms if code reuse is required.Personally, I feel it's too risky to distribute binary only kernel drivers, there was a movement some years ago to disallow loading of non-GPL kernel drivers, and although it failed it could always come back so the safe approach in my view is to keep the driver thin or don't support the platform. The second being the easier option.I'm not getting into the debate on open verse close, just pointing out one over looked aspect. It's not as one sided as you seem to apply with development riding the wave of free work, Linux is not as attractive as you make it out to be. There are few benefits to supporting the platform. Given the market distribution little reason for development to grow their Linux offerings especially if it involves a lot more work.

author: magic
author_rank: Super Contributor
timestamp: March 10, 2019, 09:24:25 am
content: I wonder what's the situation with Windows.Are Windows drivers derived works of Windows?Do they need license from Microsoft to be produced?Do they need license from Microsoft to be distributed?Do they need license from Microsoft to be distributed as part of an embedded Windows installation?Does Microsoft grant such license somewhere in that TL;DR EULA?Anyone knows?

author: nick_d
author_rank: Regular Contributor
timestamp: March 11, 2019, 08:22:59 am
content: Good points about whether the rules are different for proprietary kernel device driver support vs GPL kernel device driver support, and about whether it is easier/wiser for companies to not support Linux given these issues.Let me say though, that I completely disagree about there being few compelling reasons for companies to support Linux in addition to the usual suspects being Windows and Mac OS.I can certainly see where this is coming from, and I would have completely agreed -- 20 years ago. However, this is not 1999, this is 2019 and the landscape has shifted significantly since then.I assume you are talking about drivers for consumer devices (printers, cameras and such) to be connected to a desktop or notebook PC. Because if you're not, the argument is easily refuted given that routers, phones etc all use Linux today.Even then, the argument is pretty thin. Why do NVidia and AMD both produce high quality GPU drivers for Linux? And why do essentially all printers and office multifunction units supply a driver? Granted its basic printing functionality and not all featured. However, they do this because the market demands it and because not to do so is a competitive disadvantage. Others will soon follow.Linux has a much higher profile than 20 years ago. Many organizations now use it on the desktop, including the one I work for. Check your employment pages if you don't believe me. As many demand Linux as MS skills today. It is not yet ubiquitous in the home or in education, but this will follow slowly.MS has not done themselves any favours with their current horrible offerings. Up to Windows 8 was essentially useable if a bit annoying. That's no longer the case. Even the Windows 10 laptop I bought brand new for my wife had non working wifi and touchpad out of the box due to driver issues. I couldn't believe how bad it is. Mac OS also is not keeping up at all.And let us not forget web, the great equaliser and disrupter. Since the Internet largely runs on Linux it makes the local OS increasingly irrelevant, except if you are a web developer and therefore must run a Linux desktop.cheers, Nick

author: Marco
author_rank: Super Contributor
timestamp: March 11, 2019, 02:50:42 pm
content: Quote from: nick_d on March 11, 2019, 08:22:59 amOf those, only NVIDIA bundles closed source drivers with Linux. When they first used the shim trick the general consensus was their driver was only acceptable because they didn't bundle. That consensus slowly eroded as Linus&Co stood by while binary modules were bundled left and right, but the original reasons behind the consensus never did. Status quo can convince even judges, but still ... caveat emptor.Linus&Co are a bit of bloody assholes in this respect by the way, if this ever goes to court and jurisprudence comes down on the side of bundled binary modules not being covered by GPL partly thanks to the status quo they build, the GPL will forever be weakened.

author: newbrain
author_rank: Super Contributor
timestamp: March 12, 2019, 01:42:22 pm
content: Quote from: magic on March 10, 2019, 09:24:25 amOf course, IANAL & TINLA.Here's my reading of the WDK (device drive SDK)license:They are derivative works of the WDK.Yes, if you use the WDK.Yes, as above.I would say it does not make a difference.Yes, under the conditions in the WDK license.But the above applies to the distribution of code included in the SDK, in object/lib/source forms (each with specific rules).For your own driver code, we can look at the many examples of windows drivers onthis Microsoft github repo.The license isMS-PL, which is considered Open Source by OSI.It grants the right to liberally distribute the code and derivative works, and gives some patent protection, but it's not a copyleft license.TL,DR: You are able to distribute your code liberally, but the parts of WDK are subject to a specific Microsoft license.