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 proven to be prevented from being invoked according to the vagueness of the "Remote Network Interaction" clause. So if you never want megacorps or anyone who runs a business to ever use your code, choose AGPL.
> 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.
> So if you never want megacorps or anyone who runs a business to ever use your code, choose AGPL.
Not "anyone who runs a business" but "any business that uses your software to provide a proprietary network service".
That is the whole point of the AGPL!
Google's reasoning in your link is pretty clear that the problem is that they are a provider of network services. Most non tech businesses wold be completely unaffected by these issues and have no reason to care.
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?"
Funny Grafana added "as code" after Perses did it, look like small players can impact big players and they can be useful to the ecosystem :)
I do not understand why you say it's a worse licence?
The second link is from like 2022, and I remember having code checked into git for dashboard in 2021 or so.
> I do not understand why you say it's a worse licence?
Apache license is inferior to the AGPL that Grafana is using. If the project is any good it's just a matter of time before Amazon or some other big company starts selling a fork of the codebase and draining development resources, as it happened with Redis, ElasticSearch and other companies.
That is the only way for anyone that would like to make a living out of open source.
Other than that, younger generations are getting why the old models from shareware and trial demos, source available have made a comeback under apparently new models.
Plenty of big businesses will use AGPL software ... because you can dual license. AGPL lets you claim "open source" while still being able to pretty universally charge for the software's use via your commercial licensing option.
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 piece of string on top of an aileron and on the other you smack it with a hammer to bend it (that must be the Spitfire) and then you test it out and keep fettling until the job is done.
Well, that's roll sorted out, I'm not sure what trim for the other two axes (pitch, yaw) involves. Probably knicker elastic.
> 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).
We didn't have time to polish ours like that what with the enemy shooting at them all the time. Oh and most of them were made of wood and wishes! The Hurricane was a bit of a crossover from WWI to WW2, yet rather a lot of Brits and Poles (int al) flew them against the Luftwaffe, who had rather more modern ME109s etc. It must have been a bit of a pain to see your enemy deploy a cannon when you only have a .303.
There is absolutely no doubt that if the US hadn't rocked up, we would have been ... well I'm not sure what Europe might mean nowadays if things had been different.
Possibly, our most lethal aircraft was the Mosquito. It was made of wood and twin enginned. So it was light and very, very fast and could pack a real punch - a quad cannon or lots of machine guns in the nose and carry bombs too. Parts were made in furniture factories and garden sheds - it was totally mad and rather hard to target manufacturing.
I think that the Nazi regime gave two kills for downing a Mosquito because it was considered a bit of a handful.
it'll be alright as long as you're not receiving the trim updates as part of a search query using parse_str, otherwise, you might be susceptible to script kiddies.
It seems like the only clauses being removed are those that protect PHP and Zend trademarks. Other than that, it's just unifying the two projects under a single license.
--
Basically, these two clauses (first from PHP, second from Zend) are removed:
The name “PHP” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net.
The names “Zend” and “Zend Engine” must not be used to endorse or promote products derived from this software without prior permission from Zend Technologies Ltd. For written permission, please contact license@zend.com.
And replaced with:
Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
--
Then the following three terms (4-6) are removed from PHP:
4. Products derived from this software may not be called “PHP”, nor may “PHP” appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo”
5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes PHP software, freely available from http://www.php.net/software/”.
--
And the following three terms (4-6) are removed from Zend:
4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.
5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes the Zend Engine, freely available at http://www.zend.com"
6. All advertising materials mentioning features or use of this software must display the following acknowledgment: "The Zend Engine is freely available at http://www.zend.com"
This is exactly the reason that "Windows Subsystem for Linux" never made sense: the correct preposition would've been "including". Other suggestions: the verb phrase "consisting of"; the adverb "to wit" ("Windows Subsystem, to wit: Linux" has a nice ring to it); whatever part of speech "which is" is.
NB: This was added "later" that is why tons of projects were grandfathered in, because they were already called phpMyAdmin, phpMyFAQ, etc. (IIRC at least)
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, 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 PHP Group can do anything they want since they can release a new version of the license without contributor approval because of the "or later" clause.
I assume this is the reason they're characterising this as "PHP License V4 will have identical wording to BSD-3" rather than "We will switch license to BSD-3".
It amounts to the same thing, but the former framing means they're covered by the "or later".
> 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 because Stallman does not like their licensing.
> 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.
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.
I do recognise and respect his past work. But he's come to a point where he'd rather hinder the progress of free software than help it. That's not extremist, that's short-sighted and spiteful.
That, and the uh, "it's not rape if..." comments. I wouldn't want anything to do with this guy following that, just no.
> I also do not understand why anyone would drop the GPL because Stallman does not like their licensing.
Because he can be so obnoxious that people want to sever all ties with him and anything that has to do with him so that they never ever have to talk to him ever again in any capacity.
> Richard Stallman, the author of the GPL and quite an interesting individual lived at 5405 DEC square, he lived up on the sixth floor I think? Had an office up there; he did not have an apartment. And we knew him extremely well. He was a challenging individual to get along with. He would regularly come down to our offices and ask us, or kind of rail at us, for not using the GPL.
> This did not make a positive impression on me; this was my first interaction with Richard directly and I remember thinking at the time, “this guy is a little, you know, I’m not interesting in talking to him because he’s so challenging to work with.”
> And so, we should have listened to him then but we did not because, we know him too well, I guess, and met him as well.
There are many anecdotes like this over the years from many people, often people who in broad lines actually agree with Stallman.
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 enabled me to accomplish in that era.
> 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.
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.
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*`.
"'Conspicuous', with reference to a term, means so written, displayed, or presented that, based on the totality of the circumstances, a reasonable person against which it is to operate ought to have noticed it."
What are some of the ways you can tell if a term in a legal document is conspicuous? One of the ways mentioned in the UCC:
"a heading in capitals equal to or greater in size than the surrounding text"
So apparently the thinking is that if you make everything in the license all caps, it is all a conspicuous term, and thus a court will be convinced that a reasonable person ought to have noticed it.
The fact that the OSI didn't approve of the PHP License until pressured shows the wayward nature of their "stewardship" of "open source". As does their wonky and rights-eroding definition of "open source AI".
> The proposed license does not reduce any user rights or add any new restrictions on the use of code previously licensed under the PHP License, version 3.01,
Yes, it does. Modified BSD Clause 3 (copied below).
> 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
I know I'm being pedantic, but this is a narrowing of rights.
> Do We Require Permission From All Contributors? The short answer is, “No.”
I think that they can get away with this change since the original license doesn't preclude a narrowing of rights on derivatives.
It would be interesting if a contributor protested the additional burden and headache of having to deal with a torrent of snail mail asking for endorsement.
> I know I'm being pedantic, but this is a narrowing of rights.
No, it's not. Explicitly stating which rights you don't grant is not more narrow than implicitly not granting them, it's just clearer. Copyrights and trademark rights are different.
> is not more narrow than implicitly not granting them
Implicitly not granted? You mean, not mentioned at all? Imagine a world in which the modified BSD license exists in a vacuum. This license restricts how a product can be endorsed/promoted as per the clause. Granted, additional restrictions are removed in regard to "PHP" et al.
I don't know what you are talking about. Many licenses don't mention trademark issues at all, that doesn't mean they grant you the right to use the trademark.
"Not mentioned at all" does not mean you can do it. Licenses do not restrict, they permit, from a default of "you may not use my stuff".
The license text could also say "you may not break into my house". That would not make it a "narrowing of rights", and that doesn't mean other licenses implicitly grant you the right to break into the software author's house if you use their software.
I think the point the previous poster is trying to make is that:
> This license restricts how a product can be endorsed/promoted as per the clause.
...is technically not true for licenses, because they do not _restrict_ usage, rather they _permit_ usage. The usage is, by default, always restricted by automatic copyright and authorship laws, so any license (including the GPL) is not a restriction but a permission, since it has _granted_ permissions that were implicitly not there.
So if you change your license in a way where it appears more restrictions have been added, but those restrictions were already implicit because they were not even covered or taken into account in your original license, no new restrictions were added, your "grant" was just made easier to understand.
This clause doesn't allow people to write you, it prevents them from doing stuff without written permission.
And that's the default. Trademark laws and laws that protect individuals already work like this. I'm not even sure this clause is strictly necessary in the BSD license.
I assume they've carefully evaluated this change with a lawyer.
The way the clause was in there gives them more rights than a trademark; if their term becomes genericized they could still enforce it on people distributing the code. And other uses of the mark that could normally be allowed could be restricted.
I'm not a lawyer and I haven't studied the relevant laws, but I'm quite skeptical that trademark and publicity rights align with a broad prohibition on using the names of copyright holders to "endorse or promote" without "specific prior written permission". That phrasing could be interpreted to prohibit, for example, giving an interview about your derived work, and making the factual statement: "It's based on software called Foo, which was written by a guy named John Smith." No endorsement is implied, but you are using John Smith's name in an interview which is perhaps intended for promotional purposes.
Even if this restriction does align with US law, I will be flabbergasted if it aligns with the laws of every other country as well.
I'm quite convinced this clause says you cannot make it seem like the original authors endorse your derivative product, the BSD license is so widespread I would assume if your interpretation was correct we would have seen many issues by now, but IANAL too. I do hope you are wrong :-)
I mean, PHP license clause 3 & 4 seems to say this already:
3. The name "PHP" must not be used to endorse or promote products
derived from this software without prior written permission. For
written permission, please contact group@php.net.
4. Products derived from this software may not be called "PHP", nor
may "PHP" appear in their name, without prior written permission
from group@php.net. You may indicate that your software works in
conjunction with PHP by saying "Foo for PHP" instead of calling
it "PHP Foo" or "phpfoo"
(I've edited my comment slightly, but not in a way that changes the context of your response.)
PHP License Clause 3 & 4 are about protecting PHP branding. Modified BSD Clause 3 is about using the software author's name or likeness as endorsement. For example, it limits putting antirez's face and name on our managed Redis product without obtaining his permission.
IANAL, but the new license applies only to new PHP versions, changing it backwards would require approvals.
If you don't contribute under new license, you should be not affected.
The new license covers and applies to all the code, even code that was written before the change.
You can totally change the license of already released code, if the change is compatible with the precious license or if you have permission from all the contributors whose code is still present in significant amount. (However, you can't prevent people from using the released code under the former license)
So what do you mean by "you can totally change the license of already released code"? If the license only applies to version 9 and forward, then in any practical sense the license has not been changed for "released code".
I was generic and not talking about PHP specifically. In the case of PHP, this isn't happening, so if you are only concerned with PHP, you can ignore these theoretical considerations (however, because of the "or later" clause of the PHP license, you'll actually be able to use older versions of PHP under the new license).
That said, my point was: as the author, if you have previously released software S version V under license L1, nothing prevents you from releasing software S version V again under a new license L2 provided all the contributors of significant portions of software S version 1 agree or L1 happens to allow this additional license (because it's permissive, or because it has a "or later" clause or some other means).
Of course, re-release under a new license or not, software S version V can be used under license L1 "forever" and users can choose to ignore the L2 release completely. You cannot remove license L1, you can only offer an additional possibility (using software S version V under the new license, which you didn't allow before the re-release unless the relicensing was allowed by L1).
I've not seen this done, but I can imagine this being useful if someone needs specifically software S version V under the new license. Usually, people can just use newer versions under the new license though.
I admit my comment was terse (and a further edition probably removed important phrasing), I hope this one makes things clearer.
I believe only the rights holders need to approve of the retroactive changes, and so they really only need Perforce (presumably the rights holder as the current owner of the former Zend Technologies) to agree.
Very pedantically, because PHP doesn't require copyright assignment, it would be (almost certainly) impossible to retroactively change the licence on older versions.
However, since the PHP and Zend licences both permit the user to use PHP under the terms of whatever licence version was applied to that PHP version or any later version, the point is essentially moot, since a user can choose to use the new version of the PHP/Zend licence once published, which will give them the same rights.
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 proven to be prevented from being invoked according to the vagueness of the "Remote Network Interaction" clause. So if you never want megacorps or anyone who runs a business to ever use your code, choose AGPL.
1. https://opensource.google/documentation/reference/using/agpl...
> 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.
but you don't care enough to let your users choose to pay some other business to host it for them
The AGPL allows that.
> So if you never want megacorps or anyone who runs a business to ever use your code, choose AGPL.
Not "anyone who runs a business" but "any business that uses your software to provide a proprietary network service".
That is the whole point of the AGPL!
Google's reasoning in your link is pretty clear that the problem is that they are a provider of network services. Most non tech businesses wold be completely unaffected by these issues and have no reason to care.
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?"
In other words, if you're an open source startup and want to avoid being AWS'd, choose dual AGPL + commercial (with IP transfer CLAs).
Which is what Grafana essentially did, and it's going great (as a company and as a suite of products, their stuff is incredibly good).
but also kind of sucks for users since you can't reuse the graph widgets elsewhere... which is why https://perses.dev/ is now a thing
looks like a poorer version grafana, with a worse license?
Also grafana has "observability as code" since release 12: https://grafana.com/docs/grafana/latest/whatsnew/whats-new-i...
And it seems there used to be something similar from earlier as well: https://grafana.com/blog/2022/12/06/a-complete-guide-to-mana...
Funny Grafana added "as code" after Perses did it, look like small players can impact big players and they can be useful to the ecosystem :) I do not understand why you say it's a worse licence?
The second link is from like 2022, and I remember having code checked into git for dashboard in 2021 or so.
> I do not understand why you say it's a worse licence?
Apache license is inferior to the AGPL that Grafana is using. If the project is any good it's just a matter of time before Amazon or some other big company starts selling a fork of the codebase and draining development resources, as it happened with Redis, ElasticSearch and other companies.
That is the only way for anyone that would like to make a living out of open source.
Other than that, younger generations are getting why the old models from shareware and trial demos, source available have made a comeback under apparently new models.
Plenty of big businesses will use AGPL software ... because you can dual license. AGPL lets you claim "open source" while still being able to pretty universally charge for the software's use via your commercial licensing option.
Meta _does_ have some PHP apps. They have a collection of sites running WordPress.
That's not running on the main site. 99.99999% of it is Hack.
I thought it's using Go nowadays. Weren't so many packages rewritten in Go?
Beautifull, everything regarding PHP licensing and its history in one place, no marketing or AI generated bs in sight - love it ;)
AI generated bs doesn’t add anything new. In fact bs has always existed! So there is nothing to see :)
Dang if someone wants to become an expert in software licensing and modifications, this is a page to read.
It's sold to us as non-news, which is good. No change for contributors, no change for end users, rights wise.
Last time I heard about a non-news update that required no changes or recertification, we learned about 787MAX and MCAS.
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 piece of string on top of an aileron and on the other you smack it with a hammer to bend it (that must be the Spitfire) and then you test it out and keep fettling until the job is done.
Well, that's roll sorted out, I'm not sure what trim for the other two axes (pitch, yaw) involves. Probably knicker elastic.
> 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).
Nothing special about that, here is the factory set trim tab on the p-47.
https://www.youtube.com/watch?v=VxWKOHPPNlM&t=298
Beautiful aircraft there, very shiny.
We didn't have time to polish ours like that what with the enemy shooting at them all the time. Oh and most of them were made of wood and wishes! The Hurricane was a bit of a crossover from WWI to WW2, yet rather a lot of Brits and Poles (int al) flew them against the Luftwaffe, who had rather more modern ME109s etc. It must have been a bit of a pain to see your enemy deploy a cannon when you only have a .303.
There is absolutely no doubt that if the US hadn't rocked up, we would have been ... well I'm not sure what Europe might mean nowadays if things had been different.
Possibly, our most lethal aircraft was the Mosquito. It was made of wood and twin enginned. So it was light and very, very fast and could pack a real punch - a quad cannon or lots of machine guns in the nose and carry bombs too. Parts were made in furniture factories and garden sheds - it was totally mad and rather hard to target manufacturing.
I think that the Nazi regime gave two kills for downing a Mosquito because it was considered a bit of a handful.
it'll be alright as long as you're not receiving the trim updates as part of a search query using parse_str, otherwise, you might be susceptible to script kiddies.
Don't worry, that was written with JavaScript.
Nawh, it's really written in JScript with ActiveX plugins served over http://.
737* :)
It seems like the only clauses being removed are those that protect PHP and Zend trademarks. Other than that, it's just unifying the two projects under a single license.
--
Basically, these two clauses (first from PHP, second from Zend) are removed:
The name “PHP” must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net.
The names “Zend” and “Zend Engine” must not be used to endorse or promote products derived from this software without prior permission from Zend Technologies Ltd. For written permission, please contact license@zend.com.
And replaced with:
Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
--
Then the following three terms (4-6) are removed from PHP:
4. Products derived from this software may not be called “PHP”, nor may “PHP” appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo”
5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.
6. Redistributions of any form whatsoever must retain the following acknowledgment: “This product includes PHP software, freely available from http://www.php.net/software/”.
--
And the following three terms (4-6) are removed from Zend:
4. Zend Technologies Ltd. may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by Zend Technologies Ltd. No one other than Zend Technologies Ltd. has the right to modify the terms applicable to covered code created under this License.
5. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes the Zend Engine, freely available at http://www.zend.com"
6. All advertising materials mentioning features or use of this software must display the following acknowledgment: "The Zend Engine is freely available at http://www.zend.com"
You may indicate that your software works in conjunction with PHP by saying “Foo for PHP” instead of calling it “PHP Foo” or “phpfoo”
Now "Windows Subsystem for Linux" makes even less sense than it already did.
This is exactly the reason that "Windows Subsystem for Linux" never made sense: the correct preposition would've been "including". Other suggestions: the verb phrase "consisting of"; the adverb "to wit" ("Windows Subsystem, to wit: Linux" has a nice ring to it); whatever part of speech "which is" is.
NB: This was added "later" that is why tons of projects were grandfathered in, because they were already called phpMyAdmin, phpMyFAQ, etc. (IIRC at least)
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, 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"
Haha, such classic Stallman.
The PHP Group can do anything they want since they can release a new version of the license without contributor approval because of the "or later" clause.
I assume this is the reason they're characterising this as "PHP License V4 will have identical wording to BSD-3" rather than "We will switch license to BSD-3".
It amounts to the same thing, but the former framing means they're covered by the "or later".
That is not what the article says. It doesn't mention "or later" at all?
And reading the full license text, I don't see "or later" there either?
The wording to search for is, "You may also choose to use such covered code under the terms of any subsequent version of the license".
Ah cheers. Don't understand why that's not mentioned at all in the length section on changing the license?
> 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 because Stallman does not like their licensing.
> 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.
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.
I do recognise and respect his past work. But he's come to a point where he'd rather hinder the progress of free software than help it. That's not extremist, that's short-sighted and spiteful.
That, and the uh, "it's not rape if..." comments. I wouldn't want anything to do with this guy following that, just no.
> Stallman is said to be notoriously difficult to work with, and IMHO he's quite an extremist.
You do not have to work with him to use the GPL. You can use the GPL and ignore him completely. Its just a license.
> I also do not understand why anyone would drop the GPL because Stallman does not like their licensing.
Because he can be so obnoxious that people want to sever all ties with him and anything that has to do with him so that they never ever have to talk to him ever again in any capacity.
This goes back a long time. For example Keith Packard on why X11 isn't GPL (from https://youtu.be/cj02_UeUnGQ?t=1705):
> Richard Stallman, the author of the GPL and quite an interesting individual lived at 5405 DEC square, he lived up on the sixth floor I think? Had an office up there; he did not have an apartment. And we knew him extremely well. He was a challenging individual to get along with. He would regularly come down to our offices and ask us, or kind of rail at us, for not using the GPL.
> This did not make a positive impression on me; this was my first interaction with Richard directly and I remember thinking at the time, “this guy is a little, you know, I’m not interesting in talking to him because he’s so challenging to work with.”
> And so, we should have listened to him then but we did not because, we know him too well, I guess, and met him as well.
There are many anecdotes like this over the years from many people, often people who in broad lines actually agree with Stallman.
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 enabled me to accomplish in that era.
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.
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?"
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*`.
As colejohnson66 noted. I would use typedef table, typedef page, etc. A void* is a pointer to the void. A page table is a table of pages.
The background:
https://wiki.php.net/rfc/php_license_update#background
Can someone that understands the change please ELI5 for me? Is this changing the license for all of php?
What do you mean by all of php? This changes the license of the language. That is the interpreter, runtime, and standard library.
Why do people write licenses with whole paragraphs WRITTEN IN ALL CAPS LIKE THIS?
From the Uniform Commercial Code:
"'Conspicuous', with reference to a term, means so written, displayed, or presented that, based on the totality of the circumstances, a reasonable person against which it is to operate ought to have noticed it."
What are some of the ways you can tell if a term in a legal document is conspicuous? One of the ways mentioned in the UCC:
"a heading in capitals equal to or greater in size than the surrounding text"
So apparently the thinking is that if you make everything in the license all caps, it is all a conspicuous term, and thus a court will be convinced that a reasonable person ought to have noticed it.
US law says that warranty/liability disclaimers need to be "conspicuous". Making it ALL CAPS is the easiest way to do that in plain text.
Prevents any dispute over the significance of a certain word or phrase being capitalized vs not.
Can't help but wonder why not the much simpler MIT.
Is https://opensource.org/license/mit really much simpler than https://opensource.org/license/BSD-3-clause to make a meaningful difference to you?
Yes.
The main issue with BSD is its proliferation of versions, incompatible with each other.
If you're comparing a specific version straight with MIT, this is not evident.
[flagged]
I find these sorts of legal changes fascinating.
The fact that the OSI didn't approve of the PHP License until pressured shows the wayward nature of their "stewardship" of "open source". As does their wonky and rights-eroding definition of "open source AI".
> The proposed license does not reduce any user rights or add any new restrictions on the use of code previously licensed under the PHP License, version 3.01,
Yes, it does. Modified BSD Clause 3 (copied below).
> 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
I know I'm being pedantic, but this is a narrowing of rights.
> Do We Require Permission From All Contributors? The short answer is, “No.”
I think that they can get away with this change since the original license doesn't preclude a narrowing of rights on derivatives.
It would be interesting if a contributor protested the additional burden and headache of having to deal with a torrent of snail mail asking for endorsement.
> I know I'm being pedantic, but this is a narrowing of rights.
No, it's not. Explicitly stating which rights you don't grant is not more narrow than implicitly not granting them, it's just clearer. Copyrights and trademark rights are different.
> is not more narrow than implicitly not granting them
Implicitly not granted? You mean, not mentioned at all? Imagine a world in which the modified BSD license exists in a vacuum. This license restricts how a product can be endorsed/promoted as per the clause. Granted, additional restrictions are removed in regard to "PHP" et al.
The shape is different, not just clearer.
I don't know what you are talking about. Many licenses don't mention trademark issues at all, that doesn't mean they grant you the right to use the trademark.
"Not mentioned at all" does not mean you can do it. Licenses do not restrict, they permit, from a default of "you may not use my stuff".
The license text could also say "you may not break into my house". That would not make it a "narrowing of rights", and that doesn't mean other licenses implicitly grant you the right to break into the software author's house if you use their software.
I think the point the previous poster is trying to make is that:
> This license restricts how a product can be endorsed/promoted as per the clause.
...is technically not true for licenses, because they do not _restrict_ usage, rather they _permit_ usage. The usage is, by default, always restricted by automatic copyright and authorship laws, so any license (including the GPL) is not a restriction but a permission, since it has _granted_ permissions that were implicitly not there.
So if you change your license in a way where it appears more restrictions have been added, but those restrictions were already implicit because they were not even covered or taken into account in your original license, no new restrictions were added, your "grant" was just made easier to understand.
This clause doesn't allow people to write you, it prevents them from doing stuff without written permission.
And that's the default. Trademark laws and laws that protect individuals already work like this. I'm not even sure this clause is strictly necessary in the BSD license.
I assume they've carefully evaluated this change with a lawyer.
The way the clause was in there gives them more rights than a trademark; if their term becomes genericized they could still enforce it on people distributing the code. And other uses of the mark that could normally be allowed could be restricted.
I'm not a lawyer and I haven't studied the relevant laws, but I'm quite skeptical that trademark and publicity rights align with a broad prohibition on using the names of copyright holders to "endorse or promote" without "specific prior written permission". That phrasing could be interpreted to prohibit, for example, giving an interview about your derived work, and making the factual statement: "It's based on software called Foo, which was written by a guy named John Smith." No endorsement is implied, but you are using John Smith's name in an interview which is perhaps intended for promotional purposes.
Even if this restriction does align with US law, I will be flabbergasted if it aligns with the laws of every other country as well.
I'm quite convinced this clause says you cannot make it seem like the original authors endorse your derivative product, the BSD license is so widespread I would assume if your interpretation was correct we would have seen many issues by now, but IANAL too. I do hope you are wrong :-)
I mean, PHP license clause 3 & 4 seems to say this already:
Edit: there may be more context than I thought(I've edited my comment slightly, but not in a way that changes the context of your response.)
PHP License Clause 3 & 4 are about protecting PHP branding. Modified BSD Clause 3 is about using the software author's name or likeness as endorsement. For example, it limits putting antirez's face and name on our managed Redis product without obtaining his permission.
I don't think it does because trademark laws and individual rights already work like this by default.
Ah interesting
IANAL, but the new license applies only to new PHP versions, changing it backwards would require approvals. If you don't contribute under new license, you should be not affected.
The new license covers and applies to all the code, even code that was written before the change.
You can totally change the license of already released code, if the change is compatible with the precious license or if you have permission from all the contributors whose code is still present in significant amount. (However, you can't prevent people from using the released code under the former license)
Previously released versions are still available under the terms under which they were originally released.
Yep, that's my "however". For PHP, the new license will apply to version 9 and later if the proposal is adopted.
So what do you mean by "you can totally change the license of already released code"? If the license only applies to version 9 and forward, then in any practical sense the license has not been changed for "released code".
I was generic and not talking about PHP specifically. In the case of PHP, this isn't happening, so if you are only concerned with PHP, you can ignore these theoretical considerations (however, because of the "or later" clause of the PHP license, you'll actually be able to use older versions of PHP under the new license).
That said, my point was: as the author, if you have previously released software S version V under license L1, nothing prevents you from releasing software S version V again under a new license L2 provided all the contributors of significant portions of software S version 1 agree or L1 happens to allow this additional license (because it's permissive, or because it has a "or later" clause or some other means).
Of course, re-release under a new license or not, software S version V can be used under license L1 "forever" and users can choose to ignore the L2 release completely. You cannot remove license L1, you can only offer an additional possibility (using software S version V under the new license, which you didn't allow before the re-release unless the relicensing was allowed by L1).
I've not seen this done, but I can imagine this being useful if someone needs specifically software S version V under the new license. Usually, people can just use newer versions under the new license though.
I admit my comment was terse (and a further edition probably removed important phrasing), I hope this one makes things clearer.
I believe only the rights holders need to approve of the retroactive changes, and so they really only need Perforce (presumably the rights holder as the current owner of the former Zend Technologies) to agree.
Very pedantically, because PHP doesn't require copyright assignment, it would be (almost certainly) impossible to retroactively change the licence on older versions.
However, since the PHP and Zend licences both permit the user to use PHP under the terms of whatever licence version was applied to that PHP version or any later version, the point is essentially moot, since a user can choose to use the new version of the PHP/Zend licence once published, which will give them the same rights.