![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59The Linux Foundation is an industry organisation dedicated to
As of last Friday, this is no longer true. The by-laws were amended to drop the clause that permitted individual members to elect any directors. Section 3.3(a) now says that no affiliate members may be involved in the election of directors, and section 5.3(d) still permits at-large directors but does not require them[2]. The old version of the bylaws are here - the only non-whitespace differences are in sections 3.3(a) and 5.3(d).
These changes all happened shortly after Karen Sandler announced that she planned to stand for the Linux Foundation board during a presentation last September. A short time later, the "Individual membership" program was quietly renamed to the "Individual supporter" program and the promised benefit of being allowed to stand for and participate in board elections was dropped (compare the old page to the new one). Karen is the executive director of the Software Freedom Conservancy, an organisation involved in the vitally important work of GPL enforcement. The Linux Foundation has historically been less than enthusiastic about GPL enforcement, and the SFC is funding a lawsuit against one of the Foundation's members for violating the terms of the GPL. The timing may be coincidental, but it certainly looks like the Linux Foundation was willing to throw out any semblance of community representation just to ensure that there was no risk of someone in favour of GPL enforcement ending up on their board.
Much of the code in Linux is written by employees paid to do this work, but significant parts of both Linux and the huge range of software that it depends on are written by community members who now have no representation in the Linux Foundation. Ignoring them makes it look like the Linux Foundation is interested only in
[1] Article II of the bylaws
[2] Other than in the case of the TAB representative, an individual chosen by a board elected via in-person voting at a conference
promoting, protecting and standardising Linux and open source software[1]. The majority of its board is chosen by the member companies - 10 by platinum members (platinum membership costs $500,000 a year), 3 by gold members (gold membership costs $100,000 a year) and 1 by silver members (silver membership costs between $5,000 and $20,000 a year, depending on company size). Up until recently individual members ($99 a year) could also elect two board members, allowing for community perspectives to be represented at the board level.
As of last Friday, this is no longer true. The by-laws were amended to drop the clause that permitted individual members to elect any directors. Section 3.3(a) now says that no affiliate members may be involved in the election of directors, and section 5.3(d) still permits at-large directors but does not require them[2]. The old version of the bylaws are here - the only non-whitespace differences are in sections 3.3(a) and 5.3(d).
These changes all happened shortly after Karen Sandler announced that she planned to stand for the Linux Foundation board during a presentation last September. A short time later, the "Individual membership" program was quietly renamed to the "Individual supporter" program and the promised benefit of being allowed to stand for and participate in board elections was dropped (compare the old page to the new one). Karen is the executive director of the Software Freedom Conservancy, an organisation involved in the vitally important work of GPL enforcement. The Linux Foundation has historically been less than enthusiastic about GPL enforcement, and the SFC is funding a lawsuit against one of the Foundation's members for violating the terms of the GPL. The timing may be coincidental, but it certainly looks like the Linux Foundation was willing to throw out any semblance of community representation just to ensure that there was no risk of someone in favour of GPL enforcement ending up on their board.
Much of the code in Linux is written by employees paid to do this work, but significant parts of both Linux and the huge range of software that it depends on are written by community members who now have no representation in the Linux Foundation. Ignoring them makes it look like the Linux Foundation is interested only in
promoting, protecting and standardising Linux and open source softwareif doing so benefits their corporate membership rather than the community as a whole. This isn't a positive step.
[1] Article II of the bylaws
[2] Other than in the case of the TAB representative, an individual chosen by a board elected via in-person voting at a conference
Re: Great catch.
Date: 2016-01-21 03:13 pm (UTC)Re: Great catch.
Date: 2016-01-22 11:01 am (UTC)If I hadn't stepped in, they probably would've continued down this path. The resulting "discussion" downplayed my logic and statements, to the point where some people claimed that they no longer wished to discuss this topic with yours truly... But the drop or increase of the limit was of course never mentioned again.
As for why i bring this up here: mjg59 happily joined the shitthrowing contest against radeonhd, which at that point was a political struggle between AMD+SuSE versus ATI+redhat. This never had anything to do with creating the best possible driver, writing the best possible and most maintainable code, and furthering the linux desktop as much as possible. The ATI+redhat side showed an extreme lack of scruples, and was caught doing several very nasty things.
This is why i am so critical of mjg59s current spell of allergic reactions against linux and the linux foundation. When he did not deem himself on the receiving side of such actions, he happily joined in and happily dished out as well. And this makes me wonder what agenda mjg59 is really pushing today.
This is not to say that i disagree with his stance on what the linuxfoundation just pulled, quite the opposite, I just wonder why he is so active here all of a sudden.
Luc Verhaegen.
Re: Great catch.
Date: 2016-01-22 11:11 am (UTC)Interesting view of history there. There was an open driver developed in the community (Avivo), followed much later by a driver developed in secret for several months (radeonhd) which simply showed up by surprise one day with the expectation that everyone else would immediately cease their efforts.
But I guess if you see the world through a prism of neverending corporate conspiracies and power struggles (ones which you've happily partaken in), it makes some kind of sense.
-daniels
Re: Great catch.
Date: 2016-01-22 12:55 pm (UTC)a) AMD did not allow us to talk about this until _they_ could make the big announcement. We at suse never got told when this was supposed to be. But Mr Bridgeman (former ATI), with whom you and your friends so happily worked together, was active in enforcing this silence. And he had to, once, very early on, where it turned out that AMD was the source of the leak.
b) you were the one who had decided to use the GPL whereas MIT was the common license, and we could not talk to any of you guys because of a)
c) The avivo driver was barely a reverse engineering effort. You just dumped some register values and then changed the numbers you could readily spot. Register tracing would've given you a whole lot more useful information, and would've told you how to program the PLLs and other things.
After initial analysis of the code in avivo, we realised that there was not much worth salvaging. We would've of course preferred to build on top of that driver, but you yourself and AMD made that impossible. And we ended up writing 15kloc in 6 weeks, with 2.5 people, and getting something real solid out in (what turned out to be) time, so that ATI could not say "we told you so AMD".
Avivo did play a great role in showing AMD that this was the way forward, and it should be remembered as that, but not more.
To add to all of that, the RadeonHD team did not:
* use avivo or radeon code and then remove copyrights.
* spread FUD and claim that the avivo or radeon driver were the product of the microsoft conspiracy
* copy over painstakingly acquired/reverse engineered fixes from avivo or radeon, silently, and then turn around and bash avivo or radeon for not working on $way_too_early_or_useless_feature_X_or_Y
* remarket proper C code as "legacy" and unchangeable firmware as "scripts"
* silently remove avivo and radeon drivers from the standard Xorg build scripts
* hack the avivo or radeon git repositories using freedesktop admin rights
How often do i need to repeat the above?
Luc Verhaegen.