Live data from Hacker News

The ongoing fight against GPL enforcement

mjg59.dreamwidth.org

51–60 of 94 posts

Re: The ongoing fight against GPL enforcement

#51
post #49

Earlier quoted context omitted.

If it's about violations, or money, I can't strictly tell; it's one of those things that depends on who you talk to: http://lwn.net/Articles/475901/

The SFC's a 501(c)(3), so any money from the suits goes back into supporting their associated projects or supporting other ongoing actions.

That they use the money for "good things" is great; however, if you're trying to get greater compliance then perhaps this approach is flawed.

If they're placing too high a monetary value on non-compliance with the license, then you could easily see why these companies would push back and seek these types of alternatives; or flat out deny the use of (L)GPL software in their products entirely. In the end, this is probably the opposite of what the SFC intended and may result in the loss of their greatest legal tool.

Re: The ongoing fight against GPL enforcement

#52
post #37
post #26

Earlier quoted context omitted.

> I'm also not sure I like the idea of using BusyBox as a backdoor to examine the rest of a product's source code. I didn't realize that was a condition of the GPL, but it makes me glad I've switched most of my projects over to the BSD and ISC licenses. This is based on one interpretation of the GPL: That if you violate the license, you lose the license to that software forever, including new versions of it, until yo…

... how can that prevent you from getting a new license to a new version of the software? How are those connected? They are connected in the way that the same people whose license you violated are the ones granting you the new license. And I'd say they have reasonable doubt as to whether you will comply with the new license, since you didn't before. They don't have to grant you a license to use it, you know. Using so…

My point though is that when someone releases code under the GPL, they give a license - to the code being released just then - to everyone that gets that source code. This is what the GPL says. Yes, they don't have to - but they are being nice and releasing it under the GPL.

I don't see where it says that the license being given is not to people that violated the license on previous software being released. Again, if you argue that, then you get into the problems with "is this the same as the software from before" that I mentioned.

Re: The ongoing fight against GPL enforcement

#53
post #36
post #26

Earlier quoted context omitted.

> I'm also not sure I like the idea of using BusyBox as a backdoor to examine the rest of a product's source code. I didn't realize that was a condition of the GPL, but it makes me glad I've switched most of my projects over to the BSD and ISC licenses. This is based on one interpretation of the GPL: That if you violate the license, you lose the license to that software forever, including new versions of it, until yo…

That's certainly another plausible interpretation, but it's not one that the license authors appear to agree with - otherwise, the additional paragraph in GPLv3 wouldn't be necessary. Individual authors may obviously disagree and refuse to enforce the license in that manner, but it's something that you probably want to confirm with the copyright holders before relying on it. It's also not an argument that any of the…

> That's certainly another plausible interpretation, but it's not one that the license authors appear to agree with - otherwise, the additional paragraph in GPLv3 wouldn't be necessary.

The FSF has stated that the additional wording in the GPL3 was to avoid confusion from other possible interpretations in the past. So I don't think the GPL3 wording proves either previous interpretation is right - it has been used to argue that either of the two is, actually - all it shows is that there was some lack of clarity.

Re: The ongoing fight against GPL enforcement

#54
post #49

Earlier quoted context omitted.

The SFC's a 501(c)(3), so any money from the suits goes back into supporting their associated projects or supporting other ongoing actions.

That they use the money for "good things" is great; however, if you're trying to get greater compliance then perhaps this approach is flawed. If they're placing too high a monetary value on non-compliance with the license, then you could easily see why these companies would push back and seek these types of alternatives; or flat out deny the use of (L)GPL software in their products entirely. In the end, this is proba…

My understanding is that any amount above costs is pretty limited - it's also far less than commercial licensing of the code would have cost.

The companies who habitually violate the GPL contribute approximately nothing back to the wider ecosystem. The best you can say is that they gain brand awareness for Linux, but that's it. People release code under copyleft licenses because they want people to provide source to their downstream recipients. If they were more interested in brand awareness than source, they'd have used a liberal BSD-style license instead. Having vendors refuse to use GPLed code because they don't want to ship source is arguably a perfectly reasonable outcome.

Re: The ongoing fight against GPL enforcement

#56
post #27
post #15

Earlier quoted context omitted.

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 th…

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…

>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-.

Re: The ongoing fight against GPL enforcement

#57
post #31

As a thought experiment, it's funny to think about what GPL enforcement could have done with SOPA, had it passed. Especially if software/firmware updates were distributed via the web. On the one hand Sony is pushing for SOPA, but on the other hand Sony is violating the GPL. They could end up actively pushing through legislation that ends up significantly harming their bottom line.

I'm confident that regardless of the ultimate outcome of the Battle For Freedom on Internet and Intellectual Property, it will remain that the most wealthy most often gains financially from their own wrongdoings. The judiciary system will remain the warhammer of giants, way to heavy financially for most individuals and small companies.

Re: The ongoing fight against GPL enforcement

#58
post #55

SFC enforces copyrights on others behalf's?? Isn't that where Righthaven failed because it isn't actually allowed?

Righthaven didn't own the copyrights on the material; they were simply "granted" the right to sue, which turned out to be bogus from a legal perspective. To enjoy the benefits of SFC enforcement, you must assign your copyrights to SFC thereby avoiding the Righthaven situation altogether.

Re: The ongoing fight against GPL enforcement

#59
post #27

Earlier quoted context omitted.

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…

>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…

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.

Post reply on HN