Slashdot Mirror
Friendlier GPL-Enforcement Permission Proposed By Linux Kernel Developers (kroah.com)
The former Executive Director of the Free Software Foundation -- and Slashdot user #41121 -- contacted Slashdot with this announcement. bkuhn -- now president of the Software Freedom Conservancy --
writes: Software Freedom Conservancy, home of the GPL Compliance Project for Linux Developers, publicly applauded today the proposal of the Linux Kernel Enforcement Statement, which adds a per-copyright-holder-opt-in additional permission to the termination provisions of Linux's GPLv2-only license.
It apparently addresses a developer who "made claims based on ambiguities in the GPL-2.0 that no one in our community has ever considered part of compliance," according to a statement from some of the kernel developers who drafted the statement. While the kernel community has always supported enforcement efforts to bring companies into compliance, we have never even considered enforcement for the purpose of extracting monetary gain... [W]e are aware of activity that has resulted in payments of at least a few million Euros. We are also aware that these actions, which have continued for at least four years, have threatened the confidence in our ecosystem. Because of this, and to help clarify what the majority of Linux kernel community members feel is the correct way to enforce our license, the Technical Advisory Board of the Linux Foundation has worked together with lawyers in our community, individual developers, and many companies that participate in the development of, and rely on Linux, to draft a Kernel Enforcement Statement to help address both this specific issue we are facing today, and to help prevent any future issues like this from happening again. It adopts the same termination provisions we are all familiar with from GPL-3.0 as an Additional Permission giving companies confidence that they will have time to come into compliance if a failure is identified.
It apparently addresses a developer who "made claims based on ambiguities in the GPL-2.0 that no one in our community has ever considered part of compliance," according to a statement from some of the kernel developers who drafted the statement. While the kernel community has always supported enforcement efforts to bring companies into compliance, we have never even considered enforcement for the purpose of extracting monetary gain... [W]e are aware of activity that has resulted in payments of at least a few million Euros. We are also aware that these actions, which have continued for at least four years, have threatened the confidence in our ecosystem. Because of this, and to help clarify what the majority of Linux kernel community members feel is the correct way to enforce our license, the Technical Advisory Board of the Linux Foundation has worked together with lawyers in our community, individual developers, and many companies that participate in the development of, and rely on Linux, to draft a Kernel Enforcement Statement to help address both this specific issue we are facing today, and to help prevent any future issues like this from happening again. It adopts the same termination provisions we are all familiar with from GPL-3.0 as an Additional Permission giving companies confidence that they will have time to come into compliance if a failure is identified.
Fines and penalties aren't always about pure monetary gain. They are a means of punishment for wrongdoing and a way to dissuade others from engaging in the same behavior. Absent payment as a penalty, I suppose we could take the board of directors of a company found in violation of the GPL and have them shot.
Have gnu, will travel.
I think as Linux kernel developers we should take note of the very personal touch the MPAA has used to deal with violators: An early morning visit by a paramilitary police force.
“Common sense is not so common.” — Voltaire
Copyright law says you can't make copies for another without permission.
The BSD license grants an exception to copyright, (like all distribution licenses for copyrighted works,) which lets you copy it, but also lets you take away that permission from whoever you distribute the software too.
The GPL license also grants an exception to copyright, but says you can't take it away from whoever you distribute the software too. In other words, they get the same right to run, modify, and distribute the software as the licensed work you based your changes upon.
Linux GPL enforces compatibility. Without the GPL Linux would fracture into hundreds of proprietary dialects like BSD has.
True, payment can also be used to encourage compliance BEFORE getting caught. "If you don't comply from the start, you'll have to pay when you get caught", is one approach. It seem McHardy is seeking personal gain, though, based on his tactics of putting time pressure on them, etc.
There may be no right way to do it. Giving a warning and allowing them to come into compliance with no penalty makes sense if someone just goofed. On the other hand, a policy of always allowing 30 days to cure with penalty could be interpreted as "there's no reason to comply until after you get caught". The best approach, IMHO, may be a small penalty for non-compliance as soon as someone gets caught - enough penalty that it makes sense for companies to comply BEFORE they get caught, and 30 days to fix it before more significant penalties are pursued.
If your concern is maximum freedom for the developer, then yes. Pragmatically, though, there's a lot more potential developers with the GPL than with BSD/ISC/MIT licenses. Also, maximal freedom includes the freedom to not issue updates, for things like KRACK.
That's largely untrue. Most of what corporations do involve internal software for which the license rarely matters. The only thing they generally care about is having a working solution to their problem. Beyond that, yes, vertically and horizontally integrated companies with many subsidiaries have to start worrying about licenses, at which point they're likely to go commercial (or freeware) because they don't trust the BSD any more than the GPL. Ie, they don't want source code and want someone else to blame if copyright violations are found.
As for academic interests, that's even trickier. On the one hand, yes, a large part of academia today has turned into figuring out how to take a research project and spinning it off to a business that will provide royalties to the host university. The flip side of that is academia requires transparency and wants an ability to track attribution for things that can't be directly monetized but for which the prestige will encourage more funding to the university. So, they want a combination of BSD or GPL as appropriate.
Well, "need" is a strong word, but I can certainly understand the strong desire for it. The opposite side of this is that pragmatically going proprietary can bite you in the ass, even with GPL software. Look no further than Android.
I don't think it has anything to do with realizing anything except the last part: the researches are the ones most capable of quickly going to market with the code, and they only BSD license certain parts of the code that alone aren't enough to make a product. I have no qualms about that, but this is more about enlightened self-interest, not some recognition of a duty from receiving public money.
I would counter that as IoT and just general internet devices become more common--as if they weren't common enough, already--the pragmatic truth is that proprietarism, whether it's in the actual code or in the nature of locking down a system as a whole against modification, is an evil that will do us all great, systemic harm. Right now, I have many devices that are un-upgradable which are vulnerable to all sorts of attacks. The only responsible thing for me to do is never connect them to the internet. Yet the pragmatic truth is that many devices are heavily useless without internet.
And this doesn't even delve into the area of many devices I or others have that I likely am not aware of wildly published vulnerabilities. Even spending substantial effort and thought, the current security vulnerability ecosystem is an avalanche of reports, fixes, workarounds, and wontfix. It is to the point that the "safe" thing to do is basically discard all one's internet devices every year--which is an ecological nightmare--and only buy reputable brands which come pre-loaded with all security patches. And that
I think both BSD and GPL style licenses have their place in the world. A BSD-style license is useful for those who wish their code to be used as broadly as possible, whether by commercial or open source. A GPL license is appropriate for those who are first and foremost advocates of open source, and want maximum protection to ensure their code is only used in open source products.
This simply reflects a different intent or priorities of the authors. You hear slogans like "GPL is about user freedom", which is just shorthand for open source advocates believing that, with some good reason, that open source products are more consumer-friendly than close source. Yet the flipside to that is the simple truth that many software products that people find valuable seem to flourish as commercial products.
For my own open source libraries, I release them under the MIT license. I appreciate it's "do what you want with it" simplicity, since my goal is not open source advocacy, but simply to make a library that anyone might find useful. But I also appreciate the fact that not everyone has the same priorities as I do. I'm not sure the open source movement would be where it's at today without the hard-core advocates who insist on using the GPL.
Irony: Agile development has too much intertia to be abandoned now.
Even in enforcing a license, a court must decide how exactly to do so. If monetary damages are appropriate, how much money exactly? A court should hear from the copyright holders and from the defendant before deciding on remedies.
As you said, there are many contributors to the kernel, and many contributors to netfilter. If the vast majority of copyright holders relevant copy right holders say "we just want them to start complying, we don't want any money other than expenses for this case", a court should duly noted that.
Where one person has contributed much less than 1% of the code
Once a prominent contributor takes a substantial stand against this additional permission, watch someone file issues to replace this contributor's contributions.
This is a corporate push to protect corporate interests while they violate the GPL. The monetary findings that punish companies are so rare that there is no problem here at all. Liars working for moneyed interests.
It would have to be a clean implementation of an interface that existed before the contribution that they mean to eliminate. Otherwise it's still a derived work and the contributor maintains control over it through the "viral" nature of the GPL. Anyone who has worked on the part to be eliminated need not apply: They're too likely to end up with a result that would not elminate the claim.
It's fascinating that major open source proponents are trying to make an end run around one of the most well-known open source licenses and the rights it gives to countless authors who have contributed to one of the biggest open source projects.
but switched over to be more in favour of the BSD/ISC/MIT licences because they are maximally free.
I take exception to that. The BSD and GPL are equally free, but they split on whom gets that freedom; one gives an extra freedom to the immediate developer to change the licensing, one gives extra freedom to the downstream developer by propagating all the freedoms onto to them.
Most people using BSD 'derived' code have none of the freedoms BSD offers. How exactly do you argue with a straight face that this is the better outcome?
More and more, academics are releasing their code under the BSD/ISC licences because they realise that because they are receiving public money to fund their code and research, by dint of this, they must release the results of that money to the public in a maximally free way,
That amounts to the public paying for all the bakeries ingredients, and then the bakery sells bread back to the public. Yes, that's a pretty ideal system for the baker; not such a good deal for the public though. Why are they funding the baker's ingredients exactly?
If it were the GPL the baker would also have to share how the bread is made, and people wouldn't have to depend on him if they wanted to make their own bread. (This, according to you is the 'less free' option.)
Small wonder the baker prefers the BSD.
Some code needs to be proprietary--life is about pragmatism sometimes, not always about ideology.
IF you ever bother to ask yourself why, and really dig deep, you'll have a tough time coming up with a satisfactory answer.
Note that I don't contend the pragmatic arguments aren't real, just that they are deeply unsatisfying on a philosophical level. They point to difficult to solve problems with society itself, and rather than solve these difficult problems, the pragmatist just accepts them as unsolved and proceeds to go for lunch. That's not much of a solution.
Licensing differences lead to radically different outcomes. Free software (not just the variants of the Linux kernel containing only free software) is more attractive because the effect of the license on the users. Hollywood movies are licensed restrictively even disallowing verbatim non-commercial sharing (in other words, treating friends like friends). In addition, Hollywood movies often use digital restrictions management (a proper expansion of "DRM" from the majority standpoint, that of the viewer) to enforce more than the license restricts. DRM means non-free software control over one's computer since all DRM software is proprietary. Proprietary software is inherently unethical no matter its purpose. As people put more sensitive data on their computers, more use of proprietary software means predictably uglier outcomes even for those who participated fully in a DRM scheme.
Free software implements an environment of sharing and cooperation as well as individual control over one's computer (to the limits of one's interest and skill). These are good unto themselves but also have good consequences for businesses (which is a nice consequence but not chief goal of the free software movement). I trust I don't have to review how many commercial developers and distributors benefit from the Linux kernel. Commercial distribution of Hollywood movies as we currently see, by contrast, implements control over the viewer, fund an increasingly punitive copyright regime, and fund an unjustifiably long term of copyright. /.ers who pay to see the Star Wars movies would be wise to recall this; they're directly funding the organization most widely associated with the last copyright term expansion—Disney, for example.
Violating a free software license means mistreating a person or organization that was respecting a user's software freedom. But violating a proprietary license can be the "lesser evil" as Richard Stallman once put it in his talk about why society needs free software and why we should value software freedom for its own sake: Someone who had a useful nonfree program under a license that prohibited non-commercial verbatim copies had to choose between obeying the license of that program (and denying their friend a copy of the program) versus helping their friend who wanted a copy of a program by distributing a copy. This came up in the context of discussing free software freedom #2: "the freedom to help your neighbour. That's the freedom to make copies and distribute them to others, when you wish":
He goes on to explain that picking the lesser evil is not good, but one should aim the harm at the party that did harm (those that publish useful proprietary software) not to an innocent party (the friend). So the solution is to only have free software so you never get into this dilemma in the first place because all of the software you have you're free to share. Here we can see that the same copyright scheme grants power to radically different lic
Digital Citizen
Copyright law is a joke and has functionally destroyed or delayed unfathomable levels of productive economic activity.
The Linux Foundation needs to bring in Stephan Kinsella on retainer to help with this. Probably no one else has done as much legal-philosophical work into the nature and practice of modern IP as he has.
There is a grey area around things like the NVIDIA blobs and other "binary kernel modules". But when companies refuse to even try to comply with the GPL and share the kernel source for their device, there is no "grey area", its just as much of a copyright violation as it is when someone shares an illegal copy of the latest Star Wars film.
Its the same when someone distributes a kernel module or changes and has based it on existing GPL code (e.g. when Samsung distributed kernels for some of their phones but didn't include the code for the ExFat module even though said module was derived from the GPL FAT code)
Yes there are many GNU/Linux distros, but they are binary compatible, while the BSDs are not.
Some developers simply will not license their software under the GPL.
And?
Using other licenses is therefore an excellent solution because it is the only way the software will be released at all.
What do I care if they release it or not?
Are you objecting to their right to release their own software under whatever license they see fit? I see no legal, ethical, or moral grounds to do so.
If they write it from scratch themselves they can do whatever they like. I didn't contribute to it. I didn't fund it. As long as I don't have to use it, they can do whatever they want.
"Replaces" does not mean "derived from". Cars replace horses. Cars are not derived from horses. More to the point, GPL Linux replaces Unix; Linux is not a derivative work of Unix.
SCO spent millions on lawyers arguing that Linux is a derivative work of Unix, which it replaces. Several courts ruled it is not. It's entirely possible to replace something without creating a derivative work.
> Anyone who has worked on the part to be eliminated need not apply
Partially true. Someone who really knows the old code inside and out would need to write a significantly better or different replacement, in order to make I clear that it's not essentially the same implementation. Someone very familiar with it may know of fundamental problems with the old approach and have ideas about a new, better approach. That would be fine. If an existing developer doesn't have ideas for a new approach, it's best that the new code be written by someone unfamiliar with the implementation details of the old code.
Assuming you developed all the code yourself from scratch then it has nothing to do with the BSD and GPL debate. Go nuts. It really has nothing to with the conversation though.
On the other hand if you developed it based on GPL then you are likely in violation of the license if you aren't making the source available.
If you developed it based on BSD code then you are within your rights...but your claim of 'building your own business and all the money generating assets in it' was pretty much bullshit.
Damn newbies, they ruined this place years ago!
Apparently, a few years ago, some Linux developer named McHardy started enforcing the GPL in Germany on his own. See e.g. the background article at https://sfconservancy.org/blog...
It looks like he tends to sue GPL-violators for about 2000€ + his costs (attorny fees for trying to settle out of court, costs for reverse engineering):
Example where he successfully sued the Germany subsidy of a Taiwanese hardware manufacturer for a total of about 2900€: LG Frankfurt, 2-6 O 224/06 http://www.jbb.de/fileadmin/do...
However, there was also a case where he demanded and got more: A GPL-violator that he had contacted in 2010, and got to comply with the GPL out of court back then became a repeat offender in 2012. He sued them for for 5000€ + attorny fees of 2000€: LG Hamburg, 308 O 10/13 http://www.damm-it-recht.de/lg...
On the other hand, most Linux developers apparently think that free software developers and organizations tasked with GPL enforcement should not profit from suing GPL violators. The Software Freedom Conservancy is losing money from enforcing the GPL, and asks for donations to be able to continue their work.
Philipp
More and more, academics are releasing their code under the BSD/ISC licences because they realise that because they are receiving public money to fund their code and research, by dint of this, they must release the results of that money to the public in a maximally free way,
That amounts to the public paying for all the bakeries ingredients, and then the bakery sells bread back to the public. Yes, that's a pretty ideal system for the baker; not such a good deal for the public though. Why are they funding the baker's ingredients exactly?
Exactly. I wonder how many of the academics choosing BSD like licences are later setting up businesses that use closed source derivatives of that code? That way, they can close the code, regardless of whether they personally hold the copyright or not, and including any outside contributions.
Apple makes a considerable amount of their software available as Open Source. They most definitely do not believe that a walled garden is the only way to live. They do it because it makes them money.
If software was developed using public funding and released under a BSD license, you have the right to use that software however you like.
Right up until someone else takes it, extends it a bit, changes the license, and I'm stuck using it. Its still 95%+ the publically funded software... with 0% of the rights.
Except that the downstream developer has few freedoms. Sure they can modify the code and if that is all you care about then yes, it is a nice freedom
That's already one more freedom than the downstream developer who received "upstream its BSD but not anymore code"
But that developer has no freedom in choosing how they can redistribute the product of their work: that is decided for them by the GPL.
The downstream developer receiving relicensed BSD code has no right to modify OR redistribute. Yeah the GPL puts some restrictions their redistribution... to PRESERVE the right of redistribution further down the line.
The guy with re-licensed code based on BSD has no rights at all. The guy upstream stripped him of all his rights. He can't modify it, he can't fix it, and he can't redistribute it.
Later on, a downstream developer cannot be "stripped" of rights he never had.
Is this the maximal freedom the BSD enables? Where a developer doesn't have to worry about losing any rights, because he never got them in the first place!
He does however have recourse to use the original version.
iOS is based on BSD. How much value is there in the 'recourse' to the 'original version'? Or a checkpoint firewall? Or a juniper device?
No rights to lose, because you don't have any to start with.
Some people would say it's reasonably fair that the downstream developer only got the same rights to the BSD code that the first developer got. Just because someone gave another person a gift doesn't entitle you to a gift from the receiver.
Except that *I* might be the original developer, or the guy who paid the original developer. And all you did was take my 'gift' put on some wrapping paper and a bow, and then sell it back to me with all the rights I gave you stripped away.
The code I gave you had these rights attached, and the extended code you sent back me no longer has them. To say... they weren't 'stripped', just 'declined to be granted' is pointless sophistry.
Its legal and within the license, and its moral in the sense that I gave you permission to do this in the original license, but its still a dick move IMO, and its morally dubious within most moral frameworks... in the sense that it wasn't strictly 'wrong'... but there's not a lot of good arguments for how it is 'right'?
So I guess we're going to see yet another different network package management system in Linux soon?
Unless I'm grossly misunderstanding what you mean by "network package management system":
A package management system is an independent process in user space. The only Linux interfaces on which APT or DNF relies are the syscall interfaces, which were already subject to an additional permission.
Thanks for circling back to the very beginning of the discussion.
Most people don't know licensing. They choose the GPL or the BSD in many cases because they do *want* it to be 'free', and they don't really understand the difference. Then some twit comes along and sasy 'go BSD' its maximally free -- the GPL has restrictions.... so they follow that advice.
And then when they find someone put a nice bow on their 'free code' and is selling it for big money, they often say ... this isn't what i intended at all. I wanted it to be free; I wanted other people to take it and extend it... I didn't release it so that big companies could put a bow on it and then try to sell it back to me with strict licensing terms.
"You can't exactly cry 'unfair' if people do what's allowed, but not what you expected."
Quite so. This is why its important to be very clear exactly what each license allows and doesn't allow. So that your expectations are *met*.
You are absolutely right that lots of authors are fine with their code being BSD... and that's fine if that's what THEY want. I've released BSD code myself, usually smaller library type stuff where I don't care who uses it for what purpose, or for sample/demo type stuff.
My preference for GPL is more for bigger projects, where the tendancy for another entity to just try and 'squat and monetize it' becomes more of an issue.
And big projects funded by public universities/public research grants/ etc a GPL license makes more sense. Corporations shouldn't be allowed to just help themselves to that and then sell it.
You really think developers don't understand the licensing they chose
In a lot of cases: yes.
It has nothing to do with my preference; lots of people, including developers don't really know the ins and outs of the GPL or BSD or the LGPL or GPLv3 vs v2, or AGPL, or MPL... why should anyone expect otherwise?
Beyond the very basics, this is a specialty for lawyers not developers. Why do you think the average developer knows this stuff inside out?
Yes.