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

RFC: PHP license update

wiki.php.net

Post reply on HN
Print view View original

61–70 of 91 posts

Re: RFC: PHP license update

#61

Post by eadmund »

burnt-resistor wrote: post #39

FYI in case anyone were wondering: Meta uses Hack, not PHP. (Hack's packaging, documentation, and availability suck because there's no performance review "impact" to making things better that no one inside Meta sees. Plus, there's job security in knowledge hoarding.) Licensing: Meta and Google[1], and likely Microsoft, Apple, and most other megacorps explicitly forbid any use of AGPL software because it cannot be pro…

> So if you never want megacorps or anyone who runs a business to ever use your code, choose AGPL.

Plenty of businesses run AGPL software (e.g. Grafana, Mastodon or Mattermost). Fewer run AGPL software for external paying customers.

As a developer, I care about the freedom of my users; I don’t much care about the paranoia of a megacorp who wants to restrict the freedom of its customers.

Re: RFC: PHP license update

#62

Post by znpy »

winrid wrote: post #41
pdmccormick wrote: post #40

I remember studying the source code to the PHP Zend Engine 25 years ago, and seeing a triple C pointer for the first time (I think it was `zval***`?) I did a lot of PHP in the following years, including using PHP for a high school programming contest (but my submission was rejected because the PHP language and using it in a standalone CLI context in particular was unfamiliar to the staff). I appreciate what it enable…

That's hilarious considering I did my senior project in Perl.

> That's hilarious considering I did my senior project in Perl

Same. Wrote a web application using Catalyst and a client for mobile phones using J2ME.

Writing projects in obscure languages is the best way to avoid dumb professors/examiners ask you stupid questions about your codebase lol.

I remember reading the Wikipedia page of Perl the night before the oral exhibition, just to be sure and guess what... The examiner asked me about the difference between "Perl" (capitalized) and "perl" uncapitalized. Which was one of the first lines in the Wikipedia page.

The guy literally went fishing for stupid and pedantic questions to ask, on Wikipedia, the night before.

Re: RFC: PHP license update

#63

Post by rollcat »

graemep wrote: post #56
arp242 wrote: post #27

I suppose my concern with not getting permission from all contributors is that a bad faith contributor could make life hard. For those S signs with a stripe, or just out of spite. For better or worse, in systems like the US anyone can sue anyone for any reason and everyone is expected to carry their own costs, which is why everyone is so paranoid and covers their ass with three tanks worth of metal. Aside: "Meanwhile…

> Meanwhile, Richard Stallman, author of the GPL and founder of the FSF, had significant disagreements with the PHP project over their use of the GPL, so the PHP project discontinued the dual-licensing approach, removing the GPL license as an option The main link that cites is primarily about the MySQL license change to GPL and the impact on PHP licensing of tha. I also do not understand why anyone would drop the GPL…

> I also do not understand why anyone would drop the GPL because Stallman does not like their licensing.

Stallman is said to be notoriously difficult to work with, and IMHO he's quite an extremist.

He tried to veto emoji support in Emacs, because at the time it's only been supported on macOS. The reasonable recourse would've been add emoji support on the free platforms, but he seemingly can't see that far. So he's been ousted from the project.

In situations like this, I honestly would prefer to shut him off as well. I have huge respect for his past work, but at this point he's doing more harm than good.

Re: RFC: PHP license update

#64

Post by mschuster91 »

gerdesj wrote: post #26
michaelt wrote: post #24

Earlier quoted context omitted.

Let us hope nobody is writing their aircraft stabilizer trim control software in PHP.

Well that is rather obvious. I doubt PHP has RTOS type guarantees built in. Funny you should mention stabilizer control (I don't think that is an aeronautic term). I recently visited the Battle of Britain Memorial Flight hanger at RAF Conningsby. It turns out that the Hurricane and Spitfire had unusual (by today's standards but normal for the times) ways of applying trim to control surfaces. One of them - you glue a…

> Well that is rather obvious. I doubt PHP has RTOS type guarantees built in.

It's not multithreaded by default (as long as you're not running it in an environment like Apache), no async stuff going on, so the major roadblocks for real-time guarantees are already out of the picture.

The things I would be worried about is garbage collection and array handling. The former should be able to be configured (or in the worst case, rewritten) in a way that provides upper bounds on performance, people have already managed to do that for Java, the latter should be manageable by enforcing boundaries in the user code (e.g. disallow stuff like $foo[]='bar' that dynamically extends the length of an array).

Re: RFC: PHP license update

#65

Post by rollcat »

pdmccormick wrote: post #40

I remember studying the source code to the PHP Zend Engine 25 years ago, and seeing a triple C pointer for the first time (I think it was `zval***`?) I did a lot of PHP in the following years, including using PHP for a high school programming contest (but my submission was rejected because the PHP language and using it in a standalone CLI context in particular was unfamiliar to the staff). I appreciate what it enable…

I honestly can't think up a reasonable case for a triple "naked" pointer. Nevermind performance, it's a level of implicit indirection that you simply can't reason about.

Think of what a pointer is. Picture a struct; accessing a member is dereference + offset. It makes sense, you know there's a car, and the car has a steering wheel, and the steering wheel has a horn button. Simple. A struct with one field, that field has an offset of zero - it fits our "naked pointer" case 1:1, but is more readable. The compiler will do the rest.

As my dear friend often noted, "why simple?"

Re: RFC: PHP license update

#66

Post by throwaway9899p »

rollcat wrote: post #63
graemep wrote: post #56

Earlier quoted context omitted.

> Meanwhile, Richard Stallman, author of the GPL and founder of the FSF, had significant disagreements with the PHP project over their use of the GPL, so the PHP project discontinued the dual-licensing approach, removing the GPL license as an option The main link that cites is primarily about the MySQL license change to GPL and the impact on PHP licensing of tha. I also do not understand why anyone would drop the GPL…

> I also do not understand why anyone would drop the GPL because Stallman does not like their licensing. Stallman is said to be notoriously difficult to work with, and IMHO he's quite an extremist. He tried to veto emoji support in Emacs, because at the time it's only been supported on macOS. The reasonable recourse would've been add emoji support on the free platforms, but he seemingly can't see that far. So he's be…

To understand the value of his behaviour, you need to look at it from a broader strategic point of view, particularly the idea of setting the overtone window.

Without Stallman, the moderate would be cast as the extremist.

Stallman’s positive contribution to humanity cannot be overstated by any measure. Without him and the like of him, it is not improbable that the whole software industry would be like Apple ecosystem.

Re: RFC: PHP license update

#67

Post by DmitryOlshansky »

rollcat wrote: post #65
pdmccormick wrote: post #40

I remember studying the source code to the PHP Zend Engine 25 years ago, and seeing a triple C pointer for the first time (I think it was `zval***`?) I did a lot of PHP in the following years, including using PHP for a high school programming contest (but my submission was rejected because the PHP language and using it in a standalone CLI context in particular was unfamiliar to the staff). I appreciate what it enable…

I honestly can't think up a reasonable case for a triple "naked" pointer. Nevermind performance, it's a level of implicit indirection that you simply can't reason about. Think of what a pointer is. Picture a struct; accessing a member is dereference + offset. It makes sense, you know there's a car, and the car has a steering wheel, and the steering wheel has a horn button. Simple. A struct with one field, that field…

Think of page tables this is essentially a table of tables of tables. I also was meh on triple pointers until I found this use case.

Re: RFC: PHP license update

#68

Post by colejohnson66 »

DmitryOlshansky wrote: post #67
rollcat wrote: post #65

Earlier quoted context omitted.

I honestly can't think up a reasonable case for a triple "naked" pointer. Nevermind performance, it's a level of implicit indirection that you simply can't reason about. Think of what a pointer is. Picture a struct; accessing a member is dereference + offset. It makes sense, you know there's a car, and the car has a steering wheel, and the steering wheel has a horn button. Simple. A struct with one field, that field…

Think of page tables this is essentially a table of tables of tables. I also was meh on triple pointers until I found this use case.

Yes, but the third level isn't a "triple pointer", but a pointer to the next level. A page table level isn't just a pointer-to-a-pointer but carries information. So a three-level table doesn't have `void***` in the top level, but `PageTableLevel2*`.

Re: RFC: PHP license update

#69

Post by p_l »

rollcat wrote: post #60
p_l wrote: post #57

Earlier quoted context omitted.

The problem is that the language is vague enough and untested enough a lot of places, including non-technical ones, can be wary of being the test case.

What would it take to test it in court? Plenty of projects choose AGPL for whatever philosophical / moral reasons, perhaps even out of fear of competition. Is it just that it's "radioactive" enough to scare away anyone who'd consider it actually interesting?

I imagine it could take some minor contributor deciding they don't like what you do and taking extreme interpretation of AGPL including trying to insist everything that talks over network to it is derivative work, vs interpretation of yours (let's say you're not modifying an AGPL project at all, just running it vanilla, and it's part of some bigger offering, and your lawyers said it's not crucial enough for the bigger offering to be considered derivative)

As far as many people are concerned, AGPL is vague enough it would end up in court, so the question becomes "do I want to have this sword of Damocles of unnecessary complications and upsets?"

Post reply on HN