www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Question on Dual-Licensing Some Code for Phobos

reply Jack Stouffer <jack jackstouffer.com> writes:
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).
Nov 30 2017
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 30 2017
prev sibling next sibling parent Joakim <dlang joakim.fea.st> writes:
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.
Nov 30 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Nov 30 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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!
Nov 30 2017
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 01 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
Dec 01 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-12-01 23:45, Walter Bright wrote:


 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.


In addition to that, the first commit for that module was a copy paste 
of the PHP code, which is Boost licensed [1]. I was a suggestion by you 
and turned out to be really useful, both for this topic and for catching 
issues in porting the PHP code to D.


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


Perhaps time to write a D tool for that job ;)

-- 
/Jacob Carlborg
Dec 02 2017
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
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
Dec 01 2017
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
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
Dec 01 2017
parent reply codephantom <me noyb.com> writes:
On Friday, 1 December 2017 at 16:24:27 UTC, Jack Stouffer wrote:

 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


Just the fact that you've seen that source code, is enough to 
have already 'contaminated' you with that source code's licence, 
and, that could (potentially)constitute your work as being a 
derivative work.

Lesson? Be careful what source code you look at ;-)
Dec 01 2017
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 02, 2017 at 02:35:18AM +0000, codephantom via Digitalmars-d wrote:
[...]

 Just the fact that you've seen that source code, is enough to have
 already 'contaminated' you with that source code's licence, and, that
 could (potentially)constitute your work as being a derivative work.
 
 Lesson? Be careful what source code you look at ;-)


This is why Walter does not look at the code for any other compiler --
he could potentially be accused of stealing code from others.

Though I'm not sure if this has changed now that Symantec has so
graciously granted him to relicense the DMD backend code (which is
shared with DMC, IIRC).


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit
forever.
Dec 01 2017
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 2 December 2017 at 02:35:18 UTC, codephantom wrote:

 Just the fact that you've seen that source code, is enough to 
 have already 'contaminated' you with that source code's 
 licence, and, that could (potentially)constitute your work as 
 being a derivative work.


To that I say "prove it in court" :)
Dec 01 2017
parent codephantom <me noyb.com> writes:
On Saturday, 2 December 2017 at 05:05:14 UTC, Jack Stouffer wrote:

 On Saturday, 2 December 2017 at 02:35:18 UTC, codephantom wrote:

 Just the fact that you've seen that source code, is enough to 
 have already 'contaminated' you with that source code's 
 licence, and, that could (potentially)constitute your work as 
 being a derivative work.


 To that I say "prove it in court" :)


What if I can afford the best intellectual property rights 
lawyers on the planet.

You best start saving ;-)
Dec 01 2017
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Dec 01 2017
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Walter Bright wrote:


 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.


but you still can add another license to source code translation, if that 
new license doesn't violate the original one. like, you can distribute some 
source code port under GPL if the original was covered by BSDL, so the port 
is covered by two licenses *simultaneously* now (i.e. a user must obey both).
Dec 01 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2017 2:57 PM, ketmar wrote:

 Walter Bright wrote:
 

 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.


 
 but you still can add another license to source code translation, if that new 
 license doesn't violate the original one. like, you can distribute some source 
 code port under GPL if the original was covered by BSDL, so the port is
covered 
 by two licenses *simultaneously* now (i.e. a user must obey both).


Any added license only applies to what you added that was new.
Dec 01 2017
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Walter Bright wrote:


 On 12/1/2017 2:57 PM, ketmar wrote:

 Walter Bright wrote:
 

 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.


 but you still can add another license to source code translation, if 
 that new license doesn't violate the original one. like, you can 
 distribute some source code port under GPL if the original was covered 
 by BSDL, so the port is covered by two licenses *simultaneously* now 
 (i.e. a user must obey both).


 Any added license only applies to what you added that was new.


which, in case of source port, is everything. it is still derived work, so 
i cannot drop the original license, but the port is covered by both 
licenses, and added license cannot be removed too.
Dec 01 2017
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 02/12/17 03:44, Walter Bright wrote:

 On 12/1/2017 2:57 PM, ketmar wrote:

 Walter Bright wrote:


 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.


 but you still can add another license to source code translation, if 
 that new license doesn't violate the original one. like, you can 
 distribute some source code port under GPL if the original was covered 
 by BSDL, so the port is covered by two licenses *simultaneously* now 
 (i.e. a user must obey both).


 
 Any added license only applies to what you added that was new.


True, but there is no requirement to make the original work available 
and/or distinguishable.
Dec 02 2017
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
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).


That s great that you have a look at this area.

Maybe the developers of the Python Decimal Module could be asked 
whether they allow us to license the derived work as BSL similar 
to isemail.

Do you know there is already a similar attempt to bring decimal 
to phobos: https://github.com/andersonpd/eris
This work could also be a starting point...

Kind regards
Andre
Dec 02 2017
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 2 December 2017 at 18:30:22 UTC, Andre Pany wrote:

 Do you know there is already a similar attempt to bring decimal 
 to phobos: https://github.com/andersonpd/eris
 This work could also be a starting point...


What about:

http://www.boost.org/doc/libs/1_62_0/libs/math/doc/html/math_toolkit/high_precision/use_multiprecision.html

(I haven't used it.)
Dec 02 2017
prev sibling parent Shachar Shemesh <shachar weka.io> writes:
On 30/11/17 21:17, 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).


IANAL

That's not how it works.

Dual licensing means anyone can use the code under one license *or* the 
other. That is not something you can do on your own.

If the PSFL license and the Boost license are *compatible*, then what 
you can do is take the original Python code under the PSFL and convert 
it to D, licensing *your changes* as Boost. The result should look 
something like this:

This code is copyright (C) 2017 Jack Stouffer
Original Python code copyright (original copyright notice)

Python code is licensed under the PSFL

PSFL head goes here.

D code is licensed under the Boost license:

Boost license header goes here
Dec 02 2017