Hacker News new | past | comments | ask | show | jobs | submit login
The ongoing fight against GPL enforcement (mjg59.dreamwidth.org)
161 points by mjg59 on Jan 30, 2012 | hide | past | favorite | 90 comments



Maybe I misunderstood, but I'm not seeing how this is bad.

Sony wants to write a BusyBox that doesn't use BusyBox's license? What exactly is the problem? If they don't like the license isn't that the best approach they can take?

"A couple of weeks ago, this page appeared on the elinux.org wiki. It's written by an engineer at Sony, and it's calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it's not - it's explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity."

Wait, didn't GNU and the GPL start off for the completely non-technical reason that Stallman didn't like the original license?

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.


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.


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


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


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.


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.


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.


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.


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


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.


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


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.


This is bad because Busybox has copyright holders that actively enforce the GPL on their product.

They're not asking for this because they dislike Busybox'es GPL license. They're asking for it because they know Busybox actually goes to court to enforce it, and asks for the other GPL products to have their license respected too.

I'll spell it out more clearer: they want to get rid of Busybox, because its one of the only things whose license they cannot violate with impunity.


I'm still not seeing the problem.

On one hand, if the license holders of the other infringing software don't care to enforce the license, why should anybody care? It makes no sense to me, but it's up to them.

On the other hand, if Sony would rather write it themselves than abide by the GPL then I'm not seeing the problem there, either. Again, it makes no sense, but it's their decision.


On one hand, if the license holders of the other infringing software don't care to enforce the license, why should anybody care? It makes no sense to me, but it's up to them.

Believe it or not, most free software developers aren't dying to spend their time and money to start a copyright lawsuit against Sony. That doesn't mean they're actually OK with their copyright and licenses being violated. Public shaming is often much more cost-effective. But if there's one company that doesn't give a rats ass, it's Sony.

Most free software developers also don't register their copyright (unlike Sony) and so aren't entitled to those fantastically high statutory damages. They have to prove actual damages. For free software.

Good luck.


Here's a question: How is Sony's behavior on this so different from what MegaUpload is being accused of?

Basically, Sony is admitting that they are doing this so that they can avoid complying with the GPL, meaning that it is their intent to violate copyright law, knowing that they probably won't get sued over it. Isn't this a criminal act on the part of Sony?

I realize that it isn't as cut and dry, but I do see some strong parallels.

Further, why are these companies so stupid as to not release the source for their BusyBox implementation without being sued? It seems like it would be much, much simpler than trying to hold onto it and then be forced into a situation of releasing the source for everything that's covered.


Indeed - Pragmatically, why should sony care? They will care when they end up in court because the rightsholders go after them. if the rightsholders are not willing or able to do so, then sony doesnt have much to worry about. thats business.

Sony aside, I wondr if it is legally feasible for there to beaclass action suit against a large serial gpl violator, the class being developers only related by the license they chose to use.... copyright violation is illegal, after all, right?


If there are GPL software developers who are having their licenses infringed and want to enforce, they can grant SFC the authority to enforce. I really don't see the problem here.

On the other hand, more software that is not infected with a proprietary or copyleft license is always good.


And that is exactly what this post is requesting that they do. It is making it clear that this is an option and asking that they do it.


The article made it clear that it's _expensive_ to enforce the license, and time consuming. Most software developers don't have the kind of deep pockets, or the time, required to chase down Sony. You may be both wealthy, and have lots of time on your hand - in which case, it would make sense for you to chase down Sony violating your copyright - if you are so inclined.

Nobody has a problem with Sony writing their own version of BusyBox - good for them if they can do it. But, if the reason they are writing their own version, is so they can, without worry, violate _everyone else's_ copyright - then that's somewhat shady behavior.

Ironically - from a "Game Theoretic" position, Sony's approach is entirely rational. Take out the opponent who can stand up against you, and crush those who can't.

So - I'm simultaneously impressed by their strategy while offended by their attitude.


So, if they switch to (say) a full BSD-licensed stack, what is the problem? They can use it for whatever, modify the code for whatever, and there shouldn't be any problems.

Why is this a bad thing, other than that it weakens the importance of the GPL?


If they were going to switch to a full BSD-licensed stack, there would be no problem.

They want to switch to a mostly-GPL stack, except for the one component that causes them to have to live up to their GPL obligations.


Ah, so, that's kind of a dick move. Thanks for the explanation!


until any other rightsholder whos copyright is being violated does the same thing....... its pretty simple.


That would be fine but the article indicates that they want to continue to use other GPL code (like the Linux kernel) without complying with the GPL. Only Busybox copyright holders have been eager to prosecute violators - removing Busybox would let vendors violate the GPL with little practical consequences.


is it realistic for someone who releases their code to expect an unrelated party dealing with a license violation to just give them a free ride to enforcement? I mean, fine if they do, but it is by no means expected. I dont disagree with how this looks on sony's part, but mucking about with other peoples license enforcement smells kind of funny. Who says sony doesnt have a license from the author on a given piece of code? I mean, sure, then linix kernel andwhatnot, we know, but hypothetically, they could be usingsoftware available to the general public under gpl, but licenced to sony including non-disclosure terms about the license - only thecopyright holders can go after them, as it should be.

If its your work and you hold the copyright, how you license, distribute, and enforce it are all up to you.


Hypothetically, Sony products could be coming bundled with unicorns. Just because something is possible does not mean that it needs to be considered. What you are saying is highly improbable. In fact if we had any chance to find out, I could bet you on this, with outrageous odds.

> If its your work and you hold the copyright, how you license, distribute, and enforce it are all up to you.

Your ability to do this also depends on the legal system, which makes it hard for the little guy with respect to a big corporation. This is why we have mechanisms like SFC.


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.


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.


The problem is that, in many cases, busybox is the only program you can actually "see" and hence enforce the license on. Once that disappears, everything behind it becomes technically invisible; so you could use this "piratebox" plus other infringing software, and be safe.

It's sad, really. I can see a future where a terminal program or command is embedded in the linux kernel and cannot be removed, only to force companies to stay honest.


The implication is that Sony is presently shipping software with Busybox and knowingly violating the licensing terms. If they rewrite Busybox in the interim they will be able to get away scot-free despite their years of flagrant copyright violation. Given the variety of devices Sony ships and their complete lack of respect for the GPL, their plan could very well work unless someone catches them red-handed.

And the point is that the people who wrote Busybox don't want money if you're infringing their copyright - they just want to see exactly what you've done with their code, and get the chance to play with it. Which is pretty reasonable when you think about it.


Sony is presently shipping a lot of stuff with Busybox in, but they are not violating the license terms. Here you can download a zillion Sony-patched versions of Busybox to your hearts content: https://products.sel.sony.com/opensource/source_tv.shtml


The "2010 and later" section is empty. I guess it's possible that they stopped building new products which use GPL code in 2009, but somehow it seems unlikely that they stopped updating or patching old ones at the same time. If it takes them two or more years to ship the source, after they're already shipping the binaries, are they in compliance?


if you go here:

https://products.sel.sony.com/opensource/

you'll see other products such as webkit with updates in 2011


the problem is that the GPL is still being violated (because linux and a host of other libraries and tools are still being used), but there's no longer a good tool to enforce it because most GPL copyright holders don't have the will or the means to pursue violators.

Note that busybox is only used to obtain the source code of parts of the product for which source code is already required to be provided by the GPL or similar licenses. It's not used to get code which isn't covered by the GPL (although it could in principle be, or at least force the company in violation to choose between that and coming into compliance by removing all use of busybox)


The problem is that the rewrite is coming AFTER they've been shipping with busybox and already not complying with the license.


Cite? (besides a wiki page that can be interpreted different ways)


> 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 you get explicit permission from the author. The SFC then made a condition of granting permission to BusyBox, that the violator come into compliance regarding all other GPLed projects.

But that interpretation is not a legal fact. Another interpretation - which seems much more reasonable to me, and was certainly the intention I had when I released GPL code myself - is that you lose the license when you violate it. But as the GPL states, you get a license when you download a new version of the software anyhow, so the problem goes away - unless you violate the GPL again. In other words, if you violate the GPL, you have no license to the code, but once you comply with it, you are fine.

The former interpretation always struck me as bizarre: If you lost the license when you violated the GPL, surely you lost that license to that particular software. But how can that prevent you from getting a new license to a new version of the software? How are those connected? Or how about a new version of the software that was rewritten from scratch, and has no code shared with the one you were temporarily in violation from? Is the mere name enough? How about forks of the project? If any of this were what the GPL originally intended, you would think it would have been specified in some way. The much more reasonable interpretation is the second one: You lose the license to the concrete software you were given a license to before. Download a new version, get a new license. Stop violating the license, and you are ok.


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 defendants involved in the SFC lawsuits appear to have made.


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


But how can that prevent you from getting a new license to a new version of the software? How are those connected?

They're connected because some of the originally licensed copyrighted material still exists in the new version. You would get a clear license to any new material that you hadn't previously licensed (and hence hadn't violated the license of), but that's not very helpful.

Or how about a new version of the software that was rewritten from scratch, and has no code shared with the one you were temporarily in violation from?

If it doesn't contain any material that you'd previously violated the license of, then you would seem to be in the clear.


... 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 someone else's IP is a privilege, not a right.


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.


Yea, isn't this pretty much what Linux and GNU did? They saw software with restrictive licensing that they wanted to use, so they re-wrote it completely and released it under a license that worked for them.


No, this is not what Linux and GNU did, because they rewrote all the software they wanted to use. The linked article accuses Sony of only wanting to rewrite the software that gets them caught, so they can continue ignoring the GPL obligations on the rest of the software they use.


Thats how things work..... why would you spend time and money on something that is not likely to cause you damages? It is a calculated risk..... andnthey arent eliminating the risk, just reducing it.


If you honestly believe that it's acceptable to screw over your business partners (and the people who write the software that your business depends on are your partners, even if there's no monetary recompense involved) as much as you want up until you get caught, I'm not sure I can explain this in terms you'll understand.


So an analogy would be that Pirate Steve wants to put the entire criterion collection (http://www.criterion.com/library) on the pirate bay. However, he knows that Fox is really litigious about their movies, so he replaces all of their movies with garage remakes (like "Be Kind, Rewind") so that he can safely pirate the rest of the movies since the other motion picture studios are lazy.

Is my analogy correct at all? Essentially Sony wants to be able to pirate (that's what it's called when you're redistributing things that are copywritten), so they're removing the only project that actually litigates against them?


That's the gist, yes.


> copywritten

Copyrighted. It's about rights, specifically the right to copy.


So much for the Holy Sacrament of "Intellectual Property". When it suits a corporation, the Most Holy Eye Pee Must Be Protected By Any Means, Including Taking Away of Civil Liberties. But when it also suits a corporation, they get to take what, if they owned it, would be Most Holy Eye Pee.

What a bunch of hypocrites. If BusyBox made Sony money, they'd fight an attempt to replace it tooth and nail, as AT&T did with BSD.


In case someone from Sony is reading this - things like this result in lost sales. I research my buying options extensively and usually make a ranking of alternatives. The following sony products were at the top of their respective lists but I chose to not to buy them a) Camera - Sony Nex-5N (Bought a Canon S90 instead) b) Laptop - Sony Vaio Z with the 1920x1080 screen (Bought an HP Elitebook instead) c) Camcorder - HDR-CX700V (Bought a Panasonic TM900 instead) d) Noise cancelling headphones - MDR-NC100D (Bought Sennheiser ones instead, dont remember the model number)


I don't know about that; at this point anyone who cares about high standards has been boycotting Sony since the rootkit fiasco. Of course, this makes things worse, but that's not saying much.


When I said things like this, I definitely meant to include the rootkit fiasco. The last couple of years I do try my best to not buy from companies that I think have an antipathy to the hacker ethic.


I, too, refuse to give Sony my money. And I tell my family and friends why. Slowly, it's sinking in.

P.S. For a multitude of reasons. E.g. attempting to rootkit my computer using a legally purchased CD.


I have refused to buy any Sony products for a good number of years now and have no intention of ever buying any of their products in the future. Their actions have lost me as a customer[1] and they will never get me back.

Sadly, I am currently using a Sony Ericsson phone, though somebody gave it to me - I did not buy it.

[1] I have owned many Sony products in the past, including (but not limited to) the Playstation and Playstation 2 (and many many games for both of these), so I am definitely a lost customer and not someone who claims to be one but who never bought their products to begin with.


I stopped giving Sony money since they failed to protect my personal information on their Playstation network - three times!

Things I have not bought because of this: a TV, an ultrabook, a tablet and an Android phone.


Isn't S90 a compact camera? It's much worse quality than the NEX series. If you care about that, try Olympus E-P1 or some other mirrorless camera.


Yes I know the S90 is a compact camera. Rather than go one down in the category, I decided to go one category down and buy the top camera in that category. fwiw here is a picture from the S90 and one from the Olympus E-P1

http://a.img-dpreview.com/reviews/canons90/samples/comparedt... http://a.img-dpreview.com/reviews/OlympusEP1/samples/compare...


Looks like the s90 has some barrel distortion, but you expect that with a wider zoom lens. Otherwise, there's not much to differentiate them. But the picture was taken in good light.

The E-P1 has a much much larger sensor, and should be much better than the s90 in bad light. Also, you can get a nice 10mm prime for the E-P1 (20mm full frame equivalent, compared to the s90's 28 mm FFE at its widest), or a fast portrait lens, or a telephoto.

On the other hand, u4/3 lenses are often insanely overpriced (at the moment), and the s90 fits in your pocket.


Another plus for Canon:

http://chdk.wikia.com/wiki/CHDK


Someone should re-write this blog post and re-submit it to Hacker News. It's so confusing what the problem really is, or what the author is really saying. I had to read this about 3 times to understand it. He should just say: many hardware manufactures use several GPL projects on there embedded devices, one of those projects is BusyBox. Since BusyBox copyright holders allow SFC to defend their copyright, the SFC is able to force this manufactures to comply with the licenses of all the GPL projects they use. Sony and other manufactures are looking to have a BusyBox alternative so that they can infringe the other GPL product licenses they use, since they know no-one enforces this licenses. Those who own GPL licenses should contact the SFC and allow them to enforce there copyrights.


>The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

Wait what? This has actually happened?


That's more than fair: you can use our code as long as you don't rip anybody else off either.


fair as long as theother rightsholders involved are informed..... it is their choice whether or not to force the license issue - for all we know they decided to let sony have software X..... if this is done without implicit cooperation with other rightsholders, its sort of stretching......


If Sony has received licenses to software X, then there's no problem:

> "you must provide the source code to all other works on the device that require source distribution"

If Sony has a different license from the copyright holders of software X that means they're not required to distribute source, presumably all they need to do is produce that license if their claim is challenged, or get said copyright holders to confirm it.


for all we know they decided to let sony have software X....

If they did, there should be evidence (a licensing agreement, perhaps) of that decision. If there's no formal agreement, the existing license has authority, and it's perfectly reasonable for the SFC to require adherence to the licenses of other packages used as a condition of re-licensing BusyBox to the infringing party.


Yes, it's part of the SFC's standard settlement.


A thief must expect suspicion the second time around.


Yes, this happens all the time in the world of GPL enforcement.


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.


This article mostly seems to be suggesting that vendors derive more benefit from GPLv3 - which is more focused on coming into compliance, rather than punishing companies that get it wrong.

I'm not sure what this has to do with busybox, save that under GPLv2 there are vendors who are afraid to use them because they have actively been pursuing an aggressive course of action under GPLv2 for several years.


I'm not saying it's OK to violate the terms of open source licenses, but the GPL has never fit with my idea of what Free Software should be like. I see Free Software as a gift given to the world as a whole, regardless of what they plan to do with it. Thus I see GNU and the FSF as terrible gift-givers.


Free Software is not a gift. That is where you go wrong. Just because you want it to be does not make it so.

Free Software, as advocated by the FSF and many others, is an attempt to remedy the ethical problems posed by closed source software, which has a strong tendency to lead to monopolistic behavior and unfair power balance between the consumer and the producer of a program.

Free Software may be many other things as well, depending on who is writing the software and releasing the code, but it's almost never a gift. The developers almost always want something in return, whether that is recognition, assistance with development or support for their ideals.

People who give software as a gift, release it into the Public Domain or use the most liberal of the BSD licenses. :-P Those who chose other licenses, do so for reasons you should respect if you intend to benefit from their work.


"Those who chose other licenses, do so for reasons you should respect if you intend to benefit from their work." Of course. Authors are free to release software under whatever terms they like, and people who use the software are bound to abide by those terms. Let me be clear, I don't think that it's OK to violate the GPL. I was just saying that I don't really like the GPL.


>Free Software is not a gift

Yes it is, that is what free means. Check a dictionary.

>Free Software, as advocated by the FSF and many others

The FSF doesn't actually get to re-define the word free to mean "mandates the set of restrictions we desire".

>People who give software as a gift, release it into the Public Domain or use the most liberal of the BSD licenses

Both of which are free software.


The GPL and the concept of keeping software free permanently embodies the very definition of Free Software.

What you're saying is "the absence of color doesn't fit my idea of what black should be, I see black as having a little touch of yellow in it".


Alright, Free Software isn't the appropriate term for the type of open-source license that I appreciate. I apologize for my poor choice of terms.


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.


Looking at SFC's website, it appears that people actually assign their copyrights to SFC.


I can see why other projects are hesitant to join in.


not exactly.... they are enforcing their own copyright, and by virtue of the license wording, using it as easy leverage to insist the infringing product is cleanly complying with similar licenses before granting a new license.


SFLC is far from a well supported organization in the GPL world. You say that the busybox settlements are necessary because most authors lack the means or the time to pursue violations, but in fact anyone who wished SFLC to act on their behalf is free to let them - and yet no one does.

It is telling that not a single mainline kernel copyright holder will allow them to, including your employer and many of your coworkers. As noted elsewhere in the comments, Rob Landley regrets assigning them rights for busybox, and no other authors have been represented in the suits.

The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.

Quoth wikipedia:

On 7 December 2007, a case was brought against Verizon Communications over its distribution of firmware for Actiontec routers; this case was settled March 17, 2008 on condition of license compliance, appointment of an officer to oversee future compliance with free software licenses, and payment of an undisclosed sum.

On about Aug 03, 2010, BusyBox won triple damages of $90,000 and lawyers' costs and fees of $47,865, and possession of "presumably a lot of high-def TVs" as infringing equipment in the lawsuit Software Freedom Conservancy v. Best Buy, etal., the GPL infringement case noted in the paragraph above.

The suit against High-Gain Antennas was settled on March 6, 2008 with the company agreeing to comply with GPL and paying an undisclosed sum to the plaintiffs.

On October 30, 2007, an SFLC press release announced that the lawsuit had been settled with Monsoon agreeing to comply with the GPL and pay a sum of money to the plaintiffs.

etc.


That's a somewhat misleading. The TVs were awarded to the SFC by a judge in lieu of costs and any other settlement - Westinghouse, the company involved, had declared bankruptcy and were no longer paying their lawyers. There was no settlement in that aspect of the case, and Westinghouse never came into compliance. And if a settlement doesn't involve any payment, congratulations - you've just spent a significant amount of money and you haven't got your costs back.

Many kernel authors simply don't care. Many others are employed by companies who would prefer not to potentially scare off customers, or are contractors who work directly for companies that are concerned about increased enforcement. Some have performed all their work under work to hire conditions and are in no position to engage in any kind of enforcement. While I'm sure some do disagree with the SFC's actions, I'd be astonished if that's the overwhelming reason for a lack of involvement.


Please don't confuse the Software Freedom Law Center (SFLC, providers of legal services to numerous FOSS projects) with the Software Freedom Conservancy (SFC, a GPL enforcement organization who holds some of the copyrights to Busybox). In particular, even if you don't like the work of the SFC, please don't use that to complain about the SFLC, an entirely separate organization.


Rob Landley sure seems to believe the SFLC is in control, as he repeatedly faults the SFLC for their judgement in what suits to bring regarding busybox. They share a number of directors and staff and a few years ago the conservancy's web presence was hosted on a subdomain of the sflc.

In the SFLC's own press releases on the subject they note that they (the SFLC) identified organizations not in compliance, set the terms for getting into compliance, and decided who and when they should sue. At least at the time, the director of the SFC was a paid staff member of the SFLC.

Doesn't really sound like entirely separate organizations to me.

http://www.h-online.com/open/news/item/SFC-and-SFLC-sues-Sam...

EDIT: quote: Because many of its clients could benefit from the protections of having a legal entity as well as tax exemption status, but were reluctant to pay the fees associated with formation or dedicate the time necessary to start and maintain a tax exempt nonprofit, the Software Freedom Law Center has established The Software Freedom Conservancy. Since its launch in 2006, the Conservancy has grown to include free and open source software projects active in a wide range of fields.

https://www.softwarefreedom.org/resources/2008/foss-primer.h...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: