[twstws]

You have misunderstood. The current situation has Sony shipping devices running several/many different programs with GPL licenses. They don't want to provide their modified source code for these programs to their users, in violation of their obligations under the GPL. Most of the copyright holders of this code do not have the means to pursue an infringement case.

Busybox is the exception. The SFC actively enforces the license for busybox. In addition, once you lose your right to use busybox as a consequence of a license violation, the SFL will let you ship it again only if you come into compliance on for all of the GPL code you ship.

So they are making their own busybox as a way to continue to violate all the non-busybox GPL code they use.

If you comply with the busybox licence, you can continue to violate the licence on all the other GPL code. But violating busybox means you have to comply with all of your GPL code.

You never have to release your non GPL code.

[kryptiskt]

> They don't want to provide their modified source code for these programs to their users, in violation of their obligations under the GPL.

The fact that a Sony guy wants to build a non-GPL Busybox is not evidence of any Sony violations of the GPL, now or earlier. There is some radical jumping to conclusions here.

[dman]

This is from the linked elinux page - "Busybox is arguably the most litigated piece of GPL software in the world. Unfortunately, it is unclear what the remedy should be when a GPL violation occurs with busybox. Litigants have sometimes requested remedies outside the scope of busybox itself, such as review authority over unrelated products, or right of refusal over non-busybox modules. This causes concern among chip vendors and suppliers."

[fpgeek]

Chip vendors and suppliers could have concerns even if they are not violating the GPL. For instance, they may believe their modules contain important trade secrets. Given that, they might not want anyone they haven't approved to review the modules period.

[mjg59]

The only code that they'll ever be obliged to release is code that's covered by licenses that already require them to release it, and if their trade secret containing modules aren't derived from GPLed works then it's not an issue. If they are, then getting rid of Busybox reduces the probability of a lawsuit - but shipping other GPLed code (like, say, the Linux kernel) means they're still vulnerable.

[fpgeek]

Perhaps I have misunderstood something. Wouldn't you have to analyze all of the non-busybox modules to determine whether or not any non-busybox modules are GPL-derived?

I'm suggesting that some companies would not want to let you analyze their trade secret modules on principle even when they aren't GPL-derived. I'd say that concern is unreasonable, but that doesn't mean some companies don't have it.

[el_presidente]

The wiki page mentions "review authority over unrelated products". It sounds like someone (the SFC? the busybox people?) will be able to see all their code to ensure that there aren't any more violations. Anyway, it's hard to believe that the person who wrote that page is whining about something or someone being unclear.

[nona]

It's easy to avoid trade secrets in unrelated code being exposed. Don't infringe on the GPL in the first place!

[fpgeek]

Do you have actual evidence Sony is violating (or intends to violate) the GPL with respect to non-busybox code? Or are you just speculating?

Let me put this another way: Do you think the developers behind editline wrote it because they wanted to violate the GPL? Or did they write it for some other reason?

Personally, I read the Sony post very differently. It sounds to me Sony, in part because of the aggressive stance SFC takes with busybox GPL violations, isn't happy with the business costs of using busybox (e.g. concerns among chip vendors and suppliers). They could easily be wrong in their assessment of the business costs (e.g. concerns from chip vendors and suppliers should not be taken seriously), but given that assessment, it seems to me that writing a busybox replacement is a reasonable response.

[ignoreme]

>aggressive stance SFC takes with busybox GPL violations

I would hardly call enforcing their license an "aggressive stance". When a company enforces their right against those that violate the terms of their proprietary license it's considered "normal" but if a Free Software developer does the same thing it's considered being "aggressive"?

Sony never originally intended to comply with the requirements of the GPL. They did violate the terms of the GPL. That isn't speculation. The reason they ever complied is because they were forced to.

For those saying that there isn't a problem as long as the original authors are not willing to go to court over the violation. Think about what you are saying for a minute. You are basically saying "it's OK to pirate someones work as long as they don't enforce their license on me personally". Yes it's "piracy" as the same companies have defined it -copyright infringement-.

[fpgeek]

Let me try to be precise: I'm not characterizing enforcing the busybox license as aggressive. I'm saying that using a busybox license violation to bootstrap an investigation (and potential enforcement) related to GPLed code for which SFC does not hold the copyright is aggressive. That doesn't mean it is wrong, or even unreasonable, it is just aggressive.

Let me try an analogy: Suppose that, as part of a BSA settlement, they didn't just require you to come to terms with any BSA members whose licenses you were violating, but also with any non-BSA members whose licenses they judged you were violating. Having never had dealings with the BSA they may well do this (in the interests of drumming up new members or something). Nevertheless, I would characterize that in exactly the same way: not wrong, or even unreasonable, just aggressive.