Live data from Hacker News

RFC: PHP license update

wiki.php.net

21–30 of 91 posts

Re: RFC: PHP license update

#21
post #16
post #10

Earlier quoted context omitted.

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.

Re: RFC: PHP license update

#22
post #18
post #11

Earlier quoted context omitted.

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.

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 softwar…

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 :-)

Re: RFC: PHP license update

#23
post #21
post #16

Earlier quoted context omitted.

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.

Re: RFC: PHP license update

#24
post #3

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.

Re: RFC: PHP license update

#25
post #3

Earlier quoted context omitted.

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.

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.

Re: RFC: PHP license update

#26
post #3

Earlier quoted context omitted.

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.

Re: RFC: PHP license update

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

Re: RFC: PHP license update

#28
post #19
post #5

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…

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

Re: RFC: PHP license update

#29
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…

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.

Re: RFC: PHP license update

#30
post #29
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…

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.

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?

Post reply on HN