I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.

This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects).

My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption?

Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that).

On Thursday, November 30, 2017 19:17:32 Jack Stouffer via Digitalmars-d wrote:
> I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.
>
> This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects).
>
> My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption?

IANAL, but I would have expected anything that was dual licensed would be able to automatically be moved to one of those licenses, removing the other. Otherwise, what was the point of dual licensing? Isn't the whole point of dual licensing to allow you to pick which you're going to use? Restricting the code to _both_ licenses simultaneously seems insane.

Andrei and/or Walter will have to respond on what the official stance is, since it's their decision, but in general, we've required that all code be Boost licensed, and if other licenses are required, that complicates things considerably. Certainly, as liberal as the BSD licenses are, I don't want to have to worry about suddenly having to deal with a BSD license because I linked against Phobos. Phobos needs to have no strings attached.

> Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that).

If it needs a BSD license on it, then it probably should never have been included in Phobos.

- Jonathan M Davis

On Thursday, 30 November 2017 at 19:17:32 UTC, Jack Stouffer wrote:
> I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.
>
> This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects).
>
> My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption?
>
> Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that).

I don't believe BSD or PSFL-licensed source can be dual-licensed by you, unless you have the copyright on all the code yourself, which appears to not be the case here.  BSD-like licensed code is often then simultaneously licensed as GPL by those who don't have the copyright, while maintaining the original author's BSD copyright notice, because the GPL is a more restrictive license than the BSD license.

However, the Boost license is less restrictive than the BSD license, so technically you would be breaking the license attribution clause of the BSD license if you tried to simultaneously apply the more permissive Boost license to it.  You could probably go the other way from less restrictive Boost to more restrictive BSD though.  And if you own the copyright, you could actually dual-license as BSD/Boost, meaning the user chooses one or the other, but nobody offers that combo because they're both so permissive.

IANAL and this is all hazy legal territory, but I believe this is the way it would commonly be technically interpreted, ie you cannot do what you want and what was done with std.net.isemail, if originally BSD like you describe, can't be done without the explicit permission of the author.

On 11/30/2017 11:17 AM, Jack Stouffer wrote:
> I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.
> 
> This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects).
> 
> My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption?
> 
> Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that).

I checked, and the Phobos module is clearly in violation of the license in
https://github.com/dominicsayers/isemail/blob/master/is_email.php

This needs to be fixed immediately.

https://issues.dlang.org/show_bug.cgi?id=18023

On 11/30/2017 1:58 PM, Walter Bright wrote:
> I checked, and the Phobos module is clearly in violation of the license in
> https://github.com/dominicsayers/isemail/blob/master/is_email.php
> 
> This needs to be fixed immediately.
> 
> https://issues.dlang.org/show_bug.cgi?id=18023

Dominic gave us permission to relicense as Boost, so there is no problem. Phew!

On 2017-11-30 23:23, Walter Bright wrote:

> Dominic gave us permission to relicense as Boost, so there is no problem. Phew!

Yeah, no worries. I didn't start the work until we had permission to relicense from the original author.

-- 
/Jacob Carlborg

On Thursday, 30 November 2017 at 19:17:32 UTC, Jack Stouffer wrote:
> I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.

+1

On Thursday, 30 November 2017 at 19:17:32 UTC, Jack Stouffer wrote:
> ...

Ok, decided to try to make it from scratch based off just the spec in order to avoid any issues. You can follow my progress if you so desire here: https://github.com/JackStouffer/stdxdecimal

On 12/1/2017 2:31 AM, Jacob Carlborg wrote:
> On 2017-11-30 23:23, Walter Bright wrote:
> 
>> Dominic gave us permission to relicense as Boost, so there is no problem. Phew!
> 
> Yeah, no worries. I didn't start the work until we had permission to relicense from the original author.

I had forgotten, permission indeed was in my email archives from 2011.

But a problem remained - to anyone looking at the file, it looks like we copied the code and changed the license without permission. So I added a comment clarifying that we did have permission.

---

I once received a furious email from a person who said I stole his software and was distributing it without permission. I dug back through my archives, and forwarded him his own email granting me permission. Dodged a bullet on that one.

I once solicited and received permission from K+R to quote sections of their classic C book (both were extremely nice). It was during a stretch of about 3 months where I wasn't making backups, and a disk crash wiped it out. I was too embarrassed about that to ask again, and so I never used the quotes, and now it's too late.

It pays to keep backups of email. I very rarely need it, but when I do, it's a life saver. Though having 20 years of it now means searching it is a bit of a challenge :-)

Sometimes I'm a bit amazed at the 16 years of D newsgroup archives:

http://www.digitalmars.com/d/archives//index.html

On 11/30/2017 11:17 AM, Jack Stouffer wrote:
> I'm starting work on a proposal for stdx.decimal, and one of the clearest implementations to work off of is the Python implementation.
> 
> This however, poses a problem because Python's source is under the PSFL, a BSD-like permissive license. Any derivative work, such as a D conversion, must have the original copyright notice, a copy of the PSFL, as a well as a summary of changes. This is simple enough to do, but the resulting code would be dual-licensed with the PSFL and the BSL 1.0 (dual-licensing being relatively common in other OSS projects).
> 
> My question is there any reason this could pose a problem? Could this interfere with something like distribution or company adoption?
> 
> Also note, one of the existing Phobos modules, std.net.isemail, is supposed to be dual-licensed because it's derived from an existing BSD work. But, it's missing the BSD license from the top (and is technically breaking the license because of that).

You cannot add/change the license of software without permission from the copyright holder. Translating the code from one language to another does not erase the copyright - it's still a derived work.

If the license is incompatible with Phobos, i.e. as free as Boost is, then such a derived work cannot be a part of Phobos.

It can always be a separate library, though.