[GSoC notes] Licenses for open source software

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[GSoC notes] Licenses for open source software

Natale Patriciello

Here the notes:
====================
We started with the presentation of the participants; I asked if someone
has problems with free-riders and have then added clauses for limiting
the phenomena.
People answered that after using platforms such as Gitlab/Github the
contributions increased. Another experience reported is that people do
not expect that they can contribute back. Maintainers have the feeling
that the most of the feedbacks arrived when they broke things. For a
person, more users (even free-riders) are using the software, and better
is overall.

Then, the topic switched on how to deal with license compatibility and
license identification.

Many projects use SPDX identifiers on file. A project reported that they
have a git commit hook to check the presence of the license. Many
projects are using DCO to avoid potential problems when merging external
code.

A common missing item is a quick and fast checklist to see what a
license permits/does not permit, and what can be merged and what can
not.
For copyright issues, many projects use an automatically generated
contributors file. The two main problems still unresolved at the end of
the session are:

1) license education
2) license obligation (maybe a mailing list is needed?)


=======================

My comments:

I feel that we are doing pretty good on the license side. We already
have an example of license change (the documentation, happened some time
ago) and the process was smooth, at least from what I can remember.

However, I think that we have two points in which we can do better:

1) Developer certificate of origin
2) SPDX identifiers


For what regards point (1), how we make sure (as ns-3 project) that we
can publish the code we get as merge requests? For the moment I do not
recall that we had any problem, but prevention is better than fixing
problems :)

For the point (2), I proposed long time ago to replace the GPLv2 bloat
(and the EMACS header...) with an SPDX identifier. Easy and painless
change, at least from my point of view...

By the way, I said a thing that impressed the people from other
organization: that our first paragraph of our very first tutorial
(similar to an hello world) is dedicated to put the license header: that
is a good practice that other projects should do as well.

If you have comments or questions, please share them!

Natale
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC notes] Licenses for open source software

Tom Henderson-2
Natale, thanks for posting your notes and suggestions from the annual
Google Mentors Summit, which I have also found helpful to learn how
other open source projects operate, what new tools they are using, etc.

More inline below.

On 10/21/19 2:53 AM, Natale Patriciello wrote:

> Here the notes:
> ====================
> We started with the presentation of the participants; I asked if someone
> has problems with free-riders and have then added clauses for limiting
> the phenomena.
> People answered that after using platforms such as Gitlab/Github the
> contributions increased. Another experience reported is that people do
> not expect that they can contribute back. Maintainers have the feeling
> that the most of the feedbacks arrived when they broke things. For a
> person, more users (even free-riders) are using the software, and better
> is overall.
>
> Then, the topic switched on how to deal with license compatibility and
> license identification.
>
> Many projects use SPDX identifiers on file. A project reported that they
> have a git commit hook to check the presence of the license. Many
> projects are using DCO to avoid potential problems when merging external
> code.
>
> A common missing item is a quick and fast checklist to see what a
> license permits/does not permit, and what can be merged and what can
> not.
> For copyright issues, many projects use an automatically generated
> contributors file. The two main problems still unresolved at the end of
> the session are:
>
> 1) license education
> 2) license obligation (maybe a mailing list is needed?)
>
>
> =======================
>
> My comments:
>
> I feel that we are doing pretty good on the license side. We already
> have an example of license change (the documentation, happened some time
> ago) and the process was smooth, at least from what I can remember.
>
> However, I think that we have two points in which we can do better:
>
> 1) Developer certificate of origin
> 2) SPDX identifiers
>
>
> For what regards point (1), how we make sure (as ns-3 project) that we
> can publish the code we get as merge requests? For the moment I do not
> recall that we had any problem, but prevention is better than fixing
> problems :)

We do not use the DCO and git --signed-off-by.  However, we do ask
contributors to only contribute code that is suitably licensed; see the
second paragraph here:

https://www.nsnam.org/develop/contributing-code/licensing/

While I agree that, in general, prevention is better than fixing
problems, if prevention introduces more friction to maintainers or
contributors, we should be careful.

I just had an off list email discussion with Jared and Tommaso regarding
how I would, as maintainer, rebase and squash the merge request 102.  I
would typically do this when I am ready to push to master.  Sometimes I
will fix some small thing in a contributor's patch (like a misspelling
or style issue) as part of this process.  If I need to do this work,
then pause, and ask again for Jared to review by signing off on my final
patch, it adds more friction that I would like to avoid.  I could push
this work off on the contributor also, to ask him or her to
rebase/squash again and sign off again, because I found a small issue,
but is that what we want to do?

It is not clear to me what benefit, in the end, that doing so would
bring to ns-3, because in either case, someone could someday complain
that some code was included inappropriately, and we would have to look
into the matter, and then if we agreed, we would have to take steps to
remove it, regardless of whether we had a sign off or not.

So, I'm not yet convinced about the need for ns-3 to have CLAs or DCOs
to contribute vs. having the less formal approach we have now of
pointing out in our code contribution guidelines that it is the
responsibility of people contributing to the project to make sure that
their patches are OK in this regard.

>
> For the point (2), I proposed long time ago to replace the GPLv2 bloat
> (and the EMACS header...) with an SPDX identifier. Easy and painless
> change, at least from my point of view...

Regarding point 2, we had the thread on this last year (archived here):

https://mailman.isi.edu/pipermail/ns-developers/2018-September/014528.html

At the time, only you, me, and Peter commented, and inertia won out. 
Have perspectives changed since then?

As for SPDX, I think you are proposing that we compress these lines in
each file's header:

  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation;
  *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307  USA

into a single line as follows:

|// SPDX-License-Identifier: GPL-2.0-only|

I am neutral about making this change.  If we follow our loose guideline
of 'When in doubt, do what Linux does," then perhaps this tips the scale
towards making the change.  Any other opinions?

- Tom

Reply | Threaded
Open this post in threaded view
|

Re: [GSoC notes] Licenses for open source software

Natale Patriciello
On 24/10/19 at 04:27, Tom Henderson wrote:
> On 10/21/19 2:53 AM, Natale Patriciello wrote:
[cut]

> While I agree that, in general, prevention is better than fixing problems,
> if prevention introduces more friction to maintainers or contributors, we
> should be careful.
>
> I just had an off list email discussion with Jared and Tommaso regarding how
> I would, as maintainer, rebase and squash the merge request 102.  I would
> typically do this when I am ready to push to master.  Sometimes I will fix
> some small thing in a contributor's patch (like a misspelling or style
> issue) as part of this process.  If I need to do this work, then pause, and
> ask again for Jared to review by signing off on my final patch, it adds more
> friction that I would like to avoid.  I could push this work off on the
> contributor also, to ask him or her to rebase/squash again and sign off
> again, because I found a small issue, but is that what we want to do?

The less problematic way to deal with this is to merge the contributor's
patch (and I like a lot doing git merge --no-ff feature-branch in the
master) and then create a commit that fixes whatever you want to fix. It
is also the most fair, because it divides the credit between the
original contributor, and you, in a fair way. I think what you are doing
is an overcomplication to avoid to have more commits that ideally
needed, but we do not live in an ideal world, let the commit number grow :-)

> It is not clear to me what benefit, in the end, that doing so would bring to
> ns-3, because in either case, someone could someday complain that some code
> was included inappropriately, and we would have to look into the matter, and
> then if we agreed, we would have to take steps to remove it, regardless of
> whether we had a sign off or not.

In this case, let suppose that one company sues ns-3 consortium because
a code that is merged in the mainline is infringing a development contract (e.g., the
contractor released the code too soon  https://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA).
Without DCA, the company can do a lot of damage to the consortium (I am
not just talking about reverting the change, but also for monetary
compensation). With the DCA, the Consortium can "forward" the alleged
infringement to the signer of the DCA, freeing the Consortium from any
problem (except the revert, but that has to be done anyway).


> So, I'm not yet convinced about the need for ns-3 to have CLAs or DCOs to
> contribute vs. having the less formal approach we have now of pointing out
> in our code contribution guidelines that it is the responsibility of people
> contributing to the project to make sure that their patches are OK in this
> regard.

I am against CLAs for ns-3, given our governance. But for DCO, I see the
improvements that it can give (almost) for free. If the terms of the
DCO are not convicing, we can force the signoff to have understood and
comply with our contribution guidelines.


Nat
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC notes] Licenses for open source software

Tom Henderson-2
On 10/28/19 1:59 AM, Natale Patriciello wrote:

> On 24/10/19 at 04:27, Tom Henderson wrote:
>> On 10/21/19 2:53 AM, Natale Patriciello wrote:
> [cut]
>> While I agree that, in general, prevention is better than fixing problems,
>> if prevention introduces more friction to maintainers or contributors, we
>> should be careful.
>>
>> I just had an off list email discussion with Jared and Tommaso regarding how
>> I would, as maintainer, rebase and squash the merge request 102.  I would
>> typically do this when I am ready to push to master.  Sometimes I will fix
>> some small thing in a contributor's patch (like a misspelling or style
>> issue) as part of this process.  If I need to do this work, then pause, and
>> ask again for Jared to review by signing off on my final patch, it adds more
>> friction that I would like to avoid.  I could push this work off on the
>> contributor also, to ask him or her to rebase/squash again and sign off
>> again, because I found a small issue, but is that what we want to do?
> The less problematic way to deal with this is to merge the contributor's
> patch (and I like a lot doing git merge --no-ff feature-branch in the
> master) and then create a commit that fixes whatever you want to fix. It
> is also the most fair, because it divides the credit between the
> original contributor, and you, in a fair way. I think what you are doing
> is an overcomplication to avoid to have more commits that ideally
> needed, but we do not live in an ideal world, let the commit number grow :-)
>
>> It is not clear to me what benefit, in the end, that doing so would bring to
>> ns-3, because in either case, someone could someday complain that some code
>> was included inappropriately, and we would have to look into the matter, and
>> then if we agreed, we would have to take steps to remove it, regardless of
>> whether we had a sign off or not.
> In this case, let suppose that one company sues ns-3 consortium because
> a code that is merged in the mainline is infringing a development contract (e.g., the
> contractor released the code too soon  https://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA).
> Without DCA, the company can do a lot of damage to the consortium (I am
> not just talking about reverting the change, but also for monetary
> compensation). With the DCA, the Consortium can "forward" the alleged
> infringement to the signer of the DCA, freeing the Consortium from any
> problem (except the revert, but that has to be done anyway).
>
I would like to get some confirmation (e.g. past similar cases) that it
would work out so nicely, because I suspect not.

However, I will try to take up this question with others who know more
about it, so that we can make a more informed decision.

- Tom