June 23, 2014
On 6/23/2014 3:42 AM, Daniel Murphy wrote:
> You don't need to deal with it in the future, because boost allows you
> to change to a more restrictive license if necessary.  eg We could
> change it to BSD or GPL _without_ needing copyright assignment.  This
> is only a problem if we want to remove restrictions, and there doesn't
> seem to be any point to doing that.

I don't know what issues may come up, hopefully none. But laws can and do change, and flaws may be found in Boost, such that the license needs to adapt with the times. Shutting the door on that seems to me to be akin to putting a "kill switch" on dmd.

>
> Also, AIUI we will not be able to change the license of phobos and
> druntime anyway, since there is no copyright assignment for those.
> We're 'stuck' with boost either way.
>

And that is a potential problem, too, but less of one than dmdfe itself. Worst case a module can be discarded and redone (like Tango XML).
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/2014 10:59 AM, Steven Schveighoffer via dmd-internals wrote:
> I think the issue is that some future developers will not contribute. Some people just don't want to give up all rights to their work.

What practical right does one retain when it is licensed under Boost?

Ya know, I don't want to retain rights to D. I originally tried to make it public domain, until several people informed me that PD was not a legal concept in many countries. Boost was the next best thing. I want to continue to make D as available as possible, and that means the license may need to be adjusted in the future. If contributors do not share those goals, then yes, they should reconsider contributing to D.

I do understand the issue of retaining credit for one's work. But I believe that the github commit history amply supports that goal, and is one of the reasons I am very much in favor of using github for D.


> I don't know that I care about copyright assignment for DMD either way. Boost is certainly a very permissive license, > and I don't see us moving to an incompatible one in the future. On the other hand, you don't know what will happen in > the future. Someone future court challenge can make our version of boost unusable for some entire bloc of users, and > then we would be stuck. The likelihood of this latter case is astronomically low I think.

> As an aside, the tango XML library is not something that we could "just incorporate", so I don't think that's a fair > example. It requires tango's entire stream system.


I haven't looked at the code, but I suspect the stream system dependency would be easily converted to ranges.


>   And in general, the author of that module had proven not to be amenable to having any of his code in phobos.

There were multiple authors of Tango XML, and one did not want to change the license. So all the other contributors had their code thrown under the bus as well. Note that many bits of Tango did wind up in Phobos, because all the contributors of those bits did agree. That's the big problem - one person can hold the whole thing hostage, intentionally or simply by being unavailable. Do we really want that for dmd?


>   I think the copyright assignment issue there is moot. Also, note that the requirement on the wiki is for DMD only. It does not specify phobos/druntime contributions have the requirement, and as far as I know, we do not have that authorization from all phobos/druntime contributors.
>
> Is there some compromise we can attain that allows updating the license to some future version of Boost without assigning full copyright to Digital Mars?
>
>

The entity that can change the license is the copyright holder.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/14, 5:25 PM, Walter Bright via dmd-internals wrote:
> On 6/23/2014 10:59 AM, Steven Schveighoffer via dmd-internals wrote:
>> I think the issue is that some future developers will not contribute.
>> Some people just don't want to give up all rights to their work.
>
> What practical right does one retain when it is licensed under Boost?
>
> Ya know, I don't want to retain rights to D. I originally tried to make
> it public domain, until several people informed me that PD was not a
> legal concept in many countries. Boost was the next best thing. I want
> to continue to make D as available as possible, and that means the
> license may need to be adjusted in the future. If contributors do not
> share those goals, then yes, they should reconsider contributing to D.

I concur. If the contributor holding the copyright disappears, we can't change the license anymore. If the contributor holding the copyright has a falling with D, they can do harm by suddenly changing license for their part of Phobos. I don't see any good for anyone out of this - only the right to damage D in the future if they so want.

> I do understand the issue of retaining credit for one's work. But I
> believe that the github commit history amply supports that goal, and is
> one of the reasons I am very much in favor of using github for D.

Don't forget the "Authors:" tag. In a few cases we've erred on the side of more credit, e.g. list as authors people who contributed only a small fraction of a module.

>> I don't know that I care about copyright assignment for DMD either
>> way. Boost is certainly a very permissive license, > and I don't see
>> us moving to an incompatible one in the future. On the other hand, you
>> don't know what will happen in > the future. Someone future court
>> challenge can make our version of boost unusable for some entire bloc
>> of users, and > then we would be stuck. The likelihood of this latter
>> case is astronomically low I think.
>
>> As an aside, the tango XML library is not something that we could
>> "just incorporate", so I don't think that's a fair > example. It
>> requires tango's entire stream system.
>
>
> I haven't looked at the code, but I suspect the stream system dependency
> would be easily converted to ranges.
>
>
>>   And in general, the author of that module had proven not to be
>> amenable to having any of his code in phobos.
>
> There were multiple authors of Tango XML, and one did not want to change
> the license. So all the other contributors had their code thrown under
> the bus as well. Note that many bits of Tango did wind up in Phobos,
> because all the contributors of those bits did agree. That's the big
> problem - one person can hold the whole thing hostage, intentionally or
> simply by being unavailable. Do we really want that for dmd?

There was the same problem with Tango dates and times. We couldn't even look at the respective Tango code - and how many ways can one really implement the classic dates and times algorithms? - because of exhausting scrutiny from people who were apparently looking to pick a fight.

>> Is there some compromise we can attain that allows updating the
>> license to some future version of Boost without assigning full
>> copyright to Digital Mars?
>
> The entity that can change the license is the copyright holder.

And that's where the potential harm lies if we federalize copyright in Phobos.


Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 24, 2014
(somehow I failed to hit send on this last night)

On Tue, Jun 24, 2014 at 1:15 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
> Do you have a response for the existing precedents in which valuable work has been wasted?

My understanding is that in each case, work was wasted because it was under license A which couldn't be converted to license B.  Boost converts to everything else happily, which is why it was picked. Therefore this problem does not exist with boost.

> More generally (and for everyone), and please don't take this the wrong way as it comes from someone who knows next to nothing about this: I see there's considerable discussion here; what is the larger issue that seems to go unstated? It's entirely fine to want to maintain copyright of one's work, but on the face of it OSS seems to be a poor vehicle for that.

It's not about wanting to maintain my copyright, it's about removing an unnecessary hurdle to contribution.  For example, if we require copyright assignment I can't submit code that I don't own the copyright to, even if it's licence compatible.  Since the move to boost means we don't need it, we shouldn't have it.

>
> Andrei
>
>
> On 6/23/14, 3:42 AM, Daniel Murphy via dmd-internals wrote:
>>
>> You don't need to deal with it in the future, because boost allows you to change to a more restrictive license if necessary.  eg We could change it to BSD or GPL _without_ needing copyright assignment.  This is only a problem if we want to remove restrictions, and there doesn't seem to be any point to doing that.
>>
>> Also, AIUI we will not be able to change the license of phobos and druntime anyway, since there is no copyright assignment for those. We're 'stuck' with boost either way.
>>
>> On Mon, Jun 23, 2014 at 3:34 PM, Walter Bright <walter@digitalmars.com> wrote:
>>>
>>>
>>> On 6/22/2014 8:14 PM, Daniel Murphy wrote:
>>>>
>>>>
>>>> Those are all problems with incompatible licenses, and boost is supposed to solve these.  Now that the frontend is boost, why do we still need copyright assignment?
>>>
>>>
>>>
>>> Maybe, maybe not. I don't know what kind of issues will come up in the future, and how could I deal with it if major contributors are no longer available? What if there's some legal nit with Boost and it needs to be adjusted? GPL and BSD licenses have undergone revisions, would we want to get stuck forever with an obsolete Boost?
>>>
>>> Like I said, we've already had this problem more than once - and the resolution was abandonment of valuable work.
>>>
>>>
>>>>
>>>> I think for the frontend we're in good shape now without copyright assignment.
>>>>
>>>> On Mon, Jun 23, 2014 at 12:28 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:
>>>>>
>>>>>
>>>>> On 6/22/2014 2:15 PM, David Nadlinger via dmd-internals wrote:
>>>>>>
>>>>>>
>>>>>> On 22 Jun 2014, at 20:38, Walter Bright via dmd-internals wrote:
>>>>>>>
>>>>>>>
>>>>>>> It's still a good idea, as I'm not sure what issues may come up about
>>>>>>> it
>>>>>>> in the future. We've had contributors disappear before, questions
>>>>>>> come
>>>>>>> up,
>>>>>>> and we were forced to abandon their contributions as a result.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Putting aside all the other reasons why I think requiring copyright assignment now is a really bad idea:
>>>>>>
>>>>>> 1. What instance of troubles are you referring to, specifically?
>>>>>
>>>>>
>>>>>
>>>>> Jascha Wetzel wrote a Windows debugger in D, for example. His license
>>>>> was
>>>>> incompatible, he disappeared, his project was abandoned as a result.
>>>>> Then
>>>>> there's the case of the Tango code, such as the excellent XML parser -
>>>>> can't
>>>>> be incorporated into dmd because of the license. All that value got
>>>>> abandoned; nobody benefited from it. What a waste.
>>>>>
>>>>>
>>>>>
>>>>>> 2. How would a dubious copyright assignment give you any more security than licensing a contribution under Boost?
>>>>>
>>>>>
>>>>>
>>>>> If issues come up that only the copyright holder can resolve, we will
>>>>> be
>>>>> completely unable to resolve them. For example, I needed assignments in
>>>>> order to change the license to Boost. If one major contributor had
>>>>> refused,
>>>>> then where would we be?
>>>>>
>>>>>
>>>>>
>>>>>> Also note that systematically requiring copyright assignment before
>>>>>> merging a change on GitHub is not something we are currently doing. I
>>>>>> was
>>>>>> just not sure whether it is something you want to start doing.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I don't think it's critical for smallish contributions, as they can be worked around if necessary. For larger ones, yes.
>>>>>
>>>>> You say you're worried about something with this - can you explain?
>>>>> What's
>>>>> "really bad" about it?
>>>>>
>>>>> _
>>>
>>>
>>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 24, 2014
On Jun 23, 2014, at 8:25 PM, Walter Bright via dmd-internals <dmd-internals@puremagic.com> wrote:

> 
> On 6/23/2014 10:59 AM, Steven Schveighoffer via dmd-internals wrote:
>> I think the issue is that some future developers will not contribute. Some people just don't want to give up all rights to their work.
> 
> What practical right does one retain when it is licensed under Boost?

I don't know, practicality and logic sometimes are not factors in this decision. Go on any forum and badmouth the GPL, watch the rabid dogs emerge from perfectly competent programmers. Generally OSS programmers want to see their product used, but they may not be willing to part with all rights.

> 
> Ya know, I don't want to retain rights to D. I originally tried to make it public domain, until several people informed me that PD was not a legal concept in many countries. Boost was the next best thing. I want to continue to make D as available as possible, and that means the license may need to be adjusted in the future. If contributors do not share those goals, then yes, they should reconsider contributing to D.

Again, not for or against, just saying what I see.

> 
>> I don't know that I care about copyright assignment for DMD either way. Boost is certainly a very permissive license, > and I don't see us moving to an incompatible one in the future. On the other hand, you don't know what will happen in > the future. Someone future court challenge can make our version of boost unusable for some entire bloc of users, and > then we would be stuck. The likelihood of this latter case is astronomically low I think.
> 
>> As an aside, the tango XML library is not something that we could "just incorporate", so I don't think that's a fair > example. It requires tango's entire stream system.
> 
> 
> I haven't looked at the code, but I suspect the stream system dependency would be easily converted to ranges.

I don't really want to debate this point, I'll just say I don't agree.

> 
> 
>>  And in general, the author of that module had proven not to be amenable to having any of his code in phobos.
> 
> There were multiple authors of Tango XML, and one did not want to change the license. So all the other contributors had their code thrown under the bus as well. Note that many bits of Tango did wind up in Phobos, because all the contributors of those bits did agree. That's the big problem - one person can hold the whole thing hostage, intentionally or simply by being unavailable. Do we really want that for dmd?

Note that if Tango was boost licensed, we could incorporate anything we wanted without getting permission. You shouldn't conflate including non-compatible licensed code with later making the decision to switch DMD's license when people agreed to put their code into DMD. It's perfectly reasonable and common practice to require contributions to be licensed the same for inclusion on an open source project. Requiring assigning copyright is a much less common thing.

By this same logic, we can lament the fact that we can't incorporate libmysql because we didn't get it's owner's permission to license under boost instead of GPL. It's not a fair comparison -- Oracle/Sun did not want to contribute to D, so why should we worry about that?

I know all too well the "holding hostage" thing, and that is why I like the boost license. I think we have that base covered for the most part.

> 
> 
>>  I think the copyright assignment issue there is moot. Also, note that the requirement on the wiki is for DMD only. It does not specify phobos/druntime contributions have the requirement, and as far as I know, we do not have that authorization from all phobos/druntime contributors.
>> 
>> Is there some compromise we can attain that allows updating the license to some future version of Boost without assigning full copyright to Digital Mars?
>> 
>> 
> 
> The entity that can change the license is the copyright holder.

And granting certain rights while withholding others is always possible. For instance, I can grant power-of-attorney to someone to make one decision for me, it doesn't mean they then can do anything with my identity.

A statement saying that any contributors must agree that they give permission for Digital Mars to change the license of their code to any future version of boost license would be sufficient and reasonable, IMO. Remember that if any issues ever arise with boost license, the boost project is sure to fix them, and then we can adopt that new license.

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 24, 2014
On Jun 23, 2014, at 8:43 PM, Andrei Alexandrescu via dmd-internals <dmd-internals@puremagic.com> wrote:

> On 6/23/14, 5:25 PM, Walter Bright via dmd-internals wrote:
>> On 6/23/2014 10:59 AM, Steven Schveighoffer via dmd-internals wrote:
>>> I think the issue is that some future developers will not contribute. Some people just don't want to give up all rights to their work.
>> 
>> What practical right does one retain when it is licensed under Boost?
>> 
>> Ya know, I don't want to retain rights to D. I originally tried to make it public domain, until several people informed me that PD was not a legal concept in many countries. Boost was the next best thing. I want to continue to make D as available as possible, and that means the license may need to be adjusted in the future. If contributors do not share those goals, then yes, they should reconsider contributing to D.
> 
> I concur. If the contributor holding the copyright disappears, we can't change the license anymore. If the contributor holding the copyright has a falling with D, they can do harm by suddenly changing license for their part of Phobos. I don't see any good for anyone out of this - only the right to damage D in the future if they so want.

The only harm this does is that we need someone else to maintain this code. It does not retroactively change the license. Once it's in phobos, and it's boost, there's no reneging on that.

BTW, are we talking all of D or just DMD for requiring copyright assignment? I thought we were just talking DMD (of course, the XML thing would have been for Phobos, but I thought that was just an example).

> 
>> I do understand the issue of retaining credit for one's work. But I believe that the github commit history amply supports that goal, and is one of the reasons I am very much in favor of using github for D.
> 
> Don't forget the "Authors:" tag. In a few cases we've erred on the side of more credit, e.g. list as authors people who contributed only a small fraction of a module.

In some cases, as Daniel pointed out (great point, BTW), the original author may not be a github user, but some other code that a github user ported. I would not use the github contributors list as an authoritative list.

-Steve


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/14, 6:44 PM, Daniel Murphy wrote:
> (somehow I failed to hit send on this last night)
>
> On Tue, Jun 24, 2014 at 1:15 AM, Andrei Alexandrescu <andrei@erdani.com> wrote:
>> Do you have a response for the existing precedents in which valuable work
>> has been wasted?
>
> My understanding is that in each case, work was wasted because it was
> under license A which couldn't be converted to license B.  Boost
> converts to everything else happily, which is why it was picked.
> Therefore this problem does not exist with boost.

Boost doesn't convert to "everything else", particularly because "everything" includes licenses that haven't been created yet.

If Boost 1.0 comes with Boost 2.0 which somehow isn't convertible easily and obviously from Boost, we'd need to contact everybody "could you please let us change the license" etc.

>> More generally (and for everyone), and please don't take this the wrong way
>> as it comes from someone who knows next to nothing about this: I see there's
>> considerable discussion here; what is the larger issue that seems to go
>> unstated? It's entirely fine to want to maintain copyright of one's work,
>> but on the face of it OSS seems to be a poor vehicle for that.
>
> It's not about wanting to maintain my copyright, it's about removing
> an unnecessary hurdle to contribution.  For example, if we require
> copyright assignment I can't submit code that I don't own the
> copyright to, even if it's licence compatible.  Since the move to
> boost means we don't need it, we shouldn't have it.

I think that's a good point. Walter?


Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/2014 6:44 PM, Daniel Murphy wrote:
> My understanding is that in each case, work was wasted because it was under license A which couldn't be converted to license B. Boost converts to everything else happily, which is why it was picked. Therefore this problem does not exist with boost.

Again, you are assuming that no flaws are found in Boost and the laws don't change. I wish to point out again that both the GPL and BSD licenses have been revised.

We'd be placing an enormous bet that you are right - and the downside would be disaster like what happened to Tango.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/14, 9:06 PM, Steven Schveighoffer via dmd-internals wrote:
> On Jun 23, 2014, at 8:43 PM, Andrei Alexandrescu via dmd-internals
> <dmd-internals@puremagic.com> wrote:
>> I concur. If the contributor holding the copyright disappears, we
>> can't change the license anymore. If the contributor holding the
>> copyright has a falling with D, they can do harm by suddenly
>> changing license for their part of Phobos. I don't see any good for
>> anyone out of this - only the right to damage D in the future if
>> they so want.
>
> The only harm this does is that we need someone else to maintain this
> code. It does not retroactively change the license. Once it's in
> phobos, and it's boost, there's no reneging on that.

What if converting/relicensing it later to Boost 2.0 or some other license is in the best interest of D, and due to some technicality we'd need approval of all copyright holders? I don't know much about copyright law, but I think we can all agree it's complicated and prone to all sorts of loopholes. We can trust Walter to act in the best interest of D now and in the future; the alternative on the table is to trust instead an open union of persons.

> BTW, are we talking all of D or just DMD for requiring copyright
> assignment? I thought we were just talking DMD (of course, the XML
> thing would have been for Phobos, but I thought that was just an
> example).

Everything under our github repo.

>>> I do understand the issue of retaining credit for one's work. But
>>> I believe that the github commit history amply supports that
>>> goal, and is one of the reasons I am very much in favor of using
>>> github for D.
>>
>> Don't forget the "Authors:" tag. In a few cases we've erred on the
>> side of more credit, e.g. list as authors people who contributed
>> only a small fraction of a module.
>
> In some cases, as Daniel pointed out (great point, BTW), the original
> author may not be a github user, but some other code that a github
> user ported. I would not use the github contributors list as an
> authoritative list.

The "Authors:" tag appears in the ddoc text and can contain any appropriate credits. Just grep for it. You'll see that all my contributions appear with my name and link to my website.


Andrei
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 23, 2014
On 6/23/2014 9:00 PM, Steven Schveighoffer via dmd-internals wrote:
>
> A statement saying that any contributors must agree that they give permission for Digital Mars to change the license of their code to any future version of boost license would be sufficient and reasonable, IMO. Remember that if any issues ever arise with boost license, the boost project is sure to fix them, and then we can adopt that new license.
>



LLVM doesn't require copyright assignment, but they admit on their site that they are aware that implies the LLVM license can never change. GCC requires copyright assignment for larger contributions.

If the copyright holder agrees to such a clause, what rights do they retain as copyright holder? Such open-ended clauses may also even be invalid - I've never heard of one. Going with copyright assignment is simple and direct. I don't care to try and break new legal ground here. I don't care to risk the hard work of every contributor to D by trying a novel legal theory.

> By this same logic, we can lament the fact that we can't incorporate libmysql because we didn't get it's owner's permission to license under boost instead of GPL. It's not a fair comparison -- Oracle/Sun did not want to contribute to D, so why should we worry about that?

Because we don't really care about libmysql's license. If it's license becomes incompatible with D's goals, we'll just find another library. It won't destroy D. We can even survive various modules in Phobos needing to be rebooted over licensing issues. It'd be a lot harder to survive dmd being holed below the waterline.


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals