Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we picked AGPL

blog.paradedb.com

Post reply on HN
Print view View original

301–310 of 312 posts

Re: Why we picked AGPL

#301

Post by lmm »

teddyh wrote: post #300
lmm wrote: post #289

Earlier quoted context omitted.

> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers. And in the case of their own projects , the projects where the FSF is the project/the maintainers, what is it they do? They require copyright assignment.

What are you talking about? The FSF is not the direct maintainer for any projects, as far as I know. The project maintainers are people.

Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).

Re: Why we picked AGPL

#302

Post by awesomeMilou »

camgunz wrote: post #294
awesomeMilou wrote: post #259

Earlier quoted context omitted.

That's the GNU project's interpretation of the license. I don't see how a court couldn't reach a different agreement on what the often discussed "derivative works" section means. The FAQ also has interesting takes, where depending on the jurisdiction you're in, I'm sure such views would differ: Q: In an object-oriented language such as Java, if I use a class that is GPLed without modifying, and subclass it, in what w…

I know a lot of this stuff is legally pretty new (though AGPLv3 is almost 17 years old now) and there's not a huge body of case law around it. But--and I'm earnestly asking here--is there case law where courts reach in and modify licenses separate from the authors' explicit intent? It's hard for me to imagine a court doing that, especially with all the reliance interests involved (I use AGPLv3 with the understanding…

> is there case law where courts reach in and modify licenses separate from the authors' explicit intent

What are you on about? The explicit purpose of a license is that it's users do not have to worry about anyone else's "explicit intent". A license needs to be unambigious about it's terms, else it's just not a good license, hence see the discussion in this thread about the meaning of derivative works.

It may very well be that the FSF/RMS/GNU Project had some intent on it's use when creating the GPL/AGPL v3, but a court in another jurisdiction will not care. I have no idea how to get a hold of the FSF when I'm being sued for license violations in europe and even if so, I doubt a court would care about the FSF's interpretation, given that they're likely not a party to the proceedings.

I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.

> No, again the difference is incorporation. In order to subclass something you have to incorporate it into your code.

You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.

Re: Why we picked AGPL

#303

Post by camgunz »

awesomeMilou wrote: post #302
camgunz wrote: post #294

Earlier quoted context omitted.

I know a lot of this stuff is legally pretty new (though AGPLv3 is almost 17 years old now) and there's not a huge body of case law around it. But--and I'm earnestly asking here--is there case law where courts reach in and modify licenses separate from the authors' explicit intent? It's hard for me to imagine a court doing that, especially with all the reliance interests involved (I use AGPLv3 with the understanding…

> is there case law where courts reach in and modify licenses separate from the authors' explicit intent What are you on about? The explicit purpose of a license is that it's users do not have to worry about anyone else's "explicit intent". A license needs to be unambigious about it's terms, else it's just not a good license, hence see the discussion in this thread about the meaning of derivative works. It may very w…

> What are you on about? The explicit purpose of a license is that it's users do not have to worry about anyone else's "explicit intent". A license needs to be unambigious about it's terms, else it's just not a good license, hence see the discussion in this thread about the meaning of derivative works.

Even the most carefully written license has ambiguity, and that's for two reasons. First, we want to cover situations without exhaustively enumerating and describing them in great detail. Statutes and the Constitution run into this all the time, but no one's like "don't start a business in the US, their Constitution is ambiguous and courts have to clarify and interpret it all the time" because courts (except for this one, I'll admit) do things like take reliance interests into account when adjudicating cases. It works well enough in contract law that we've built the most advanced economy in history, so I wouldn't poo-poo it.

Second, and I'll echo Dijkstra here [0] our languages aren't precise. They're bad at the thing you want them to do. Your argument argues against all contracts and licenses everywhere, even laws themselves.

Finally, (A)GPLv3 don't refer to derivative works. That's a GPLv2 thing.

> I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.

Again, happy to read any case law you can find on this.

> You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.

I'm starting to believe people here don't know what linking and incorporate mean. Linking is using a linker--like ld--to build an executable or library. It's not some abstract idea of linkage. Incorporate means pulling the source code into your own. It's not some abstract idea of building a larger system. You don't pull the source code to Minio into your code to use its API.

0: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

Re: Why we picked AGPL

#304

Post by dwaite »

k__ wrote: post #112
zelphirkalt wrote: post #44

Earlier quoted context omitted.

Where there is a will, there is a way. Big corporations could use the license and stick to its terms, but no, they don't want to. Better in their view to just take take take and never give. What they don't see however, and what is on no ones quarterly number sheet, is all the talent they don't attract.

Which is funny, as enterprise customers have no issue in buying closed source software, but the moment they see a GPL, they lose their mind.

The most significant reason there is that the license must be taken under the strictest interpretation without a more specific business level agreement between the two.

Apple for instance forbade GPLv3 because the anti-Novell clauses, which could be interpreted as "with a lost patent lawsuit, you can't merely license the technology but must secure and license the technology for all parties who may use or create a derivative of the original GPLv3 work". If you thought a court would agree with this interpretation, you'd be crazy to touch the software.

AGPL takes the strictest interpretation of a derivative work that even content created using the AGPLed software internally for an administrative function (such as storing your business data in a database) is a derivative work, and that the output of your software thus has restrictions under it by AGPL. Before AGPL, the only times we would see statements as such was to assure businesses that such an interpretation would not be taken - standard C libraries, compiled output, and java code with classpath exceptions are three popular examples.

I find the AGPL to run counter to the original purpose of the GPL, which I understand to be to protect the communities developing software from having their work superseded by commercial entities not giving back. The lack of examples of AGPL projects where contributors are not required to execute some form of CLA illustrates how it is often not being embraced to foster communities, but to protect against them and even exploit them.

Re: Why we picked AGPL

#305

Post by teddyh »

lmm wrote: post #301
teddyh wrote: post #300

Earlier quoted context omitted.

What are you talking about? The FSF is not the direct maintainer for any projects, as far as I know. The project maintainers are people.

Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting re…

And the named maintainer has the right to not require CLA:s for their project. The FSF does not require the maintainer to require CLA:s.

Re: Why we picked AGPL

#306

Post by philippemnoel »

matheusmoreira wrote: post #169
keskival wrote: post #12

The point of an OSS license in these kinds of situations is pretty simple: They need to pick a license which is salty enough so that big corporations cannot use it, but have to buy a special license from the authors. Meanwhile they can support and benefit from the open source community without bureaucracy, and get a maximal userbase to create content on the web about this stack, and have a maximal number of people wh…

Absolutely. As the copyright owners, the authors of the software can always sell permissions to corporations. This allows software to become free. Stallman himself has suggested this to corporations: https://www.gnu.org/philosophy/selling-exceptions.html People have pointed out to me that the above is not quite the same as what happens today with people building proprietary SaaS platforms. So I emailed Stallman to as…

That's so cool that he responded! Thank you for sharing

Re: Why we picked AGPL

#307

Post by kazinator »

sneak wrote: post #244
kazinator wrote: post #4

> The AGPL license permits free use, modification, and distribution of software, provided that distributed, derivative works of the software are released under the same license. Here is the rub: free software permits unconditional use. The GPL without the A, or MIT or BSD licenses are not EULAs; they place restrictions or conditions on redistribution, not on use. (With regard to use, they have only certain liability…

Thank you for pointing this out. It is logically obvious that the AGPL is a nonfree license. I have been saying this for some time. It is a very unpopular thing to say.

And others.

https://news.ycombinator.com/item?id=24861043

Re: Why we picked AGPL

#308

Post by codelion »

max-privatevoid wrote: post #288
codelion wrote: post #145

This resonated with us as well, we have also chosen AGPL as license for our open source project - https://github.com/patched-codes/patchwork

Please do not use the AGPL as a marketing point when you have a CLA.

What's wrong in having a CLA? It allows you to re-license your project in future.

Re: Why we picked AGPL

#309

Post by max-privatevoid »

codelion wrote: post #308
max-privatevoid wrote: post #288

Earlier quoted context omitted.

Please do not use the AGPL as a marketing point when you have a CLA.

What's wrong in having a CLA? It allows you to re-license your project in future.

Q: What's wrong in having a CLA? A: It allows you to re-license your project in future.

It gives the original author the right to relicense your contributions at a moment's notice, to a license you might not agree with. It effectively means that you cannot contribute to the project under fair terms.

A CLA is similar to a EULA in the sense that most people don't care about it and blindly click "Agree", and as such are unaware of the potential consequences. Look at what happened when HashiCorp relicensed its projects. People were outraged. They agreed to the CLA, so they must have known that this could happen. But did they really take the time to understand what they were signing?

As a contributor, you should never agree to a CLA. As the original author, requiring your contributors to sign a CLA sets an extremely bad precedent.

Re: Why we picked AGPL

#310

Post by codelion »

max-privatevoid wrote: post #309
codelion wrote: post #308

Earlier quoted context omitted.

What's wrong in having a CLA? It allows you to re-license your project in future.

Q: What's wrong in having a CLA? A: It allows you to re-license your project in future. It gives the original author the right to relicense your contributions at a moment's notice, to a license you might not agree with. It effectively means that you cannot contribute to the project under fair terms. A CLA is similar to a EULA in the sense that most people don't care about it and blindly click "Agree", and as such are…

You have just listed the benefits of having a CLA. This post is about why projects should pick a license not how contributors should prioritise what they spend their time on. If you are trying to build something commercial and be open-source this is a good recommendation.
Post reply on HN