Hacker News Reader

Comment by tempnow987 | Hacker News Reader

Wow - to say this is a major major result in an understatement. This is going to turn GPL litigation on its head, and allow more activist type folks to pursue cases aggressively. On the developer side I can see a move away from GPL - as adding third parties into this is going to be pretty unappealing for some developers.

I think historically distribution of source code was seen as a condition of the copyright license (which meant copyright holders enforced), not as a separate contract right available to third parties (which would mean users and other can go after a variety of claims).

View on HN

On the contrary, as a developer, this makes GPL even more appealing to me.

I don't have time, money or energy to sue someone for using my code and not giving back.

But if downstream users can, and the math changes.

In the old model in that case you could assign or work with any of the litigation groups already doing the work needed to allow them to sue on your behalf.

Downstream users can also of course sue you if you work on a project with a few other people under the GPL even if they didn't write any code or contribute.

Someone could "use your code and not give back" while staying perfectly within the limits of the GPL, though. For example, they could use and modify your software in an internal package.

This is something that's always been slightly unclear to me. I think you should be able to do whatever with any copyrighted code that's been published (by someone who has the right to do so) for your own personal use, regardless of license. Clearly publishing this copyrighted is not possible without some kind of license.

However where 'personal use' ends and 'publishing copyrighted code' begins is not entirely clear to me. Does an internal tool in a company still count?

> Does an internal tool in a company still count?

I would think so, yes. If I take a piece of information and do something to it inside my house, that's my business. If I show it to my friend, it's between him and me. If it let my coworkers see it so that they can only see it within the office, it's between them and me. And so on. The only issue would arise if an employee asked to see the source of such an internal tool and was denied.

The FSF FAQ explicitly states that internal use within a corporation does not count as distribution. It's one legal entity and can't violate copyleft on its own. A gray area would be a subsidiary or joint venture sharing with a parent.

That's really interesting, because if a corporation bought a physical book, scanned it, and distributed it internally that would be a clear violation of copyright law.

GPL is copyleft (copies authorized by default) until you violate the terms. Then normal copyright law applies and it's the same as an unauthorized book copy.

> The FSF FAQ explicitly states that internal use within a corporation does not count as distribution.

It's probably a good thing on balance since it's one less barrier to companies using code under the license, but considering companies and their assets (including their internal tools) can be bought and sold, I'd personally consider that distribution enough.

Your reasoning suggests the terms of the copyright license do apply when used as an internal tool (you'd be free to keep the code hidden otherwise) in which case preventing anyone from publishing any work derived from code under a copyleft license seems impossible. At the very least the GPL doesn't seem to allow you to create a derived work and require people to keep it secret even if it's just internal to the office (though I guess they could keep it secret willingly, I just see no way to legally compel them).

This seems different from something that's purely personal use. I don't think it makes much sense to force a program to show a notice its GPL licensed if you're the only one using it for instance. In fact that seems to run counter to the intent of free software.

It's possible that legal systems treat this situation differently, but I think it makes far more sense if you don't need an additional license to use stuff that's already published by the copyright holder until what you're doing starts to go beyond just personal use.

Of course; those are freedoms 0 and 1 guaranteed by the license. It seems like "use" sometimes means "include in a downstream software package and redistribute modified versions of".

My point is that just having the GPL doesn't guarantee that modifications will be contributed back or published, even without violating the license.

Right, GPL only requires contributing forward, to the downstream users. It is only through creating a culture of working upstream and or reaching out to downstream redistributors that a project gets any contributions back, including financial contributions.

Yes, and that's good. Internal use is different from redistribution.

The important point is to prevent freeloaders from taking credit from your work [and sometime even competing against you].

True. As a original developer of code, it protects the original author and the real user. However the middlemen (companies who make money using others code) may not like this.

On the developer side I see the opposite: End users that are complaining can now deal with problem themselves without having to pester (or even find) the developer.

Anything that amounts to less pestering of developers is (probably) a good thing

I'm unsure of how the burden of proof would work if the developer is not involved. The end user may have a hard time even guessing whether a piece of GPL software is embedded in the defendant's software.

Someone with enough knowledge to provide the proof would still need to be involved, but it doesn't have to be the original developer(s).

This just makes me more confident in choosing GPL licenses for my projects in order to ensure user freedom.

Exactly. The choice of GPL is an explicit choice to protect end user freedom over reducing intermediate developer & corporation hassle. If you want to ensure end-user freedom, BSD, MIT, Apache style permissive licenses don't cut it. If you want to become a developer celebrity and have your open source project used in projects everywhere, or if you are a company and you want to hook other devs on your freemium open core product, then those licenses are for you. The decision about whether to use the GPL or not is far more nuanced and there is no one-size-fits-all license out there. If there was I suspect we'd all use it...

Interestingly in this case, this ruling also reduces intermediate developer hassle for devs who are already used to working with GPL code. So that's a nice win (=

Agreed.

Will be interesting to see where development / contributions by various players go in the future.

> protect end user freedom over reducing intermediate developer & corporation hassle

Actually it also reduces intermediate developer hassle: it's better if I don't have to rely on closed source firmware, firmware updaters, drivers, SDKs, proprietary tools.

It create openness in the whole software stack.

Then this will be a good result.

You of course may be sued yourself if you have a project using GPL'ed code that doesn't comply with the the current view of GPL (ie, release of encryption keys) or if you infringe your own GPL copyright in some proprietary project (ie, GPL code where user was promised access is in something that you don't want available broadly).

This is all good for users for sure for things like open core projects and projects that used to be open but moved away etc

You could only infringe the GPL copyright if you change the GPL license wording itself. The GPL license is a license that allows software using your copyright code to be used by others under certain conditions but at no point does it violate the law and remove your copyright in your own work, so there is no way someone could sue you (and win) for using your copyrighted work as you see fit, including licensing it under a separate distribution license to some third party.

That's the change here. Historically the GPL distribution language was a condition of the copyright license, so exactly as you said, no one could sue you because there was no separate contract element to end users binding them into a contract with anyone.

That is what is so exciting / different about this. When you make available software under the GPL, you have now entered into a CONTRACT (not copyright anymore) with all users that binds you to the terms of the GPL and gives them a right to sue for violations of THEIR independent rights.

This is the power of this new ruling, they can then sue you or anyone for breaking this agreement with them. Obviously will take some experience to see how far this can be taken. My understanding is the conservancy may want to try to leverage this to try to get GPLv3 effects into GPLv2 and a few other things the developers of for example Linux are not so hot on.

> When you make available software under the GPL, you have now entered into a CONTRACT (not copyright anymore) with all users that binds you to the terms of the GPL and gives them a right to sue for violations of THEIR independent rights.

Sure, anyone can sue you for anything. However nothing in this removes the copyright holders' ability to issue non-GPL licenses. A user of a product that uses a non-GPL license for that code would still have no standing for that suit.

Correct.

Historically one could contribute to a GPL project (potentially on a significant level for a corp) but wouldn't worry too much about using it in your own product that was potentially locked down - ie, DRM / motor duty cycle control, rev limits etc.

Linus / Linux have a long history of being pretty relaxed about your use cases, with the one key provision that you share your code.

Now, the group of people who can sue you is much larger. And some of them (conservancy in particular) may have views that don't align with your GPLv2 interpretation (particularly around tivoization / lock down issues for hardware devices). So if you are contributing too and shipping GPLv2 code - yes, you as the distributor of a larger body of code probably have a higher risk now of being sued.

Some links on the topic of GPLv2, installation, tivo and GPLv3. The Conservancy position seems to be that GPLv2 requires allowing installation but that what Tivo did (breaking proprietary software when you modify GPL software) is allowed by both GPLv2 and GPLv3. The main reason the GPL exists is to give downstream users the right to run modified versions, so their interpretation of GPLv2 seems reasonable to me.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

That is the SFC's position.

The main reason the GPL exists was to insure changes to code (forks) were available to original developers of the code so they could include those changes if they wanted (this was a result of issues with earlier unix systems that had fragmentation from forks). Additional, Linus, author of Linux, has been clear that his focus is getting code back, what happens to hardware was not covered in his mind by GPLv2.

So there is a dispute as to what GPLv2 requires with respect to hardware. It's clear that the code must be shared, and that's what a lot of GPLv2 devs have focused on. That the source code be shared, including scripts used for compilation and installation.

But (one view) is that is separate from mandating behavior of hardware, and that hardware can still check if its running approved code and refuse to run if approved code is not loaded.

That's why this case is so huge. The actual developers of Linux are not likely to try to enforce a term they don't think exists, the SFC very well may.

Nothing in the GPL requires giving back, only giving forward to downstream users, who may or may not give back or even publish what they received.

So what Linus wants from the GPL isn't even mentioned in the GPL.

It is only through a culture of contributing upstream and through upstreams reaching out to downstream redistributors and asking them to contribute upstream that anything gets upstream at all.

I suggest you read Conservancy's posts and the GPL, it does mention that installation is required to be possible and this requirement has always been present and enforced by copyright holders for GPL software, including for Linux itself.

> You could only infringe the GPL copyright if you change the GPL license wording itself.

Only if you had a time machine. Once you’ve distributed the code the horse has left the barn.

You can impose a new license on new versions of the software though.

You seem to have the concepts of copyright and license confused.

> you infringe your own GPL copyright in some proprietary project

You can't infringe your own copyright. If you own the copyright to the code, you can't violate GPL by using it, even if that code is licensed under GPL. This is because a copyright holder releasing only their code under one license, can also release that code under another, proprietary license.

That's what's so new about this. There is now a contract (not copyright) element - which binds you and the recipients of your code.

If you contribute to an open source project, then use that code in for example a locked down device, a user / conservancy who views that as a violation of GPL can sue you. That's important because historically developers on linux kernel have not agreed with conservancy views on things like encryption keys, and so have not pursued these types of claims and were somewhat unlikely to fully litigate claims against other contributors especially beyond just sharing code back.

As the conservancy notes, the universe of potential claimants (even with bogus claims) is now much much larger.

> If you contribute to an open source project, then use that code in for example a locked down device, a user / conservancy who views that as a violation of GPL can sue you.

If it is only code you wrote and you haven't transfered your copyright to the project, then No, this creates no standing.

> That's what's so new about this. There is now a contract (not copyright) element - which binds you and the recipients of your code.

Incorrect, there is a contract that binds you and recipients of the code under a GPL license.

If you receive that code under a different license, that contract doesn't exist.

Edit: Let me put it this way. Let's say you create a library and make it available under GPL. Any company that uses your code under that GPL license, has entered a contract with you that allows users of their software to sue them for GPL violations. However, you can also simultaneously offer a non-GPL, proprietary license for that library to paying customers. Those paying customers would not be part of any GPL contract, they would instead have whatever contract they signed with you when buying the proprietary license. The users of that paying customer would have no grounds to sue that paying customer, because that paying customer never agreed to the GPL contract. (OFC if you use other people's code in your library under a GPL license, then you don't have the legal right to offer a propriety license for that code.)

You are missing a large value to GPL code, it's often developed collaboratively.

Consider carefully your example, you've contributed to some GPLv2 body of code. Now you ship that code on your device (making available corresponding source code, but not decryption keys). You are not the only copyright holder, this is a collective effort.

Can you avoid the GPL'ed requirements? No. More critically, this allows new requirements to be asserted (under the GPL) that GPLv2 developers might not have considered something they want to enforce (hardware unlock) but users and activists might want to try and enforce.

All good for the users. Glad to hear this is welcomed by developers and those hiring open source contributors. This is still going to be a change from past GPLv2 experience I think for some / many.

I'm missing something here. Are you saying that people should be able to (or were previously able to) violate the GPL with software that they contributed to, but didn't completely write? What about the rights of the other contributors?

edit: if not, maybe you're trying to say that the people who control the license to the project (and have the contributors' agreements to prove it) can't relicense the code however they want (and however is allowed in the agreement) for whoever they want? Because I don't think that's true.

In the past if you were a contributor and violated the GPL in terms of your product (that used yours and others code) it was only other contributors who could sue you (ie, you broke your deal with them, and they had the copyright that was violated).

There are different views on the GPLv2. Most of the contributors / developers on GPLv2 just wanted you to share back your code, so most litigation in this space followed that approach. Even there, it was at times pretty cooperative.

The SFC has a MUCH more aggressive view. They have views around DRM / unlocks on hardware and much more that are very user rights focused, but pose complications to developers. In the past though, they really couldn't pursue these claims because despite lots of contributors to projects, many didn't support their approach and so wouldn't work with them to make copyright claims. To give you a sense of some developers views:

"lawyering has become a nasty festering disease, and the SFC [Software Freedom Conservancy] and Bradley Kuhn has been the Typhoid Mary spreading the disease." - Linus Torvalds (key player in the Linux kernel development).

They and the EFF created Affero GPLv3 and GPLv3 to try and solve for some of the issues they felt were important, but developers didn't really get on board.

The key is SFC can now sue folks making and distributing devices with OSS software WITHOUT any permission or input from the creators and copyright holders of the software, that is what is so huge. And this is particularly important because many authors and copyright holders have different views on these issues compared to the SFC.

We went though this once with GPLv3 already. SAMBA for example moved pretty aggressively to GPLv3. I'm not sure apple kept contributing to it or updating it in their software once that happened.

Its interesting to note that the GPLv2 doesn't say anything about sharing back your code, only sharing forward your code to downstream users (who might or might not then share that code back upstream). So downstream users have the same access to software as upstream authors; that makes the SFC position seem much more consistent with the GPL than what Linus says.

> The key is SFC can now sue folks making and distributing devices with OSS software WITHOUT any permission or input from the creators and copyright holders of the software, that is what is so huge. And this is particularly important because many authors and copyright holders have different views on these issues compared to the SFC.

Sure, its easier to get standing to enforce GPL, but the legal requirements of abiding by GPL have not changed due to this decision. The only change is that GPL violations that were hard to pursue are now easier and people that have been violating GPL will be more likely to face consequences.

If this that GPL projects have lower adoption rates then that is because fewer people who would have violated the license will bow avoid it. Similarly, if fewer projects areadr available as under GPL, it is because they are adopting licenses that have fewer restrictions.

I don't personally see the advantage of having a more difficult to enforce license. Either your license accurately matches your intent in a court of law and should be enforced rigorously, or it doesn't match your intent and you should use a different license.

Selectively enforced licenses seems like selectively enforced laws: ripe for corruption.

> as adding third parties into this is going to be pretty unappealing for some developers

On the contrary: the GPL is meant to PROTECT developers from patent trolls and freeloaders who what to turn FOSS into unpaid labor.

It also protect users, and all developers are also users.

Nothing in the GPL does anything about freeloading; I'm using lots of GPL projects without contributing back funding, bug reports or patches, for eg glibc, GCC and so on.

The only thing the GPL does is give the same access copyright holders have to software to downstream users.

> The only thing the GPL does is give the same access copyright holders have to software to downstream users.

I think that's what GP meant by preventing freeloading. Anything you do with the source code to GPL software needs to itself be distributed freely. Ie, a company can't freeload off of your work to build and then sell a proprietary project.

Right, but they can freeload off your work and sell a GPL project (or even sell just setting up the project), distributing source to users, but those users not publishing or doing anything with the code and you not getting modifications back nor any kind of financial support.

No. I wrote "freeloaders who what to turn FOSS into unpaid labor".

Simply using or modifying for internal use is OK.

We cross the line into unpaid labor when I release an application or a game, and somebody changes the name, maybe makes minor improvements, then sells it and takes all the money, takes all the credit, and even competes against my own software.

That sounds like a description of what literally every Linux distro does. Take your code, potentially make a (minor) fork of it, sells access to it, sells support for it, maybe sells hosting for it (Amazon), takes all the money, maybe gives back patches or maybe not and competes with your own builds of the software.

I think that what you want (no competition from forks or downstream redistributors) would not comply with the Open Source Definition (or DFSG) nor the Free Software Definition.

https://opensource.org/osd https://www.gnu.org/philosophy/free-sw.html

Reply on news.ycombinator.com