Grsecurity stable patches to be limited to sponsors
We decided that it is unfair to our sponsors that the above mentioned unlawful players can get away with their activity. Therefore, two weeks from now, we will cease the public dissemination of the stable series and will make it available to sponsors only. The test series, unfit in our view for production use, will however continue to be available to the public to avoid impact to the Gentoo Hardened and Arch Linux communities."
Posted Aug 27, 2015 5:30 UTC (Thu)
by liam (guest, #84133)
[Link] (4 responses)
Posted Aug 27, 2015 12:30 UTC (Thu)
by ewan (guest, #5533)
[Link] (3 responses)
Posted Aug 27, 2015 19:13 UTC (Thu)
by liam (guest, #84133)
[Link] (2 responses)
Posted Aug 28, 2015 0:31 UTC (Fri)
by spender (guest, #23067)
[Link] (1 responses)
-Brad
Posted Aug 29, 2015 3:07 UTC (Sat)
by liam (guest, #84133)
[Link]
Best/Liam
Posted Aug 27, 2015 5:46 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (51 responses)
So it should be easy to discover what is the name of this multi-billion dollar corporation?
> Therefore, two weeks from now, we will cease the public dissemination of the stable series and will make it available to sponsors only.
How will it hurt crappy "companies in the embedded industry not playing by the same rules as every other company"? You said yourself that they use a "several year old, unsupported version of grsecurity that they've modified" because they are "driven by a need to mark a security checkbox at the lowest cost possible". So they'll simply use your test series instead of your stable series.
I think your decision will only hurt your users. IMHO the real solution for Grsecurity is to become a member of "Software in the Public Interest" or "Software Freedom Conservancy". You'll have legal help to fight those mega-corporations.
Posted Aug 27, 2015 6:39 UTC (Thu)
by edomaur (subscriber, #14520)
[Link] (50 responses)
Posted Aug 27, 2015 7:41 UTC (Thu)
by Seegras (guest, #20463)
[Link] (49 responses)
Posted Aug 29, 2015 15:15 UTC (Sat)
by RCL (guest, #63264)
[Link] (48 responses)
Posted Aug 29, 2015 18:59 UTC (Sat)
by clump (subscriber, #27801)
[Link] (28 responses)
Posted Aug 30, 2015 21:16 UTC (Sun)
by RCL (guest, #63264)
[Link] (27 responses)
Posted Aug 31, 2015 0:25 UTC (Mon)
by clump (subscriber, #27801)
[Link] (26 responses)
Posted Aug 31, 2015 0:31 UTC (Mon)
by RCL (guest, #63264)
[Link] (25 responses)
Posted Aug 31, 2015 1:43 UTC (Mon)
by pizza (subscriber, #46)
[Link] (24 responses)
The thing is, "comparable more permissively licensed options" don't actually exist.
Would Google have used Linux for the Android kernel if it had anything remotely viable as an alternative? This is the same Google that replaced *every* other GPL component component, after all.
The Linux kernel is very far ahead of everything else (permissive or otherwise) in both features and hardware support, even if you only count mainlined stuff.
Posted Aug 31, 2015 1:50 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
Posted Aug 31, 2015 2:15 UTC (Mon)
by pizza (subscriber, #46)
[Link] (16 responses)
Granted, the latter is generally of a much higher quality than the former, but let's be honest here -- to the end user, the old situation is the same as the new situation -- You're still at the complete mercy of your vendor.
Posted Sep 2, 2015 14:18 UTC (Wed)
by RCL (guest, #63264)
[Link] (15 responses)
Posted Sep 6, 2015 7:08 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link] (14 responses)
Usually that marks the point where a technology is better than its predecessor. See LibreOffice for example...
Posted Sep 7, 2015 0:47 UTC (Mon)
by RCL (guest, #63264)
[Link] (13 responses)
Posted Sep 7, 2015 1:21 UTC (Mon)
by pizza (subscriber, #46)
[Link] (10 responses)
FWIW, That's not a very good metric. Apple in particular is the primary backer of LLVM. I can't speak of Sony or Google specifically, though I know the latter heavily uses (and contributes to) GCC as well. (And last I checked, Android's NDK still uses GCC). GCC is heavily "used by professional developers" day in and day out.
Incidentally, "professional developer tools" are amongst the worst I've ever had the mispleasure of using. I can't name names because I'd open myself up for legal action.. then again, that's also an example of the sorts of crap one has to deal with when using proprietary tools. One of them even has BSD (4-clause) "open source" stuff in it, not that said code has been sync'd with upstream in years -- leaving us end-users dealing with bugs long since fixed upstream. But hey, it was built on business-friendly "open source", with so much freedom that we can't do anything to fix it.
Posted Sep 7, 2015 2:33 UTC (Mon)
by RCL (guest, #63264)
[Link] (9 responses)
Matter of time; they switched: https://www.phoronix.com/scan.php?page=news_item&px=M...
> Incidentally, "professional developer tools" are amongst the worst I've ever had the mispleasure of using.
FOSS code is usually no better; Heartbleed and Shellshock provided the occasion to peek into the most commonly used software, only to find the practices outrageous.
Most importantly, commercial products are being QA'd since they come with guarantees, thus no matter how the code looks, it works (usually, or at least there's someone accountable to make it work). Testing of most Linux distributions is less formal, and for "rolling" ones essentially happens in "production", so all bets are off.
Posted Sep 7, 2015 14:24 UTC (Mon)
by pizza (subscriber, #46)
[Link] (3 responses)
HAHAHAHAHA
I can tell you've never been on the receiving end of any commercial product.
Posted Sep 13, 2015 17:15 UTC (Sun)
by RCL (guest, #63264)
[Link] (2 responses)
Of course, this may depend on the company size and I suspect that if I were escalating issues as a singular end user and not in my employer's name they might have been prioritized differently, but that is expected: end users outnumber developers 99 to 1, no project - FOSS or commercial - can address all their needs at the same priority (and, no, most users cannot fix the issue by themselves in a FOSS product).
So in practice: with commercial products you have at least some feedback mechanism, while with FOSS, if you cannot fix the issue yourself (which may be because you simply don't have time, not just because you lack skills), you won't see the fix in reasonable time.
Most of the bugs I filed against FOSS products (SDL being an exception) are still open. They might have been fixed in practice, but there's no QA pipeline in place to verify that for each new release; unlike commercial vendors, FOSS don't seem to have resources to conduct regular bug scrubs.
Posted Sep 13, 2015 17:41 UTC (Sun)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Did you mean proprietary products here? FOSS != non-commercial.
Posted Sep 13, 2015 18:03 UTC (Sun)
by RCL (guest, #63264)
[Link]
Posted Sep 7, 2015 14:26 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
Um, I respectfully suggest you actually read the articles you reference.
That article says that now google uses LLVM to compile *CHROME* for production release builds. It does not apply to the rest of ChromeOS (aka heavily customized Gentoo), nor does it apply to Android.
Posted Sep 7, 2015 16:49 UTC (Mon)
by nye (subscriber, #51576)
[Link]
Posted Sep 13, 2015 17:01 UTC (Sun)
by RCL (guest, #63264)
[Link]
Also, lldb is being preferred to gdb, for which I was able to find a public reference: http://tools.android.com/tech-docs/android-ndk-preview
Posted Sep 8, 2015 17:36 UTC (Tue)
by lsl (subscriber, #86508)
[Link] (1 responses)
What kind of software comes with guarantees that are actually worth a shit?
Posted Sep 13, 2015 17:16 UTC (Sun)
by RCL (guest, #63264)
[Link]
Posted Sep 13, 2015 6:54 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link] (1 responses)
That is exactly why I said what I said: I will believe it when distributions move. Because they will move to using CLANG the day it is actually, technically better than GCC. Unlike Apple, Google and others who would move for business reasons or reasons related to sales, relationships between individuals within the companies and so on. If you have been exposed to decision making in large companies you would know, for sure...
Posted Sep 13, 2015 12:07 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Clang is already technically superior than GCC for many purposes -- Most prominently being its considerable advantage over GCC in C++ compile times (for roughly equivalent code size and performance). LLVM/Clang is also a much nicer codebase to work with, with a more modular internal structure, and is much easier to embed. This opens up entire classes of uses that are nearly impossible to do with GCC -- the fact that pretty much every graphics stack (F/OSS or otherwise) now uses LLVM to compile shaders and whatnot is a testament to that.
I know there are several efforts in play to utilize Clang by the major distributions, but that effort is focused more on uncovering subtle bugs that just happen to be hidden by what basically amounts to a compiler monoculture, and to a lesser extent finding ways in which Clang can be improved. There is no real desire to get rid of/replace GCC outright (outside of the big commercial concerns that are pumping so much money into LLVM, that is. You really must ask yourself why they're doing this, and what it means for you as a developer and/or an end-user..).
While I'm personally glad LLVM/Clang exists and has matured so rapidly, I'm disappointed that so much of the "enthusiasm" surrounding it is solely due to its licensing allowing proprietization and rabid hatred of anything to do with the FSF and its GPL. In doing so, they are enthusiastically acting against their own long-term interests, and proud of it.
Posted Sep 2, 2015 12:34 UTC (Wed)
by nye (subscriber, #51576)
[Link] (5 responses)
In a very real sense, it *isn't* the same Google, given that this choice was made before Google bought Android. It's entirely possible that, had Android started out as a Google project, it could have been based on FreeBSD.
Posted Sep 2, 2015 14:09 UTC (Wed)
by pizza (subscriber, #46)
[Link] (4 responses)
During those years, Google made many, many, many changes to the platform definition, but despite their massive effort to replace all other GPL components (even a new libc!), they chose to heavily modify Linux instead of making similar changes to another kernel.
Since then, Linux's feature and performance gap versus other Free kernels has only grown larger. (For all the complaining about how Linux's ARM stuff is a ginormous mess, everyone else is far, far worse...)
Posted Sep 2, 2015 14:35 UTC (Wed)
by RCL (guest, #63264)
[Link] (1 responses)
Posted Sep 2, 2015 14:46 UTC (Wed)
by pizza (subscriber, #46)
[Link]
That explanation doesn't fly, because Google went well out of their way to replace (and in many cases, create from scratch) alternatives to *every* other traditionally GPL component of a Linux system.
Posted Sep 3, 2015 11:46 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Well, you've sort of countered your own point there: after two years of heavy modifications, switching kernel would have increased the time to market by enough that Android might never have taken off. All of the other components were much more readily replaceable, either with drop-in replacements already existing, or by developing their own in tandem (based at least partly on BSD code, as it turned out), but the kernel was the largest and most specialised part.
I'm certainly not convinced (or trying to claim) that, given the choice from step zero, Google would definitely not have chosen Linux. I am convinced however that by the time Google bought Android it was already far enough along that changing the OS it's built on would have been commercial suicide for the project, and that Android doesn't therefore make a good example of Google's choices, because I don't believe they really had one.
Posted Sep 3, 2015 13:56 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
Sure they did, they could have not bought Android and went somewhere else, or started their own in-house because they certainly got a good look at the technology stack and roadmap as part of due diligence before purchasing the company. Google has invested a lot in the Linux kernel, not just in Android, over the years so it is still a good fit for the company, they have (and had at the time) a lot more Linux kernel expertise than BSD, even if in many cases what they run on top of the Linux kernel is Google proprietary.
Posted Aug 31, 2015 0:22 UTC (Mon)
by pizza (subscriber, #46)
[Link] (18 responses)
The most favourable excuse they can come up with is one of incompetence. But as the saying goes, sufficiently advanced incompetence is often indistinguishable from malice.
Posted Aug 31, 2015 0:40 UTC (Mon)
by RCL (guest, #63264)
[Link] (17 responses)
This makes even LGPL a non-starter in cross-platform software, since cross-platform these days includes platforms where dynamic linking is either forbidden or technically impossible by end user (most mobile and console OS are that way).
Posted Aug 31, 2015 2:07 UTC (Mon)
by pizza (subscriber, #46)
[Link] (16 responses)
At some point, especially once lawyers are involved, one can no longer use the "incompetence" excuse, especially when the liabilities (in the US) for getting it wrong are $150,000 *per copy*. This is especially true for companies that rely on copyright (such as Atari) which quite happily (and publically) wave that number around when someone else supposedly infringes upon their stuff.
> This makes even LGPL a non-starter in cross-platform software, since cross-platform these days includes platforms where dynamic linking is either forbidden or technically impossible by end user (most mobile and console OS are that way).
Given that platform SDKs fall under the "system library exemption" to the (L)GPL, you can't blame anyone but said mobile/console platform owners for deliberately creating that situation.
Posted Aug 31, 2015 2:33 UTC (Mon)
by RCL (guest, #63264)
[Link] (13 responses)
>Given that platform SDKs fall under the "system library exemption" to the (L)GPL, you can't blame anyone but said mobile/console platform owners for deliberately creating that situation.
What I am saying is that we're slowly moving to (or already are in) the world where a small number of developers using (relatively) open platforms create software for consumption by masses that use closed platforms, where exercising (L)GPL-mandated freedoms is both technically and legally impossible.
In such a world, BSD-licensed OSS is clearly preferable - developers can still share it between themselves to mutual benefit, but they can draw a clear border between themselves and the users when shipping the end product. (L)GPL fares much worse since a platform which is not under user's control is incompatible with its spirit, if not letter - FSF did not foresee that billions of people will be willing to give up what they considered essential freedoms for convenience.
Posted Aug 31, 2015 3:54 UTC (Mon)
by pizza (subscriber, #46)
[Link] (12 responses)
The (L)GPL doesn't distinguish between "users" and "developers" -- It reflects the FSF's position that *everyone* should have equal rights to use, inspect, modify, and distribute said software. That lack of distinction is critical, and is basically the entire point of the (L)GPL.
As for the superiority of BSD-licensed OSS, history shows time and again that without something to level the playing field, "developer mutual benefit" tends to rapidly fall to the wayside in the face of "value add" -- Let's not forget that Microsoft won the BSD wars.
> (L)GPL fares much worse since a platform which is not under user's control is incompatible with its spirit, if not letter - FSF did not foresee that billions of people will be willing to give up what they considered essential freedoms for convenience.
I don't think the FSF has ever deluded themselves as to the motivations of the general masses, but I suspect they're dismayed by the sheer number of developers that are jumping onto those closed platforms.
Posted Aug 31, 2015 5:04 UTC (Mon)
by RCL (guest, #63264)
[Link] (11 responses)
I know, and as much as I consider such position noble, I think it is too extreme and is at odds with 1% participation rule ( https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture) ). Whether we want it or not, people split into developers and users themselves, and (L)GPL, by ignoring human nature, deprives developers who put significantly larger effort than someone who simply repackages their software of receiving respectively larger reward.
> I don't think the FSF has ever deluded themselves as to the motivations of the general masses, but I suspect they're dismayed by the sheer number of developers that are jumping onto those closed platforms.
Well, duh. We all want to have a (stable) salary. I don't think I would enjoy being at the mercy of "sponsors" or donations, and I don't think anyone enjoys that, including grsecurity folks.
A lot of commercial developers are only in the industry for money. Yes, they may write worse code compared to those who have intrinsic motivation, but as long as their code does what is needed it does not matter - their sheer number does. Forget freedoms, create a sustainable model for making money on open platforms and you will see a *ton* of developers embrace it (vide Android). Freedoms will come as a side-effect.
Posted Aug 31, 2015 14:02 UTC (Mon)
by pizza (subscriber, #46)
[Link] (10 responses)
The only sustainable model for making money is to completely control the platform and take a cut of every transaction that happens on it. The other model is to sell services. The big boys do both, and everyone else basically fights over the table scraps.
I'm of the opinion that software in of itself is inherently non-sustainable; it only has long-term value as an enabler for providing a service -- The service is what has value, not the software itself.
But I digress.
The FSF has *always* placed Freedom first -- and relying on Freedom to follow as a side effect of something else is a strategy doomed to utter failure, especially when the trend is towards ever greater lockdown of platforms, not less.
Posted Sep 2, 2015 14:28 UTC (Wed)
by RCL (guest, #63264)
[Link] (9 responses)
I don't share it. Something that takes non-zero effort (sometimes *very* significant effort) cannot has no value.
But more importantly, selling software works. This is the ultimate proof that users are willing to pay not just for the service, but for the product as well.
> The FSF has *always* placed Freedom first -- and relying on Freedom to follow as a side effect of something else is a strategy doomed to utter failure, especially when the trend is towards ever greater lockdown of platforms, not less.
I think bringing ideology into engineering is just wrong. FSF is a mental Taliban fixated on their definition of freedom. Real freedom is being able to do what you want on the platform - if this includes paying a reasonable price, so what. So far "locked down" platforms enabled all sorts of creativity that open platforms still struggle to attract.
Posted Sep 2, 2015 15:21 UTC (Wed)
by pizza (subscriber, #46)
[Link] (8 responses)
Basic economics: everything eventually gets reduced to the marginal cost of producing another copy. Unfortunately for software, that marginal cost is effectively nothing, no matter how much effort went into creating the first unit.
> But more importantly, selling software works. This is the ultimate proof that users are willing to pay not just for the service, but for the product as well.
I'm afraid I don't understand the distinction you're trying to make here; are these users purchasing a product, or a service, or both? If the latter, what distinguishes the "product" from the "service"?
> I think bringing ideology into engineering is just wrong.
Ideologies are the foundations of societies.
> FSF is a mental Taliban fixated on their definition of freedom.
Are you seriously saying that you can't see the difference between a highly repressive group that literally mutilates (if not outright slaughtering) those who oppose them, and an organization that has consistently advocated to improve freedom for users of *software*?
> Real freedom is being able to do what you want on the platform - if this includes paying a reasonable price, so what. So far "locked down" platforms enabled all sorts of creativity that open platforms still struggle to attract.
So.. is "freedom" the point, or is "creativity?" -- You just said that you have to lock down the platform to foster creativity, but if the platform is locked down, you no longer have "real freedom" as you just defined it. You can't have it both ways -- the platform is either open or it isn't. If it's not open, then your freedom is being restricted.
Posted Sep 2, 2015 16:37 UTC (Wed)
by RCL (guest, #63264)
[Link] (7 responses)
Arguably for software a "copy" in that context is more like "next version" than a per-seat copy.
> I'm afraid I don't understand the distinction you're trying to make here; are these users purchasing a product, or a service, or both? If the latter, what distinguishes the "product" from the "service"?
When you are purchasing a game, you aren't (always) purchasing a service. Granted, there are free-to-play games that sell exactly this; however you may be aware of players' negative attitude towards this model. Apart of "pay to win" concerns (games that allow you to gain competitive advantage for money), there is a strong sentiment that players want to make their spending on a game "bounded". Hence traditional market where you pay a per-unit price and then play for ever is still going strong, especially for single-player games.
> Ideologies are the foundations of societies.
We are making software, not politics :)
>> FSF is a mental Taliban fixated on their definition of freedom.
> Are you seriously saying that you can't see the difference between a highly repressive group that literally mutilates (if not outright slaughtering) those who oppose them, and an organization that has consistently advocated to improve freedom for users of *software*?
There are differences in their goals and methods, but not in their dogmatic, inflexible approach. FSF ignores the fact that people, at large, rejected their ideas. They continue to persist at what they envisioned to be good for people and stick to their licensing model even as it slides more and more into radical / fringe corner, being displaced both by more permissive (and thus flexible) licenses and proprietary (but also flexible and affordable) licenses. They basically made a religion out of that, despite that their user base is thinning (I am willing to bet that even you don't type this from gNewSense or Hurd).
> So.. is "freedom" the point, or is "creativity?" -- You just said that you have to lock down the platform to foster creativity, but if the platform is locked down, you no longer have "real freedom" as you just defined it. You can't have it both ways -- the platform is either open or it isn't. If it's not open, then your freedom is being restricted.
It's not black and white. Despite all the fear mongering, locked platform aren't locked in any essential way and practically speaking, real freedom is possible on all major desktop platforms. Even on non-desktop platforms, the real freedom is not limited - granted, you are prohibited from turning PS4 into a desktop computer, but this is not what that platform is about anyway. Todays most gaming platforms are rather open to indie games - Steam is of course leading in that regard, but it's not hard to publish on PS4 these days either.
People aren't sheep - if the platform owner imposes unreasonable limitations (i.e. if there are practical use cases that are being restricted), users will either exert sufficient pressure or abandon the platform. So far very few platform owner were suicidal enough to enforce restrictions that go against the will of the majority of their user base (Nintendo did, and slid into obscurity).
Of course, if you take "all or nothing" approach, then you need to run gNewSense with open-source BIOS - not possible on post-2008 hardware. But this is very fringe case - arguing that stuff like that restricts your freedom is like arguing that your freedom is now restricted because you cannot secede from the US and form the CSA. There are some people for whom these "freedoms" are important, but the majority moved on from that to a more "higher level" freedoms.
Posted Sep 2, 2015 18:20 UTC (Wed)
by pizza (subscriber, #46)
[Link] (6 responses)
I suppose I lump games under the same general category as art and entertainment, as opposed to something functional that you depend or rely on.
...But I'm not going to compromise my livelihood or freedom just so someone else can be entertained.
> There are differences in their goals and methods, but not in their dogmatic, inflexible approach.
So.. you're saying that any organization focused on achieving some ideological goal is essentially the same, even if their goals (software freedom vs total domination of all facets of life) and methods (peaceful advocacy vs slaughter) are radically different?
I'm not sure why, but you seem to be under the impression that the FSF somehow forces people to bow to their ideals. At the end of the day, folks are free to do what they choose, and license their software under whatever terms they see fit.
If you can't see the difference between that and forcing folks to submit to your will under penalty of dismemberment and death, then I am truly sorry for you.
> FSF ignores the fact that people, at large, rejected their ideas. They continue to persist at what they envisioned to be good for people and stick to their licensing model even as it slides more and more into radical / fringe corner, being displaced both by more permissive (and thus flexible) licenses and proprietary (but also flexible and affordable) licenses. They basically made a religion out of that, despite that their user base is thinning
Ah, appealing to popularity. I can't help but be reminded of the expression "democracy is two wolves and a sheep deciding what to have for dinner."
The FSF has shown a remarkable ability to correctly predict the future -- Including the inevitability and outcome of the BSD wars, the effects and desired endgame of DRM, and the slow-motion train wreck that is Android and the upcoming IoT popcorn-fest.
The common thread of all of those things are that they are only made possible when users' rights are restricted -- The FSF's attitude from the outset is that users should have the rights (and legal means) to control their own fate. I don't know how anyone can argue against that without also arguing against their own freedoms -- after all, if you can chose to strip that right from someone else, someone else can do that to you too.
On the other side of the coin, the FSF's ideological opponents are even more dogmatic and inflexible, but also have the resources to buy politicians and therefore laws at the national and international level. That sort of fascist collusion is the true threat to freedom, as it seeks to eliminate the very existence of any sort of open platform and in the process, eliminate the freedoms such an open platform would effectively guarantee.
Personally, I am glad *someone* is pushing back against the interests that seek to take away my freedom to practice my trade.
> (I am willing to bet that even you don't type this from gNewSense or Hurd).
No, but I am typing this via a system that has no non-Free software installed -- although on-disk there is firmware/microcode intended to be loaded into hardware. For that reason I see gNewSense as rather silly; I see no moral difference between a blob stored on a hard disk vs the same blob stored on an EEPROM. Neither is Free.
As for the Hurd, its many failures are technical in nature, rather than ideological.
Posted Sep 7, 2015 2:02 UTC (Mon)
by RCL (guest, #63264)
[Link] (5 responses)
Games are the bulk of software market - have always been and still are. What other software is sold to end customers in bestbuys of the world? Pretty much every other need is covered by "software as a service" approach.
> So.. you're saying that any organization focused on achieving some ideological goal is essentially the same, even if their goals (software freedom vs total domination of all facets of life) and methods (peaceful advocacy vs slaughter) are radically different?
Maybe comparing them to NRA would be better, but I indeed lump ideological fanatics together. They *do* try to impose their world view - just read any essay by them and you'll instantly get the impression that licensing software in any other way than copyleft is somehow unethical, and that commercial vendors are evil.
> The common thread of all of those things are that they are only made possible when users' rights are restricted -- The FSF's attitude from the outset is that users should have the rights (and legal means) to control their own fate. I don't know how anyone can argue against that without also arguing against their own freedoms -- after all, if you can chose to strip that right from someone else, someone else can do that to you too.
This rests on assumptions that
#1 is certainly not true in vast majority of cases today - specialized hardware made the situation asymmetric. Game consoles, mobile, embedded devices - all those appliances are not sold with the expectation that users will tamper with them. This can be outright dangerous when the software in question is controlling your car.
#2 is even worse - copyleft licenses make free software essentially free as beer as well. As Linux Hater (the blog) once bluntly put it, you need to be "someone's bitch" in order to ship free software - and unfortunately, this is spot on. Copyleft licenses did not allow commercial vendors to base successful products on top of the free software (unless they hold the complete copyright and can dual-license the whole project); very few exceptions (Android, Red Hat, Code Sourcery) function against the spirit of GPL, jumping through hoops to avoid violating the letter.
> Personally, I am glad *someone* is pushing back against the interests that seek to take away my freedom to practice my trade.
If you are practicing your trade, this perhaps means that you are employed by a commercial company or run one. Even Linux the kernel these days is being worked on primarily by commercial entities, enthusiasts that have sufficient free time constitute a minority (and perhaps could have made a better use of their free time).
In that case, GPL is of no use for you; you cannot sell GPL'd product, nor can you incorporate GPL'd code in your product. What is the freedom we're talking about then? Freedom to do something at home in your free time? BSD takes care of that - and unlike GPL, the end result of your work can be used by you.
Although if you work in the area that truly interests you, you don't have any free time for moonlighting - hence first and foremost you should be thinking about your freedoms as a professional, not as a dabbling enthusiast.
Posted Sep 7, 2015 14:21 UTC (Mon)
by pizza (subscriber, #46)
[Link] (4 responses)
I'll repeat myself yet again -- the FSF takes pains to state that folks are free to chose whatever license they want for their own software. They strongly believe that many of those choices are unethical, do their best to present a compelling case, and put their money where their mouth is by writing a considerable body of software via methods they consider ethical.
Ignoring the false equivalacies with the NRA, you're still claiming that advocating for something somehow forces or imposes it upon you. By that same token, what you are I are writing here is also fanatical imposition or coercion.
> Games are the bulk of software market - have always been and still are. What other software is sold to end customers in bestbuys of the world? Pretty much every other need is covered by "software as a service" approach.
Ah, I am beginning to see the underlying flaw in your assumptions -- The bulk of software market consists of stuff that is not sold to the general public. Most programmers are employed writing or customizing software for internal, non-public use (eg business middleware, stuff to power web services, internal IT stuff, and the like). Only a small fraction is ever sold at retail, and even that is shrinking -- The modern approach (as practiced by web services and smartphone platfoms) tend to give the software away and rely on advertising or the truly awful euphamism that is called in-app-purchases. (I have nothing against IAP in principle, but in practice it consists primarily of practices that would make casinos and tobacco companies blush with embarassment. or envy.)
But I digress. Retail, sold-to-consumer software is a small portion of the overall software market. If that's what you want to target your efforts, it is of course your choice, but understand that there are other options that have different dynamics and implications, and that your principals/values/ethics/whatever are not universal.
> If you are practicing your trade, this perhaps means that you are employed by a commercial company or run one. Even Linux the kernel these days is being worked on primarily by commercial entities, enthusiasts that have sufficient free time constitute a minority (and perhaps could have made a better use of their free time).
I can't disagree with any of that, though none of us really have the right to judge how other people spend their free time.
> In that case, GPL is of no use for you; you cannot sell GPL'd product, nor can you incorporate GPL'd code in your product. What is the freedom we're talking about then? Freedom to do something at home in your free time? BSD takes care of that - and unlike GPL, the end result of your work can be used by you.
LOLwut? You just said that "Linux the kernel" is mostly commercial, yet every single one of those contributing vendors incorporates GPL code into their products, which they presumably sell for a profitable amount of money. On the same token, all of my former employers have sold products incorporating GPL code -- and have had no difficulty complying with the license terms while making a buck or three.
Also, where do you think said BSD code comes from? The same arguments you are making against writing/releasing copyleft stuff applies even more so to writing/releasing any source code at all, preculding the very existence of BSD-licensed source code.
As for personal moonlighting -- these days it consists mostly of hacking on Gutenprint -- Fully GPL'd code. It started (not unlike the FSF) because I wanted to be able to directly use a specific printer with Linux. I'll spare you the history, but suffice it to say that original printer now works *better* than with the manufacturer's official Windows/OSX drivers, and this GPL printer driver work led to various commercial concerns paying me to further improve things.
They don't do it out of altruism; they do it because this approach leads to a greater ROI than their alternatives. In the process, they benefit, I benefit, and everyone else benefits in the form of a greater, more useful, body of software.
> Although if you work in the area that truly interests you, you don't have any free time for moonlighting - hence first and foremost you should be thinking about your freedoms as a professional, not as a dabbling enthusiast.
You fail to see that those freedoms are equivalent -- they enable enthusiasts to become amateurs, and enable amateurs to become professionals. My own career is demonstration that this is not a theoretical benefit -- My involvement in copyleft software has directly led to all but one of my day jobs.
Posted Sep 13, 2015 17:46 UTC (Sun)
by RCL (guest, #63264)
[Link] (3 responses)
No; I am saying that FSF is advocating for destroying our trade, and that destructive angle puts them on the same shelf as NRA, Taliban and such. They sincerely believe that somehow limiting the contractual freedom that exists between software vendor and software user, the freedom that allows you to license software in a way that provides a sustainable monetary feedback and prevents your users from re-releasing it with little to no effort, will somehow make the software more "free".
Gladly, FSF were largely unsuccessful in their crusade against "proprietary" software.
> Ah, I am beginning to see the underlying flaw in your assumptions -- The bulk of software market consists of stuff that is not sold to the general public. Most programmers are employed writing or customizing software for internal, non-public use (eg business middleware, stuff to power web services, internal IT stuff, and the like).
I frankly question that - even if you argue that the most software is not sold in retail, it is still being licensed to its customers in a way that provides a monetary reward for making the software itself available, and not just services around it. E.g. when you license a business-to-business software you will have a per-seat and/or per-user pricing (sometimes per-CPU or per-core).
That changes nothing for the purposes of our discussion since GPL would not allow such an arrangement. GPL makes it impossible for you to get money (in a sustainable way, excluding donations and sponsorship) for writing the software itself, so it is destructive to our core trade.
> LOLwut? You just said that "Linux the kernel" is mostly commercial, yet every single one of those contributing vendors incorporates GPL code into their products, which they presumably sell for a profitable amount of money. On the same token, all of my former employers have sold products incorporating GPL code -- and have had no difficulty complying with the license terms while making a buck or three.
Commercial developers around the kernel do not "sell" the kernel at large, they sell services built around the OS. A few that do sell the OS themselves (Red Hat, Google, firmware vendors), jump through hoops to satisfy GPL and would be happier if the kernel was BSD-licensed.
> Also, where do you think said BSD code comes from? The same arguments you are making against writing/releasing copyleft stuff applies even more so to writing/releasing any source code at all, preculding the very existence of BSD-licensed source code.
No. There is still value in making your code open to others for reviews and improvements. Companies do open up their code base for this reason; however, BSD and custom licenses allow you to regulate how much of the code base you prefer to be developed in-house and how much you want to make open.
> They don't do it out of altruism; they do it because this approach leads to a greater ROI than their alternatives. In the process, they benefit, I benefit, and everyone else benefits in the form of a greater, more useful, body of software.
Exactly, but they would be better off opening it on BSD terms, because that way they can still sell the final product.
> You fail to see that those freedoms are equivalent -- they enable enthusiasts to become amateurs, and enable amateurs to become professionals. My own career is demonstration that this is not a theoretical benefit -- My involvement in copyleft software has directly led to all but one of my day jobs.
You sound as if GPL were the only means to achieve it. Before and after GPL companies made their code available to hobbyists for many reasons, including evangelism of their technology. If GPL were to die today, nothing would change in that regard - you would still be able to hack on OS kernels (Darwin), improve compilers or mod your favorite games. Copyleft is not an enabler of that; vice versa, it makes your intellectual property vulnerable to someone who will simply repackage your effort.
Posted Sep 13, 2015 18:28 UTC (Sun)
by corbet (editor, #1)
[Link]
Posted Sep 13, 2015 18:50 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
> Exactly, but they would be better off opening it on BSD terms, because that way they can still sell the final product.
So.. you're saying that my customers can't sell *what they're already selling* because it incorporates software that is not BSD based? Or are you saying that I can't sell the software *that I'm already selling* because it's not BSD-based?
As I said at the outset, you're entitled to your own opinions, but you're not entitled to your own facts. Good day.
Posted Sep 20, 2015 16:49 UTC (Sun)
by RCL (guest, #63264)
[Link]
I am saying that with licenses other than GPL, you could find ways to be better protected from someone repackaging and selling your software while adding little or no value to it at all.
I guess selling GPL software can work for certain markets where software itself is not the key component of the solution, but I fail to see how complicated software that requires extensive R&D (like https://www.youtube.com/watch?v=3ugVuyCXjss) could be developed under that model in a sustainable way.
But I agree it's time to end this discussion. Have a nice day.
Posted Aug 31, 2015 3:25 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Aug 31, 2015 3:42 UTC (Mon)
by pizza (subscriber, #46)
[Link]
I understand why they did that -- allowing *any* modifications renders their entire DRM scheme useless. The mobile/console owners' goal was to create a completely locked-down platform, which happens to be entirely at odds with the (L)GPL's goals of user empowerment.
Posted Aug 27, 2015 7:54 UTC (Thu)
by tz (guest, #104220)
[Link] (30 responses)
> I am a software engineer from Wind River (subsidiary of Intel), we ported GRsecurity patch (GRSecurity 2.9.1 -- 201207080925) into Wind River Linux as our security solution's critical part
> Vital Security Capabilities on Top of Open Source Innovation
So if it's indeed true that the Grsecurity project has not seen a single dime from them - and I'm sure it is - then I fully understand why they chose to discontinue public access to the stable branches, as sad as it is for people who used them and cannot afford to become a sponsor (200$/month is certainly affordable for any company in this business).
I don't understand why they don't just become a sponsor. They could afford it. Hell, they could afford to just hire Spender full-time. Instead, they went this way, risking bad publicity and making sure that they're never going to receive any support from the project. They're going to need support sooner or later.
Posted Aug 27, 2015 8:41 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (29 responses)
Why? When you use GPL that's part of the deal. You know your code can be used (poorly) by crappy companies. Do you remember the Linus quote about sharks with laser on their heads? As long as WindRiver respect the license, they can include the patch in all their products if they want.
Posted Aug 27, 2015 8:49 UTC (Thu)
by tz (guest, #104220)
[Link] (19 responses)
Posted Aug 27, 2015 10:18 UTC (Thu)
by moltonel (subscriber, #45207)
[Link] (18 responses)
But I really don't see how this is going to help. WindRiver and their ilk will switch to the unstable patches instead, and keep infringing the trademark. Not only have you not solved the trademark issue, now there's going to be "grsecurity" products out there of using unstable code, which might decrease grsec's reputation of quality.
I wonder if setting up a strong trademark document (à la Mozilla) would be a better idea. Word it in such a way that makes any trademark violation crystal-clear so that lawsuits don't cost as much as they do now.
Posted Aug 27, 2015 11:20 UTC (Thu)
by abelloni (subscriber, #89904)
[Link] (17 responses)
Posted Aug 27, 2015 13:53 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (16 responses)
[There are general rules on when you can use a trademark without permission but those rules do not cover a company that says they are using something covered by the trademark to better their own product. In that case, one must get permission and must follow whatever rules are laid out by the legal agreement. ]
Posted Aug 27, 2015 16:26 UTC (Thu)
by fandingo (guest, #67019)
[Link] (15 responses)
This couldn't be any less true. Permission has nothing to do with it. It's all about whether a customer would confuse the alleged infringing product or service with the genuine one. There are many situations where people can use competitor trademarks against the wishes of the mark holder.
Whether taking an genuine copy of the code, and making changes necessary to port it, substantively qualifies as different than the genuine, original product is an open question. I don't think it's clear-cut infringement since WR is using grsecurity -- it's just an old version with some necessary compatibility changes. Under trademark law, I'm not sure that WR's grsec is different enough from genuine grsec. It's older but overwhelmingly the same code.
In the end, it's illustrative that grsec is changing software distribution instead of fighting their case in court. If their legal footing was solid, they'd pursue that avenue instead of cutting off their nose to spite their face.
Posted Aug 27, 2015 16:51 UTC (Thu)
by smoogen (subscriber, #97)
[Link]
Posted Aug 27, 2015 16:54 UTC (Thu)
by drag (guest, #31333)
[Link] (13 responses)
The argument that unnamed 'Big Corp' is using is that they are using patches unmodified from Grsecurity and thus does not infringe on their trademark since they are using their product as intended; which is the set of patches.
Grsecurity believes that they are modifying the grsecurity source code, but more importantly they are doing other things to their kernel which may affect the functioning of grsecurity. This could lead to compromising the security of their kernel, which means that when there is some widely publicized hack of said 'Big Corp's product then consumers will think that grsecurity had some responsibility in this.
Grsecurity lacks the necessary resources to pursue this matter in court in a satisfactory manner. It's all fine and dandy to take a theoretical or technical stance on law, but if you don't have the money to actually survive in court then you effectively have no rights.
So what Grsecurity will do is withdraw their 'stable' branch of patch sets from public distribution and instead provide them only to their sponsors. This does not eliminate the ability of 'Big Corp' to get access to those patches. 'Big Corp' will still be able to extract patches from sponsor's products or from grsecurity's own source code (since grsecurity will still need to distribute based on the GPL). Or they can do a work around and use a subsidiary corporation to obtain the patch sets under false (but legal) pretenses.
What this does do is eliminate the excuse that Big Corp is free to use grsecurity trademark's for advertising their products because they will no longer be using the patch sets as intended. This will hopefully strengthen their case and reduce the expense of going after 'Big Corp' for trademark violations.
Posted Aug 27, 2015 17:25 UTC (Thu)
by fandingo (guest, #67019)
[Link] (12 responses)
I never said that grsec was outright wrong. I said that it wasn't clear-cut, and their clear displeasure at "unnecessarily dragged out over several months" probably doesn't understand the legal complexities at work. For one of the companies, the time window was "May 2015" until presumably sometime around today. When talking about potential lawsuits against major companies, that's a completely reasonable amount of time. I'm not sure what they're expecting out of a civil suit, including discovery, because those are more like 1-2 years.
> Grsecurity lacks the necessary resources to pursue this matter in court in a satisfactory manner. It's all fine and dandy to take a theoretical or technical stance on law, but if you don't have the money to actually survive in court then you effectively have no rights.
This is such BS. Yes, it's a very expensive process, but it's not at all insurmountable. It's far more likely that grsec didn't actually suffer *any* quantifiable harm (speaking strictly about trademarks and ignoring statutory penalties for the alleged copyright infringement). If they didn't suffer harm, they don't have a claim for anything beyond fees and an injunction.
> What this does do is eliminate the excuse that Big Corp is free to use grsecurity trademark's for advertising their products because they will no longer be using the patch sets as intended.
Once again, this is not a limitation that the trademark holder can legally impose. One can very well use a trademark in contravention of the owner's will, so long as there is no unreasonable confusion in the market. Since the grsec in WRL is, what, 99.8% grsec, I'm having trouble understanding the problem calling it grsec.
Posted Aug 27, 2015 17:47 UTC (Thu)
by drag (guest, #31333)
[Link] (11 responses)
If I have a automobile company and I start advertising that my automobile's motor is 'The Ford Mustang' because I am using some metal from old mustangs that I melted down and used as block components... I expect that Ford would have all the cause in the world to go after me for trademark violations.
I don't see how 'Big Corp' advertising that their product uses grsecurity kernel, while in fact they are using something completely hacked up which compromises all the benefits of using a grsecurity kernel, would lead to anything but confusion for public at large.
Posted Aug 27, 2015 18:12 UTC (Thu)
by fandingo (guest, #67019)
[Link] (10 responses)
Your analogy isn't even remotely similar to what's happening. We're talking somewhere around 95%+ identical.
> I don't see how 'Big Corp' advertising that their product uses grsecurity kernel, while in fact they are using something completely hacked up which compromises all the benefits of using a grsecurity kernel, would lead to anything but confusion for public at large.
Umm, has grsec publicly stated what the infringing code does? The blog post only talks about modifications to an old version of grsec to run on a kernel that grsec didn't previously and also about some EFI compatibility issues from a forum post. I don't see any allegations that changes were made "which comprises all the benefits." The allegations are:
* they didn't pay grsec developers to actively support and maintain what these companies seem to be happy to do themselves.
All I'm saying is that the trademark claims aren't strong. Even if they were to prevail, the claims aren't actionable much beyond attorneys fees and an injunction (against calling it grsec, not using grsec or saying "based on grsec"). That seems borne out by the trepidation grsec's counsel seems to have in pushing the matter beyond a C&D.
Posted Aug 27, 2015 18:15 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (9 responses)
So, not identical. Different.
And where do you get the 95% from?
Posted Aug 27, 2015 18:24 UTC (Thu)
by fandingo (guest, #67019)
[Link] (8 responses)
95% was an estimate based upon the allegations made, which solely consisted of kernel compatibility patches and possibly some EFI fixes. There's no allegations of adding features or otherwise modifying the code outside compatibility issues. (Perhaps this is simply due to where they are in the legal process: before discovery.) It could be 91% of 82% or anything. It's an arbitrary number.
Posted Aug 28, 2015 4:54 UTC (Fri)
by artem (subscriber, #51262)
[Link] (6 responses)
Posted Aug 28, 2015 6:33 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (3 responses)
It's a bit like saying that you could make a small change to a car and it wouldn't drive. While true, that neglects the fact that there are lots of ways to modify cars that have no effect on the driving performance.
I don't think software is particularly special here.
Posted Aug 29, 2015 7:00 UTC (Sat)
by artem (subscriber, #51262)
[Link] (2 responses)
I don't think car analogy is particularly good. Android analogy is much better - it's software, it's open source, and it's a trademark.
If what you claim is true, it should be perfectly OK for phone vendor to make small changes to it, compile it for their phone and sell it as 'Android phone', using Google trademark without going through Google-recommended Android Compatibility program. Is any phone vendor actually doing that? Admittedly you won't find definite answer in the open, but existence of android-like devices which carefully avoid using name 'Android' gives you some indication.
From legal point of view, the situation seems identical. Why is Google able to defend their trademark, and Grsecurity team is not?
Posted Aug 29, 2015 9:30 UTC (Sat)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Sure, I don't disagree. I was just refuting the idea that just because changing a single bit can break a program doesn't mean that only bit-for-bit identical copies would comply with a trademark. It's a lot fuzzier than that.
> From legal point of view, the situation seems identical. Why is Google able to defend their trademark, and Grsecurity team is not?
IANAL, but from here it looks like that Google (and the other example Firefox) have published trademark policies indicating what they consider acceptable and what not, which makes it easier to enforce. ISTM that what happened here is that it's not clear that the trademark was violated, and the uncertainty costs money/time/effort. Without a written policy you have to argue from general principles, and that's always harder.
Posted Aug 29, 2015 9:58 UTC (Sat)
by artem (subscriber, #51262)
[Link]
I had a look at trademark policy published by Google. It has 'submit your request to us' form right there. What's published is superficial - you won't know if Google will allow you to call your device 'Android' until you actually negotiated and signed an agreement with Google.
So it looks like the potential threat of sued by Google is a good deterrent, while the same about Grsecurity is not.
Posted Sep 5, 2015 9:44 UTC (Sat)
by abelloni (subscriber, #89904)
[Link] (1 responses)
Posted Sep 5, 2015 19:42 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link]
Posted Aug 28, 2015 11:56 UTC (Fri)
by ewan (guest, #5533)
[Link]
It is however, widely accepted, and is the foundation of various trademark policies including the Firefox one. If people could tweak Firefox 'a bit' and still use the name, there'd be no need for Iceweasel. Now, you can argue that there actually isn't any need for Iceweasel, but if you are, then it's safe to say that your view is not universally agreed.
Posted Aug 27, 2015 18:48 UTC (Thu)
by jra (subscriber, #55261)
[Link] (8 responses)
If only this were true. Most GPL violations go unreported and unenforced. Especially of the Linux kernel. Just as an example, take a look here:
https://emotiva.com/products/pres-and-pros/xmc-1
Wonderful product, I have 2 myself (and they really are good). Now look here:
https://emotiva.com/resources/XMC_user_v30_manual.pdf
Search for Linux and you'll find:
"The XMC-1 is controlled by a custom Linux-based operating system."
No source or offer of course. This is endemic in the embedded software community. I'm not even sure the company that ships this even understands it's a license violation (they're an audio company, not a software company).
There is *NO* funding for enforcement, and only SFConservancy as far as I know doing any actual enforcement.
If this doesn't get fixed, Linux GPL becomes worthless - it becomes equivalent to BSD. Personally I think there are many companies who would like to see this become the case.
Posted Aug 29, 2015 15:46 UTC (Sat)
by RCL (guest, #63264)
[Link] (7 responses)
With GPL, this is never going to happen. You cannot sell GPL'd products without violating at least the spirit of GPL (like Red Hat does, by cancelling support contract if a customer redistributes the source), and GPL doesn't seem to protect you from copycats in a practical sense anyway (as grsecurity story shows, and Red Hat vs. Oracle situation does too).
So if you are participating in a GPL'd project, you
1) restrict your own options by not being able to establish a monetary feedback - this activity is doomed to remain your hobby rewarded by what is essentially "tips" (donations you'll be begging for).
2) have, in practice, similar protection from someone taking your code and not contributing back.
3) complicate cooperation with commercial entities who cannot easily contribute to your project even when they are willing to.
This, in part, is why gcc is dying and clang is on the rise. Here's hope this becomes a trend.
Posted Aug 29, 2015 17:48 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
Bzzt, wrong. They cancel support contracts if a customer redistributes the *binaries*. You're free to redistribute the source package, and compile the source package and distribute the results. Hence CentOS, Scientific Linux, and so forth.
As for "violating the spirit of the GPL".. to put it politely, you're full of it. I get that you dislike the GPL, you're entitled to your opinion. But you're not entitled to your own facts. I respectfully suggest you read the FSF's FAQ on the GPL: http://www.gnu.org/licenses/gpl-faq.en.html.
Posted Aug 30, 2015 21:59 UTC (Sun)
by RCL (guest, #63264)
[Link]
Even worse...
> But you're not entitled to your own facts. I respectfully suggest you read the FSF's FAQ on the GPL
So what exactly was I wrong about? Revoking support for redistributing binaries violates GPL spirit no less than sources. Or was I wrong about the fact that you cannot sell GPL'd software and not be afraid of your customers re-selling it?
The fundamental problem with GPL is that it was conceived in times when everyone was a developer. In modern world, <1% are professional developers. GPL does not allow to properly reward original developers for their effort, putting them on equal footing with someone who simply repackages their work. That is why Notch is a billionaire while Linus is not.
Posted Sep 6, 2015 9:53 UTC (Sun)
by jospoortvliet (guest, #33164)
[Link] (4 responses)
The GPL and the concepts behind it have been instrumental in and crucial part of a cultural and economic shift, not just in the IT industry but far and wide. And I'm not just talking about the Creative Commons and Wikipedia but also the realization in academia and now business that this 'open innovation' thing is incredibly powerful. Businesses of course always look for was to benefit from this while staying in control - the real 'open' part is scary. That's why we had many controlled, small 'internet' competitors in the 90's and today so many little walled gardens where 'crowd sourcing' takes place.
But individuals have little incentive to contribute to a walled garden. Ownership is a powerful motivation and you just don't have that there. This goes twice for companies, of course, unless there is no choice they will prefer an open platform where they have a fair chance.
I think the BSD is an inferior license from a business pov because it provides no incentive to contribute. More importantly, it doesn't provide the equal playing field the GPL gives which is so beneficial for innovation and creativity. It works in a few cases because some are willing to contribute, even though it is of no benefit to them - but there is a reason why it is Linux which became a huge and successful project, and not any of the BSD's.
Posted Sep 7, 2015 1:03 UTC (Mon)
by RCL (guest, #63264)
[Link] (3 responses)
As far as I understand the issue, it is somewhat orthogonal to both licenses and is more about trademark usage.
> It works in a few cases because some are willing to contribute, even though it is of no benefit to them - but there is a reason why it is Linux which became a huge and successful project, and not any of the BSD's.
The bulk of software in use was not created by enthusiasts in their free time though, but by paid developers (this includes Linux); thus the question is more - which license allows better cooperation between the said enthusiasts and commercial entities. Linux is pretty much the only "big name" where GPL is still being used for such cooperation; gcc used to be the case too but commercial vendors all but quit it in favor of clang.
Of course, I am mostly talking about software that is supposed to be distributed to the end user - something that runs in the cloud is less affected by copyleft licenses, unless an exotic one like Affero GPL is being used.
Posted Sep 7, 2015 1:29 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
I've seen clang replace many home-grown proprietary compilers.. with other proprietary compilers that happen to be built on top of clang.
From an end-user perspective, it amounts to the same thing, though the latter tends to be higher quality.
(One of my work systems has *three* different forks/versions of clang installed as part of proprietary eclipse plugins. Plus another fork/version of clang internal to nvidia's graphics driver. Plus the built-from-source one that came with the Linux distro that can't replace any of the other four because none of the mods were contributed upstream)
Posted Sep 7, 2015 2:16 UTC (Mon)
by RCL (guest, #63264)
[Link] (1 responses)
http://lists.freebsd.org/pipermail/freebsd-amd64/2011-Mar...
while it is not uncommon to see outdated GPL'd software (gcc) being used downstream (e.g. CodeSourcery).
It is unreasonable to expect everyone to regularly update their versions, GPL'd or BSD'd, or contribute their patches upstream. This is another point that makes GPL moot - do you really need a tarball with some 2.4.x kernel used by someone in their firmware, heavily hacked to match their custom hardware? What value does that bring?
Posted Sep 7, 2015 14:39 UTC (Mon)
by pizza (subscriber, #46)
[Link]
I agree that's unreasonable to expect everyone to regularly update things. I also agree that upstreaming may or may not make commercial sense based on the ROI (FWIW it usually does in the long run, but hardly any commercial enterprise concerns themselves with the long run any more...)
However, putting aside the legal requirement for full corresponding source to a shipped binary Linux kernel image, having a proper source tarball means that *someone else* can upstream or support things long after the manufacturer has lost interest. This includes not only new features, but fixing security vulnerabilities.
This kind of thing is the entire premise of DD-WRT, OpenWRT, Cyanogen, and countless other efforts that tend to result in a far superior product to what was orginally shipped, and is effectively impossible without the source code for the supposedly-open bits.
Your "makes the GPL moot" assertion is actually one of the strongest arguments of why the GPL's copyleft ideals are a pragmatic thing in practice.
Posted Aug 27, 2015 8:59 UTC (Thu)
by nzx (guest, #93155)
[Link] (11 responses)
Apart from that I fully support Grsecurity guys, but I think this embargo will mostly hurt ordinary users (myself included), which use Grsec on a few personal machines, and where "sponsor" price tag is too steep.
Posted Aug 27, 2015 11:28 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (3 responses)
Exactly. On the LinuxFR thread one of the user wrote : "I'm member of a student association and we use grsec on a server on which every student have a shell. We can't become a grsec sponsor and using the test patch series don't seem to be a good idea. What are the possible alternatives?".
Due to this distribution restricted to sponsors, grsec will lose a lot of users and there is an increased risk or marginalization.
Posted Aug 27, 2015 12:13 UTC (Thu)
by Lionel_Debroux (subscriber, #30014)
[Link] (2 responses)
Posted Aug 27, 2015 14:19 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link] (1 responses)
Posted Aug 28, 2015 4:36 UTC (Fri)
by thestinger (guest, #91827)
[Link]
Posted Aug 27, 2015 16:34 UTC (Thu)
by txwikinger (guest, #57821)
[Link] (3 responses)
Posted Aug 27, 2015 16:57 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Aug 27, 2015 17:03 UTC (Thu)
by ewan (guest, #5533)
[Link] (1 responses)
If I use section 3b of the GPL and give them a written offer for the source code, then it's true that the offer must be valid for third parties. However, if I choose 3a and just givn the people to whom I distribute binaries the source code at the same time, then there's no obligation on me to distribute either the binaries or the source code to anyone else at all.
Posted Aug 27, 2015 17:15 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Okay, that's not what rms and the FSF intended, but to be strictly legal, unfortunately you need to *force* them to accept the source at the same time as the binary :-(
Cheers,
Posted Aug 28, 2015 4:58 UTC (Fri)
by dakas (guest, #88146)
[Link] (2 responses)
Posted Aug 29, 2015 16:00 UTC (Sat)
by RCL (guest, #63264)
[Link] (1 responses)
I see this as an intrinsic property of that license, which is loaded with political agenda that you, in turn, have to force upon others. You cannot simply develop software and have agreements suited to fit your particular customer's needs; you have to make them a part of the "movement" and if they are unwilling to, do legal and technical trickery like discussed here. Sickening.
Posted Aug 29, 2015 17:53 UTC (Sat)
by pizza (subscriber, #46)
[Link]
Hmm, my customers don't seem to have any problem with using GPL-licensed software. Or paying me to improve it. They seem to think it meets their needs quite well.
So, please, stop claiming to authoritatively speak for everyone just because you can't freeload on someone else's work without even a modicum of compensation.
Posted Aug 27, 2015 8:59 UTC (Thu)
by tz (guest, #104220)
[Link] (4 responses)
Is there any possibility for individuals to become a sponsor? While companies can easily afford the >=200$/m to become a Grsecurity sponsor, individuals can't.
Posted Aug 27, 2015 10:02 UTC (Thu)
by moltonel (subscriber, #45207)
[Link] (1 responses)
Posted Aug 27, 2015 21:38 UTC (Thu)
by makomk (guest, #51493)
[Link]
Posted Aug 27, 2015 11:37 UTC (Thu)
by Lionel_Debroux (subscriber, #30014)
[Link]
I have some experience of both the maintenance cost reduction and the code quality improvement, through the TI-Nspire platform support code submission. The first iteration was https://lkml.org/lkml/2013/4/4/113 (my s-o-b is due to the writing of the cover text and fixing checkpatch warnings before submission, not to any significant code contribution). Arnd Bergmann encouraged the submission, then indicated how things should be done instead... and later iterations, in a better shape, were integrated over time.
Posted Aug 28, 2015 7:13 UTC (Fri)
by gdt (subscriber, #6284)
[Link]
Although the RPi kernel isn't mainline (yet), it is reasonably current. For the commonly used Raspbian Wheezy distribution the kernel version after apt-get update && apt-get upgrade is 4.1.6 (the latest -stable kernel).
Posted Aug 27, 2015 14:05 UTC (Thu)
by imitev (guest, #60045)
[Link]
As pointed in other posts I doubt withdrawing the stable release to the public will do any good since the infringing company seems to run a very old kernel + modified grsecurity, but that's spender/paxteam's call so they know better and get to decide.
I really appreciate those guys' work and I considered becoming a sponsor a few times but as a home user of grsecurity the 200$/m is too steep. I hope they will consider creating a more affordable subscription where you could get a stable "lite" patch where - for instance
To people pointing out that there's still the "test" version: while it may be perfectly fine (security wise) for soho users, the latest version of the kernel is way too bleeding edge for enterprise distro users like me.
BTW I'm also wondering how this plays out with companies who are providing grsecurity kernels in their products. If I understand the GPL correctly they are required to publish the source of their patched kernel; they can of course delay the release and publish a big archive - ala redhat - but there still would be a convoluted way for bad companies to obtain the patch, while only making it more difficult for regular users.
Posted Aug 27, 2015 15:14 UTC (Thu)
by karkhaz (subscriber, #99844)
[Link]
[1] https://www.archlinux.org/packages/community/x86_64/linux...
Posted Aug 27, 2015 16:59 UTC (Thu)
by fandingo (guest, #67019)
[Link] (1 responses)
I'm confused why they ever pursued a path that they admit has little chance of any resolution; perhaps they should find better counsel (or listen to what she's already saying) that takes more than the heated emotions of the clients into consideration. Honestly, the trademark claim is reasonably weak. Modifications for compatibility *may* not infringe trademarks, although of course, it very well could be infringing. The problem is proving any sort of harm and quantifying it. Anyways, the blog post makes it sound like they iron-clad arguments, but I don't think it's that clear on the trademark angle.
The GPL angle is stronger because copyright both provides greater, more tangible protections and is more clear-cut. The problem, though, is what is the purpose. I guess if you're the uppity rabble rouser type pursuing GPL violations just to punish and retaliate this is a fine course of action. However, from a getting useful code back to the project and public angle, it's useless. They complain several times about how the alleged copyright violations are over code that is very old, and the patches are presumed to be of unusable quality. What exactly is the goal of getting such code released or a judgment?
I wish they had worked with the SFLC rather than going it alone. It seems like issues pursued by the SFLC always come to a beneficial conclusion for both the copyright holders, community, and infringers. This "resolution" seems to be to the detriment of everyone. Actually, the infringers are mostly unaffected since they forked off of stable a long time ago.
So, what's the goal? Make more money? Good luck. The unintended consequences will overwhelm anything they can get from the unnamed companies.
Posted Sep 1, 2015 20:51 UTC (Tue)
by jra (subscriber, #55261)
[Link]
Please name one real person or organization that fits this description. The problem with GPL violations isn't that there are "uppity rabble rouser type(s)", it's that there is almost no enforcement done *AT ALL*.
Posted Aug 27, 2015 18:23 UTC (Thu)
by smckay (guest, #103253)
[Link] (8 responses)
Solution: give money to grsecurity to get their code.
I don't really see how the solution is intended to impact the problem, aside from "if we had done this ten years ago there wouldn't be a problem today!"
Posted Aug 28, 2015 12:15 UTC (Fri)
by ewan (guest, #5533)
[Link] (7 responses)
Posted Aug 28, 2015 17:53 UTC (Fri)
by dlang (guest, #313)
[Link] (6 responses)
There are a tremendous number of companies using a lot of GPL software and not doing this, so I have a hard time believing that the 'social norms' require it.
Posted Aug 30, 2015 1:32 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
As I read it, the problem is that if WindRiver gets caught up in some IoT security apocalypse, it having grsecurity on its label can harm grsecurity. Now, if it had been audited and specced by grsecurity itself as up-to-par, this would be valid. But if it is due to poor patching, it is undeserved. Since they will only do such audits and checks with a sponsorship, I think the use of the grsecurity name should be tied to sponsorship. Not unlike Mozilla's trademark allowances on Firefox.
Posted Aug 30, 2015 8:03 UTC (Sun)
by dlang (guest, #313)
[Link] (4 responses)
they seem to be saying, "here are our patches, but you can't use them unless we fully audit the result and approve of it", which is among the most extreme forms of trademark rules you can come up with.
It's bad enough when Mozilla implemented such rules for firefox, but at least Mozilla was providing a complete software package.
grsecurity is only providing patches to the kernel, and to take the attitude that they should have veto power on what other patches can be put in a kernel along with theirs and still use the name is extremely arrogant (at best)
Unfortunately, that sort of "we know everything, everyone else is an idiot" attitude doesn't surprise me from this group.
Posted Aug 30, 2015 8:20 UTC (Sun)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
They wrote the code, they're entirely permitted to choose to enforce whatever restrictions the license gives them permission to enforce. The GPL doesn't require that you give blanket permission for trademark use. If permission is only granted to use the trademark for unmodified code, and if a vendor modifies the code and then continues to use the trademark in a way that would be likely to cause confusion between the modified code and the original code, they're within their rights to attempt to enforce their trademark. There's nothing arrogant about that. What's arrogant is the assumption that you can continue using a name even after the original authors indicate that doing so is against their wishes.
Posted Aug 30, 2015 9:15 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
Posted Sep 11, 2015 11:20 UTC (Fri)
by oldtomas (guest, #72579)
[Link]
As far as I understand it -- no. They are just trying to control the use of their trademark (which I think is understandable).
Wind River can take the code and patch it all the way to Times Square and back (courtesy of the GPL), but they aren't allowed to say "lookee, grsecurity inside" (strictly speaking it isn't). That sounds pretty sane to me?
Posted Aug 30, 2015 14:07 UTC (Sun)
by spender (guest, #23067)
[Link]
-Brad
Posted Aug 29, 2015 21:06 UTC (Sat)
by chrisV (guest, #43417)
[Link]
The fact also that grsecurity are willing to forfeit their trademark (if trademarks are not protected they are lost) is also incredibly limp. People should not be in a commercial business if they are not prepared to take the steps to stop people walking all over them.
Posted Jun 1, 2016 16:14 UTC (Wed)
by nealmcb (guest, #20740)
[Link] (22 responses)
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...
Are any customers (or prospective customers) willing to confirm this and help us protect the underlying GPLv2 protection of the kernel, by sharing any written agreements from GRsecurity that may violate GPLv2 section 6 or 7, or re-distributing and if necessary suing?
Posted Jun 1, 2016 16:40 UTC (Wed)
by Felix (guest, #36445)
[Link] (18 responses)
How is that different from a RHEL contract - which is assumed to be GPL compliant?
Posted Jun 1, 2016 16:49 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (17 responses)
Red Hat provides srpms which includes the source of all patches. So GRsecurity policy appears to be different if the patches are never available to non-customers. SFC or FSF would need to be contacted if a GPL violation is suspected.
Posted Jun 1, 2016 18:48 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (16 responses)
And... its not clear to me that support customers can publicly share the signed srpms available via the customer portal without breaching the terms of the support contract. I think things changed in the rhel7 timeframe. You might want to double check how the support contract terms intersect with the signed srpm redistribution now. I think because they are "signed" srpms, they are treated the same way as the signed binaries in terms of support contract value add, with the same contract breach conditions if someone redistributes them publically.
I can't find rhel kernel srpms for example. I can certainly find CentOS kernel srpms, and I can rebuild unsigned srpms from the referenced git repository...but official, signed, red hat srpms for rhel7... are not publically available afaict...which corroborates the idea that support contract doesn't allow them to be redistributed. So at present the GRsecurity situation may be more similar than you have stated in the previous post.
-jef
Posted Jun 1, 2016 19:28 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (15 responses)
Posted Jun 1, 2016 20:12 UTC (Wed)
by jspaleta (subscriber, #50639)
[Link] (14 responses)
So it looks very similar to the RH/CentOS sources. Its not clear to me that you can reproduce exactly what RedHat ships from the CentOS sources. You can get all the patches RH commits to the source tree..yes... but what is in the CentOS sources could easily be a superset of what is actually QA'd and shipped in RH srpms.
Again this looks really similar.
-jef
Posted Jun 1, 2016 20:34 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Well, it is ABI and API compatible and afaik, there isn't real source changes aside from branding and minor configuration. So I am not really sure it is the same situation.
Posted Jun 1, 2016 20:37 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (5 responses)
Posted Jun 1, 2016 21:01 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted Jun 1, 2016 21:10 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (3 responses)
Posted Jun 1, 2016 21:27 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
Posted Jun 1, 2016 21:28 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Jun 1, 2016 22:22 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jun 1, 2016 20:42 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (6 responses)
Posted Jun 1, 2016 20:48 UTC (Wed)
by Felix (guest, #36445)
[Link] (2 responses)
Red Hat is still pretty helpful as they share some form of their source code publicly but that should matter with regards to the GPL.
I have my own gripes with grsecurity but I fail to where the GPL violation is with regards to the OP.
Posted Jun 1, 2016 21:32 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
This is slightly inaccurate in a way that tends to cause confusion. When you perform commercial distribution under GPLv2, you have two options:
1) Provide the source code alongside the binaries
In this case it's basically irrelevant because (as far as my understanding goes) they're providing the source code itself to customers, and so GPLv2 section 3 doesn't apply.
Posted Jun 2, 2016 8:22 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Jun 1, 2016 21:54 UTC (Wed)
by spender (guest, #23067)
[Link] (2 responses)
Please stop blindly repeating misinformation.
-Brad
Posted Jun 2, 2016 6:22 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link]
Posted Jun 2, 2016 9:50 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jun 1, 2016 22:01 UTC (Wed)
by spender (guest, #23067)
[Link] (1 responses)
etc etc. He was quite vocal last year and for whatever reasons seems to have cropped up again just recently with posts today on LKML and then on reddit, with the same delusions and completely incorrect ideas about the GPL.
-Brad
Posted Jun 2, 2016 20:53 UTC (Thu)
by flussence (guest, #85566)
[Link]
That's definitely him, the way those messages are crafted sticks out like a sore thumb.
Posted Jun 2, 2016 1:00 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
The GPL governs the conditions under which you're allowed to distribute the code, and the support contract governs the conditions under which grsecurity is prepared to provide you with support and updates for the code. The two are completely separate legal agreements that deal with different services, and there is no magic connection between the two.
This means that the support contract does not impinge on your rights under the GPL. The GPL gives you the right to take the grsecurity source code (which is provided under the GPL) and pass it on to whomever you wish as long as you do it within the confines of the GPL. But whether you like it or not, if the support contract contains language to that effect, it is absolutely grsecurity's privilege to cancel it if they catch you passing on their code. This is a support issue and has no bearing on the GPL; if your support contract is cancelled, you still get to use and distribute the code that you already have under the GPL, even though you forfeit the right to support and further updates. The GPL doesn't care.
In summary, however distasteful and contrary to the spirit of Linux software development it may seem to some, the grsecurity folks are under no obligation to give anyone anything for free. If you don't like their behaviour or the terms of their support contract, don't buy their stuff.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Make sense?
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
> Matter of time; they switched: https://www.phoronix.com/scan.php?page=news_item&px=M...
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
> I'm not sure why, but you seem to be under the impression that the FSF somehow forces people to bow to their ideals. At the end of the day, folks are free to do what they choose, and license their software under whatever terms they see fit.
> If you can't see the difference between that and forcing folks to submit to your will under penalty of dismemberment and death, then I am truly sorry for you.
1) the platform for that software is a general purpose platform where you can actually "control your fate"
2) the interests of the user trump the interests of the software vendor.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
> Ignoring the false equivalacies with the NRA, you're still claiming that advocating for something somehow forces or imposes it upon you. By that same token, what you are I are writing here is also fanatical imposition or coercion.
OK, so comparing the FSF to the Taliban might not constitute a proper, technical invocation of Godwin's Law, but it's getting pretty close. Maybe it's about time for this discussion to wind down?
Enough?
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
LGPL requires that the end-users be able to replace the LGPL-ed library with a modified version. This is not possible for consoles and other similar platforms. Xamarin made quite a bit of money this way selling proprietary licenses for otherwise LGPL-ed Mono.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
> [...]
> - Expanded grsecurity packages in the secure kernel
Grsecurity stable patches to be limited to sponsors
Of course it's another story in case of GPL violations.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
* They're using an unsupported version of grsec, which through an unmentioned mechanism, somehow isn't allowed to be called grsec.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
http://llvm.org/devmtg/2013-11/slides/Robinson-PS4Toolcha...
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
It means it's nearly impossible for a lot of users.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Bug in GPL 2
Wol
Grsecurity stable patches to be limited to sponsors
Excuse my ignorance, but isn't it possible for a sponsor to publish stable patches on their own? GPL clearly allows that (redistribution).
Yes. Which makes an interesting GPL monetization vector: security. You pay for getting the software from a trusted source. If the developer figured out you redistributed, your next version could contain properly GPLed easter eggs.
At some point of time, you have to pick between being in good standing with the developer or going through with redistribution.
There is only so much a license can achieve.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Mainlining as much platform support and drivers as possible (I'm aware that binary blobs and firmware get in the way) is the way to go, especially in the mid- and long-term, because it both reduces maintenance costs and helps making the code better.
Without the mainlining, either the Nspire platform support would be stuck at zero maintenance cost on an old, non-DT version in worse shape based on a non-LTS (or at least, no longer LTS, given that it's been over two years) kernel, or would have to be upgraded once in a while, at some developer cost.
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
- you don't get any support (the 200$/m includes personal support, audits of RBAC policies and kernel configurations, ...)
- the RBAC feature is removed.
Grsecurity stable patches to be limited to sponsors
[2] https://www.archlinux.org/packages/community/x86_64/linux...
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
Grsecurity stable patches to be limited to sponsors
GRsecurity violating GPLv2 themselves by prohibiting redistribution
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/20...
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
ref: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Client...
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRSecurity is threating to revoke access to paid (more featureful) version for people who would like to use license's (GPL) features to share paid patchset with others.
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
2) Provide the source code to anyone who asks, whether they got binaries or not
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
Only in the free software "community" would jerks complain about getting the latest security advances for free.
GRsecurity violating GPLv2 themselves by prohibiting redistribution
GRsecurity violating GPLv2 themselves by prohibiting redistribution
Only in the free software "community" would jerks complain about getting the latest security advances for free.
Boy oh boy, you haven't been paying attention to the amount of whining that comes from proprietary software's users much.
GRsecurity violating GPLv2 themselves by prohibiting redistribution
http://geekfeminism.wikia.com/wiki/MikeeUSA
http://geekfeminism.wikia.com/wiki/Debian_and_LinuxChix_h...
https://geekfeminism.org/2009/10/08/psa-mikeeusas-hate-sp...
https://soylentnews.org/article.pl?sid=15/09/07/040206
GRsecurity violating GPLv2 themselves by prohibiting redistribution
I have absolutely no reservations about putting aside my flame grilling to emphasise this.
GRsecurity violating GPLv2 themselves by prohibiting redistribution