Forgot your password?
typodupeerror
GNU is Not Unix Open Source Software News Your Rights Online IT

How Far Should GPL Enforcement Go? 432

Posted by timothy
from the lo-unto-the-ends-of-the-earth dept.
itwbennett writes "The debate over enforcement of the GPL flared up again this week when Red Hat kernel developer Matthew Garrett wrote in a blog post that Sony is looking to rewrite BusyBox to sidestep the GPL. Which is a perfectly legal undertaking. But it raises the question: 'Is there social pressure within the Linux kernel community to not undertake GPL compliance action?' writes blogger Brian Proffitt. 'This may not be nefarious: maybe people just would rather not bother with enforcing compliance. Better, they may argue, to just let the violation go and get on with developing better code.'"
This discussion has been archived. No new comments can be posted.

How Far Should GPL Enforcement Go?

Comments Filter:
  • Execution (Score:5, Funny)

    by busyqth (2566075) on Thursday February 02, 2012 @05:13PM (#38908665)
    By hanging
    • by qbast (1265706) on Thursday February 02, 2012 @05:19PM (#38908745)
      Trampling by herd of angry gnus. That's poetic justice.
    • corporate death penalty

    • is there any reason why Sony cant use the program while conforming to GPL? they can include it in their systems, do mention that it's GPL'ed, link to its source code, and put proper attribution. or are they too smug to mention they borrowed code from elsewhere?

      execution would be the fairest thing when dealing with such case... especially when we consider the company we're dealing with here, who'll be more than happy to sue anyone for the silliest of reasons

      • Re: (Score:3, Insightful)

        by AdrianKemp (1988748)

        It's a matter of the (L)GPL being a shitty license for corporate use. If they wish to use the code they are under restrictions that can mean big problems if they are even accidentally violated.

        Why *wouldn't* they put the time into rewriting it in house? It's pretty easy when you're essentially transcribing source code. then they can freely change it without sharing, without worrying about a lacky somewhere forgetting to host the code, etc. etc.

        The GPL is a great hobbyist license but it's a pain in the ass a

        • Re:Execution (Score:5, Insightful)

          by Nursie (632944) on Thursday February 02, 2012 @08:44PM (#38910889)

          It's a matter of the (L)GPL being a shitty license for corporate use. If they wish to use the code they are under restrictions that can mean big problems if they are even accidentally violated.

          This is pretty much pure FUD.

          If they "accidentally" violate a commercial license then they could be on the hook for millions of dollars. With the GPL the choice is generally to distribute the source or stop distributing. Hell, even with the recent "aggressive" enforcement, the only really onerous bit is paying $5k per time to have future FOSS projects vetted. Compared to settling a lawsuit with a commercial vendor, it's peanuts.

          Why *wouldn't* they put the time into rewriting it in house? It's pretty easy when you're essentially transcribing source code.

          If they're transcribing source code then they've absolutely within the bounds of derivative work and will fall foul of copyright law.

          The GPL is a great hobbyist license but it's a pain in the ass at the corporate level, especially when you aren't really a software firm.

          It's less onerous that many commercial licenses. The problem comes from the lax attitude towards it. If people further down your supply chain were including commercial code or libraries without the proper license compliance then things would be worse.

          • by s4m7 (519684)

            If they're transcribing source code then they've absolutely within the bounds of derivative work and will fall foul of copyright law.

            There's a well known method of avoidance of this issue. What you do is set up two teams. One team looks at the original source code and writes a detailed spec based on that code. The second team never sees a single line of code from the original project. They use the detailed spec to recreate the program "from scratch" but such as to perform exactly or nearly exactly the same as the original program.

            This method has two safeguards. For one, your "blind" team will most likely write code quite different

            • Re:Execution (Score:5, Interesting)

              by Nursie (632944) on Thursday February 02, 2012 @09:45PM (#38911235)

              Yes, I've heard of this sort of thing, seems a neat enough way to sidestep copyright.

              It's considerably more complex than just "transcribing code", I'm sure it's been done as much in the pursuit of FOSS as in the pursuit of closed source software.

              Out of interest, has this been tried in a court in recent years?
              Just wondering if the general IP hysteria has affected whether or not this procedure is legal.

    • A hung program doesn't execute properly.
  • by inode_buddha (576844) on Thursday February 02, 2012 @05:18PM (#38908721) Journal

    I think GPL enforcement sould go just as far as everyone else. It should go as far as copyright law allows and as far as the copyright lobby goes.

    • Without cheating, without being oppressive and without being a force for evil. Which is the case today, in everybody's opinion but a few shills with an agenda, usually in the form of a paycheck.

      Anyway, I encourage Sony to fork Busybox. They will likely be able to make some improvements, however over the long run their fork will likely degenerate to the same quality as their typical software efforts, which to be honest, I am not much impressed with. When they get tired of that work and expense, and their new

      • by turgid (580780)

        A fork is not a rewrite.

        If Sony want to have their cake and eat it, they are free to develop their own busybox-like suite of tools, on their own dime, and they can probably cannibalise some BSD code to get off to a flying start.

        It's been a long time since I had time to browse any of the code repositories out there, but last time I looked, the BSD people (Free, Net, Open, ...) all had their own BSD-licensed unixy command-line tools.

        Goodness, me, unless I'm mistaken, that stuff's been about for longer than GN

        • by Plunky (929104)

          It's been a long time since I had time to browse any of the code repositories out there, but last time I looked, the BSD people (Free, Net, Open, ...) all had their own BSD-licensed unixy command-line tools.

          Speaking as a NetBSD user (and developer) we do have something that looks similar to busybox under /rescue, a statically linked binary which acts differently depending on how you call it. See the "list" file at cvsweb [netbsd.org] for common utilities included and the build seems easy enough to configure your own uti

    • by TaoPhoenix (980487) <TaoPhoenix@yahoo.com> on Thursday February 02, 2012 @05:37PM (#38908977) Journal

      I second this.

      "Hi there. Nice GPL copyright-backed code you got there, that you're violating the license on. It would be a shame if you had to pay $375,000 per Copyrighted Work, aka each file in the 50,000 file package. The Choice Is Yours."

      Come on guys, if they're going to abuse copyright law, abuse it back, preferably with a big gun case that sets precedent. "No, you don't get to "withdraw your case. You get to pay me X BILLION dollars! Or - your choice - you can go fix it in Congress so that copyright damages are back down to $20 per work, like it should be."

    • by stephanruby (542433) on Thursday February 02, 2012 @06:05PM (#38909397)

      Except that even copyright law is being treated differently in different countries.

      In Germany for instance, a few court rulings set the precedent that in order for German developers to maintain their rights under copyright, they must actively defend those rights (so not surprisingly, German open source developers are doing just now right now and they're currently contacting/suing everybody who are using their code but not complying with their license).

      And in places like Tawain, Chinese manufacturers are not even paying lip service to open source (even if providing the sources to their modifications wouldn't be difficult at all). So they're not getting sued at all, unless they have offices in the US, because it's far easier to sue in the US than it is in Tawain.

  • by Anonymous Coward on Thursday February 02, 2012 @05:19PM (#38908725)

    Slashdot on piracy: "Abolish all copyrights! Copying isn't theft! Everyone is entitled to everything!"
    Slashdot on the GPL: "Gee whiz, the GPL copyright license protects this code. Down with leeching violators! Protect against GPL theft!"

    • by Jorl17 (1716772)
      The thing is that most copyright stuff involves getting money out of that project, while the GPL stuff might also involve money, just the other way around.
      • by Dahamma (304068) on Thursday February 02, 2012 @05:40PM (#38909055)

        Never understood why people thought getting money for your work was a bad idea...

    • by ad454 (325846) on Thursday February 02, 2012 @05:37PM (#38908981)

      There is a huge difference between copyright enforcement against individuals in the context of personal use, and organizations in the context of earning signifigant revenue.

      Most people including those on Slashdot, do not think it is reasonable to sell a pirated DVD movie on a street corner for profit, but consider it okay to download that same movie for media shifting for personal viewing.

      Sony should be applauded for making their own BusyBox alternative, rather than violate the GPL. Hopefully it will be released as opensource with a different licence, for those that want an alternative choice. Adding more choice is a good thing!

  • by PCM2 (4486) on Thursday February 02, 2012 @05:21PM (#38908761) Homepage

    I confess I only skimmed TFA -- this is Slashdot, after all.

    But I'm not sure I understand the argument that is being made here. If Sony is really trying to "rewrite Busybox" -- which makes it sound like they're going to look at the Busybox code and write a new version that does the same thing in a different way -- then surely that's a derivative work of Busybox and it's a copyright violation.

    If, on the other hand, Sony is planning to write a Busybox replacement from scratch -- what's wrong with that? Are companies not entitled to write code? How is that "violating licenses with impunity"?

    If Sony is planning to do a clean-room re-engineering of Busybox -- what's wrong with that? Isn't that essentially what Linux kernel developers have done for all kinds of devices? Again, how is that "violating licenses with impunity"?

    Sony wants to not use GPL-licensed code in its proprietary products. What could be more clear? Would you rather they used it without complying with the license?

    • by bonch (38532) *

      But I'm not sure I understand the argument that is being made here. If Sony is really trying to "rewrite Busybox" -- which makes it sound like they're going to look at the Busybox code and write a new version that does the same thing in a different way -- then surely that's a derivative work of Busybox and it's a copyright violation.

      Is that really considered a derivative work just because they can see the source? Genuinely curious here.

      • Is that really considered a derivative work just because they can see the source? Genuinely curious here.

        If the Linux community hires some big fancy lawyers and bring the case to court, a judge will provide an answer to your question.

      • by PCM2 (4486)

        Is that really considered a derivative work just because they can see the source? Genuinely curious here.

        It could be. As the poster below says, it kind of depends on who has the most lawyers. SCO argued that Linux violated SCO copyrights because its source code tarball contained similar-looking header files.

      • by Daniel Phillips (238627) on Thursday February 02, 2012 @05:41PM (#38909061)

        But I'm not sure I understand the argument that is being made here. If Sony is really trying to "rewrite Busybox" -- which makes it sound like they're going to look at the Busybox code and write a new version that does the same thing in a different way -- then surely that's a derivative work of Busybox and it's a copyright violation.

        Is that really considered a derivative work just because they can see the source? Genuinely curious here.

        It can be. That is why cloning a library under an incompatible license typically requires an expensive "clean room" engineering process. Of course, Sony holding to their well known high moral and ethical standards, would never think of playing fast and loose with this, would they? And of course we would never notice if they cut a few corners to save cost, would we?

      • It's a good question. I personally don't know. My limited understanding of copyright protection is it protect not function, but expression. So copying the function of something isn't derivative. To protect function you have to get patent on it. However, it depends how close the new programmers are to the original code. For instance, if you hand a detective novel to a writer and say make me a story very similar to this one, even if he changed the names, places and such, if the general plot is the same,
      • by tepples (727027) <tepples AT gmail DOT com> on Thursday February 02, 2012 @05:44PM (#38909111) Homepage Journal

        Is that really considered a derivative work just because they can see the source?

        Proving an allegation of copying requires proving two elements: first, that the alleged infringer had at one time had access to the older work; and second, that there is a level of similarity between the two. "Access" can be as simple as having heard a song on the radio a decade ago (Bright Tunes Music v. Harrisongs Music).

        Compaq decided to make lack of access clear when it reverse-engineered the IBM PC BIOS using a "clean room" technique. This involved having one team turn copyrighted code into descriptions of its (unprotected) functionality and a second team turn the descriptions into code, with all communications between the two teams carefully monitored. I've been told it might not be quite necessary to go that far, but in the business world, you'd often rather spend money on engineers than trial lawyers. In such a case, it's best to draw up a plan for "being able to tell IBM to go to hell, and having the federal judge draw them a map for exactly how to go there", as sigwinch put it a decade ago [slashdot.org]. (Here's such a map [mapq.st].)

      • "Is that really considered a derivative work just because they can see the source?"

        Surely it is, at least for this judge: http://news.slashdot.org/story/12/01/26/0237246/non-copied-photo-is-ruled-copyright-infringement [slashdot.org]

        The right question nowadays it "but should it be?"

      • by dougmc (70836)

        Is that really considered a derivative work just because they can see the source? Genuinely curious here.

        That would be an issue for the courts to work out. I imagine that if it went to court, that argument would certainly be made.

        And I expect that the authors of this Busybox clone would retort saying that they've never seen the source of Busybox (and it would be prudent for them to make sure they never have), and unless the Busybox folk could show that they had, that would be the end of it. (Unless there's a patent out there somewhere about making one executable that performs the function of lots of *nix too

    • by MBCook (132727)

      They don't have to look at BusyBox, it's just a collection of standard utilities. Since they know what the utilities are supposed to do, they can make their own versions without having to look at the BusyBox code.

      The real issue is what this look like. "We keep being accused of GPL infringement, and people are using this BusyBox thing as leverage, so if we replace it, they won't have leverage and can keep infringing without worry."

      Now it's entirely possible Sony isn't doing this to let them get away with o

      • by PCM2 (4486)

        The real issue is what this look like

        But... dude. Surely you see my point here. It's Sony.

    • by dougmc (70836) <dougmc+slashdot@frenzied.us> on Thursday February 02, 2012 @05:43PM (#38909091) Homepage

      If Sony is planning to do a clean-room re-engineering of Busybox -- what's wrong with that? Isn't that essentially what Linux kernel developers have done for all kinds of devices? Again, how is that "violating licenses with impunity"?

      I'm with you.

      If they really wanted to be fancy about it, they could do the same thing the BIOS cloners did -- have some people write up documentation on what Busybox does, and other people write the clone. But really, the first part is easy -- just decide which commands must be implemented and which flags, and let somebody write it. For bonus points, all people involved certify that they've never looked at the source of Busybox, or perhaps never explicitly used it at all.

      If they do this (and it sounds like it's their plan) ... I don't see where there's any room to enforce the GPL at all, not with regard to this Busybox clone anyways. All they could do is try to be even more picky about other packages, perhaps trying to step up enforcement of Busybox usage (not a clone, not yet) now.

      While I hate rooting for the bad guy, I think Sony has the right idea. (Though I'm sort of surprised that more embedded device makers haven't gone with one of the BSDs rather than Linux simply to avoid the GPL.)

    • by c (8461) <beauregardcp@gmail.com> on Thursday February 02, 2012 @05:45PM (#38909115)

      > Sony wants to not use GPL-licensed code in its proprietary products.

      Well, no. If you RTFA, it suggests Sony wants to use GPL-licensed code except for projects the license is actually enforced. They'll use the Linux kernel because the Linux kernel community doesn't bother with GPL enforcement. They don't want to use Busybox because the Busybox developers will sue them for license violations.

      Of course, it's a bit of a risky strategy. Just because someone hasn't enforced their copyrights so far doesn't mean they still can't or won't. You'd think their own lawyers would raise a stink about it...

      • by Gadget_Guy (627405) * on Thursday February 02, 2012 @06:20PM (#38909601)

        They'll use the Linux kernel because the Linux kernel community doesn't bother with GPL enforcement.

        The big difference is that their custom code that they would want to keep private would most likely be linked into Busybox and not the Linux kernel. This means that they might be quite happy to give out the source code to a mostly unmodified Linux (thus complying with GPL) while still keeping all their secrets by not having to disclose their modifications to busybox.

        Making claims that writing their own replacement for busybox means that they will violate the GPL in other ways is the same kind of FUD as when Sony says that jailbreaking a device means you are a pirate, or when Microsoft says that GPL is a cancer. It would be the same as if Microsoft tried to claim that people using Wine did so to pirate Windows software.

        The more childish response to anybody complaining about using GPL software in a commercial environment is "if you don't like it, write your own software". Well, that is exactly what Sony want to do. What amazes me is how long it took for anyone to do this. By making a non-GPL version, companies have a choice when creating new products. Now all they need is for someone to develop an alternative to Linux and release it under the BSD license. Now if only we could think of a name for such a project...

    • by jaminJay (1198469) on Thursday February 02, 2012 @05:45PM (#38909129) Homepage
      According to TFA's comments, the Busybox replacement under discussion is Toybox, written by a former maintainer of Busybox. It cannot be clean room, whether or not that matters.
      • According to TFA's comments, the Busybox replacement under discussion is Toybox, written by a former maintainer of Busybox. It cannot be clean room, whether or not that matters.

        If the SFC wants to go through the source code line-by-line to look for any similarities so they can claim ownership of the code, then they are quite welcome to do so.

        It is a strategy that worked well for SCO, and made them the darling of the software world that you see today!

    • the argument (Score:5, Informative)

      by chrb (1083577) on Thursday February 02, 2012 @05:52PM (#38909229)

      The argument that is being made in a nutshell:

      Busybox copyright is enforced by the SFLC, which sues companies to get them to comply. When negotiating for compliance, they also request that the company in question comply with the GPL2 license on the Linux kernel. Now, for whatever stupid reasons, some companies don't want to release their kernel modifications for Android devices. So they think that by removing Busybox, the SFLC will no longer have a copyright claim that opens them to litigation which results in their releasing their kernel source. This reasoning is flawed, because there is another, much easier way to avoid Busybox litigation: put the source code on your web site. That's all it takes. They could keep their kernel sources, and just put up the Busybox source, and they would achieve the same thing.

      The other argument being made by one developer is that enforcement action is pointless, because he hasn't seen any Busybox source opened up from this route that was worth anything. Others disagree, saying there was some useful code, and that it's not just about Busybox - the Busybox enforcement actions have also resulted in kernel drivers being opened up.

      So, the "outrage" here is the allegation that Busybox is being rewritten so that companies can violate the copyright of the Linux kernel without being sued by the SFLC.

    • by Chemisor (97276) on Thursday February 02, 2012 @05:53PM (#38909237)

      You can read the actual complaint in the second link. It is not about any copyright violations of busybox code. He's whining about the fact that with a non-GPL busybox replacement he won't have an excuse to sue for Linux kernel GPL violations. Kernel developers are generally not inclined to sue anybody for not releasing the source code to kernel modifications, while busybox developers sue everybody in sight. If busybox is replaced, it would be more likely that device manufacturers who do not release sources for kernel modifications would be able to get away with it.

    • I don't think there's anything illegal about the project, but it seems explicitly designed to thwart the efforts of the Software Freedom Conservancy. The SFC technically only has authority to enforce the GPL when it comes to BusyBox, but when they find a BusyBox violation, they use that to pressure companies to come into compliance with other GPL software, namely the Linux kernel. The project author thinks that's a bad thing, preferring to allow "naive or defunct" companies make "mistakes" with non-BusyBox

    • It might be that Toybox is derivative of Busybox. Parts of Toybox were written for Busybox, and presumably are derivative of other parts of Busybox. They were then removed from Busybox and put in Toybox, which does the same thing, just without other parts of Busybox.

      But the really nasty part of all of this is that Toybox's only purpose is to allow the GPL on the kernel to be infringed with impunity, because kernel developers currently aren't cooperating with SFC.

      Does anyone want to sell their copyright on

    • by GauteL (29207) on Thursday February 02, 2012 @06:24PM (#38909655)

      If Sony is really trying to "rewrite Busybox" -- which makes it sound like they're going to look at the Busybox code and write a new version that does the same thing in a different way -- then surely that's a derivative work of Busybox and it's a copyright violation.

      No. Being "inspired" by other code is not copyright violation. Clean room implementations are about making your intentions clear and removing doubt.

      Two programmers may well write similar code because they share similar views or education and copyright violations can be hard to decide upon in court. If you're writing a replacement for something else it becomes particularly important to remove doubt and avoid unnecessary litigation.

  • So basically... (Score:4, Insightful)

    by Millennium (2451) on Thursday February 02, 2012 @05:30PM (#38908871) Homepage

    It seems to me as though this is less about BusyBox per se, and more about enabling companies to steal code from other GPL'd projects without having to worry about the threat of the BusyBox folks calling them out on their wrongdoing.

    Forgive me if I can't think of any word other than "scum" at the moment.

  • You can spend months trying to rewrite busybox, or you can just put the source code on your web site. It's not that hard. In fact, Sony already do it. [sony.com] GPL Compliance: put the source on your web site. That's all it takes. It isn't expensive or difficult.
    • by WarJolt (990309)

      Depends on the GPL version though. the anti-tivoization clause of GPLv3 makes compliance more difficult. Some organizations ban GPLv3 all together.

      Busybox is GPLv2, which no one should complain about that.

    • Re: (Score:3, Informative)

      by bug1 (96678)

      "You can spend months trying to rewrite busybox"

      Output from sloccount for busybox suggests its more like 50 months.

      Busybox is highly optimized code, there has been a lot of rewriting to reduce space, without being an expert on how these estimates work, i suggest it underestimates the effort required to create.

      Total Physical Source Lines of Code = 192,634
      Development Effort Estimate, Person-Years (Person-Months) = 50.12 (601.42)
      Schedule Estimate, Years = 2.37 (28.45)
      Total Estimated Cost to Develop = $ 6,770,3

  • by eexaa (1252378)

    I always thought that LGPL was created for this kind of stuff. I guess that if sony contacted busybox authors in a nice manner and if it was all for some good thing (bash-scripted gadgets!), relicencing would be fast&easy option.

    • LGPL is a good fit for this (although it's really more for libraries). However, the busybox folks seem to be quite happy about being "that piece of software that nails everybody that tries to violate the GPL", so they may not be interested in relicensing.

  • by Animats (122034) on Thursday February 02, 2012 @05:39PM (#38909009) Homepage

    BusyBox is just some standard UNIX utilities in one executable. BSD has all the necessary code. The BSD license doesn't require source redistribution. Putting together a BusyBox replacement shouldn't be a big deal.

    • by jd (1658)

      Why rewrite it at all? Flash memory is sized in gigabytes and is unlikely to be the expensive part of any embedded device. There are plenty of variants of the standard UNIX utilities - the *BSD ones, the SysV rewrites, etc. There's absolutely no need to go for a single binary on any modern device.

  • The question should have been: How Far Should Sony Hate Go ?

    Why is the GPL preventing Sony from using BusyBox as is ? The source code is already available, so if they feel the burning need to make changes, they can simply post patches on the web. Am I misinterpreting the GPL here ?

    Why would rewriting BusyBox be considered cheaper/easier than complying with the GPL ?

  • by Anonymous Coward

    For several hundred years, and probably before then, there has been a struggle between individuals who strive for the possibility of social segregation and the perpetuation of (their) wealth, and individuals who strive for, effectively, a vision of communal merging of humankind. The former represented by a collection of mythologies related to social darwinism, self-sufficiency, republicanism, individual property rights and free will, and the latter represented by a collection of mythologies related to equal

  • Stupid question (Score:5, Insightful)

    by slimjim8094 (941042) <slashdot3NO@SPAMjustconnected.net> on Thursday February 02, 2012 @05:47PM (#38909167)

    The implication is clearly that we (as a community) shouldn't discourage people from using OSS code, or they'd start rewriting it to "get around" it.

    That's the entire argument for the GPL. Basically, if some simple conditions aren't met, you don't get to take advantage of all the work that's been put into it. The idea being that you'd rather they not use your code at all if they're going to be dicks about it.

    Sony, for reasons I don't quite understand but are entirely up to them, seems unhappy about putting the publicly-available-and-not-competitively-relevant source code on their website. More power to them, but the tradeoff is spending a bunch of time rewriting software that already exists and works fine. More power to them.

    When I license my code under the GPL, I realize that the odds of its reuse are somewhat smaller. But that's fine, since I'd rather that somebody saving time by building off my work makes their source available (to me, and everybody else). If they don't want to do that, I don't want to save them the trouble of having to write it themselves.

    The more interesting story here is that Sony's got it in its head that it'll be cheaper to rewrite Busybox than continue to have links to it. Not sure how they figured it.

    • Sony, for reasons I don't quite understand but are entirely up to them, seems unhappy about putting the publicly-available-and-not-competitively-relevant source code on their website

      Probably because they don't want the bad press of an open source group claiming that Sony needs to open source all their source code if there's even one bit of GPL code sitting on the same media.

      I know that's not what the GPL says, but it hasn't stopped certain companies (*cough* MySQL AB *cough*) from chasing after people waving that interpretation. After being in a company that was stung by MySQL, I'd give the same advice to anyone I talked to as well. Don't use GPL code unless you're willing to either:
      a)

  • DRTFA, but if they are advocating not enforcing the GPL and just developing instead - why don't they just advocate using a BSD derived licence?

    In other words, if you have chosen to use GPL for your code, then you must have done so because you want people to abide by those conditions, and so you must want to enforce them.

    If you don't, then don't use GPL.

    If you selectively enforce GPL, then it just weakens enforcement.

  • by ahecht (567934) on Thursday February 02, 2012 @05:48PM (#38909193) Homepage

    Once again, Slashdot links to a blog instead of the original source. The linked blog gets its evidence from a wiki page at http://www.elinux.org/Busybox_replacement_project [elinux.org]

    This page has a Q&A which clearly states that it is not a Sony project:

            Q. Tim Bird, the proposer of this project, works for Sony. Is this a Sony project?
            A. No. Although Tim is employed by Sony, he spends a portion of his employed time working on behalf of the embedded industry to improve Linux and encourage GPL compliance. As of February 2, 2012, Sony has not endorsed or agreed to support this project. This wiki page is for gathering information and project description information, to present to various companies to solicit support and resources for the project.

            Q. Can Tim's creation of this proposal be used to infer anything about Sony's compliance record, future compliance intent, or other business practices?
            A. Tim has only recently informed his management about this proposal, and Sony has not yet (as of 2/2/12) agreed to support it. So, "no, not really". Sony has a good compliance record, and has strong compliance policies in place. It has never been contacted by the SFC and has no expectation of being contacted by the SFC about any license violation of GPL software. Tim is doing this as part of his (paid for by Sony) role in the industry to address issues which inhibit the adoption of Linux in consumer electronics.

  • by nadaou (535365) on Thursday February 02, 2012 @06:02PM (#38909355) Homepage

    Proffitt is a financially motivated troll, raking up the mud to get page hits. Please stop posting his blog posts, they don't help improve our lives or our software.

    thank you

"You need tender loving care once a week - so that I can slap you into shape." - Ellyn Mustard

Working...