OpenID patch about smf HOT 35 CLOSED

Regarding the license can we assume is fine or do we need something else?

Maybe @mikemill can give a more informed opinion.
And @norv just in case :P

More in general regarding openID, a while ago I was thinking to play with http://gitorious.org/lightopenid

from smf.

I sent the OP a PM requesting permission, will report back once they reply.

from smf.

Oh he's definitely offering it license free. Also with the way OpenID is, I don't think you can copyright conforming to the spec :P

from smf.

Regarding the license can we assume is fine or do we need something else?

What license? That is the problem. None was specified with the patch, so the same principle applies as with old mods: no license means closed source. Sure he sent a patch, that can imply, one would argue, that the code is sent to be included within SMF. However, to be legally safe, we should ask the contributor.

Now, if they were under the CLA, that would be a different story.

Oh he's definitely offering it license free. Also with the way OpenID is, I don't think you can copyright conforming to the spec :P

It's quite a murky business. Don't need permission to conform to an open spec, but do require it to take in the contrib.

from smf.

It would be totally fine if this person himself submits the patch with a proper DCO. But if this person cannot or won't do that then we definitely need his written permission to SMF and SM to redistribute his code or to him to explicitly release his patch with a license that is compatible with SMF's.

from smf.

Believe it or not this isn't criminal law, you do not need to prove anything. You just need to ensure that it was probably meant that way. On the balance of probability it just needs to fall on our side.

From his description file, he includes a changelog, and in the post asks if theres a better place to submit his patch. If thats not falling on our side on the balance of probability, then call me Waldo :P

A lot of people are spreading a lot of FUD on the SM.org boards when it comes to licensing.

from smf.

But don't you want to avoid lawyers and their creepy faces?

from smf.

Read the post, there aren't lawyers gonna come after us :)

from smf.

Yes, I see what you mean, but you never know, perhaps today I'm all for open source and tomorrow I become a greedy bastard. That's why we have a DCO, to cover SMF's posterior, let's ask the guy to properly send a pull request :)

from smf.

I doubt he'll do it.

On Sat, Aug 25, 2012 at 11:10 AM, Jessica González <[email protected]

wrote:

Yes, I see what you mean, but you never know, perhaps today I'm all for
open source and tomorrow I become a greedy bastard. That's why we have a
DCO, to cover SMF's posterior, let's ask the guy to properly send a pull
request :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/151#issuecomment-8025866.

from smf.

Apart from layers, we have in place DCO and we ask to sign off any commit, so it's good practice to be sure of what we are including into the package.

from smf.

Is not about the guy or if he would do it or not, there is a possibility (0.0000001 if you like) and as such, we should act on this possibility.

from smf.

Thats your opinion, keep it separate from fact.

He posted a patch in a patch format for us to use. We currently need to find a real simple way for us to accept this stuff on the board, maybe an extra bbcode or something.

[dco]

from smf.

En Sat, 25 Aug 2012 13:13:03 -0500, emanuele45 [email protected]
escribió:

Apart from layers, we have in place DCO and we ask to sign off any
commit, so it's good practice to be sure of what we are including into
the package.

---

Reply to this email directly or view it on GitHub:
#151 (comment)

this ^^

Yes he posted on the board, lets ask him to properly submit a pull request
with a sign-off by line. Thats all we need to do really.

I don't really get why we need to modify the forum for something like
this, it isn't that often and the forum isn't the right place to post that
kind of stuff in the first place (he is aware of that, he is even asking
for it!), now thats a fact, not an opinion ;)

from smf.

I concur that the BB code is overkill.

On Sat, Aug 25, 2012 at 12:20 PM, Jessica González <[email protected]

wrote:

En Sat, 25 Aug 2012 13:13:03 -0500, emanuele45 [email protected]
escribió:

Apart from layers, we have in place DCO and we ask to sign off any
commit, so it's good practice to be sure of what we are including into
the package.

---

Reply to this email directly or view it on GitHub:
#151 (comment)

this ^^

Yes he posted on the board, lets ask him to properly submit a pull request
with a sign-off by line. Thats all we need to do really.

I don't really get why we need to modify the forum for something like
this, it isn't that often and the forum isn't the right place to post that
kind of stuff in the first place (he is aware of that, he is even asking
for it!), now thats a fact, not an opinion ;)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/151#issuecomment-8026515.

from smf.

He posted 4 month ago, we basically ignored him.

He was asked almost a month ago to this day to come here, and hasn't.

We're obviously at an impasse now. Its ultimately up to a dev now whether they roll it in.

from smf.

I had a think about this again and I'm dumb. Can we get his email address from the profile at SM.org and try and have him agree, having a DCO would be better.

I'll go back to the silly seat.

from smf.

We do need his/her express permission to include the patch. There are a few ways to do that:

1. Have the user post "I give permission to include this work under the current license". Then someone else can submit the pull request under condition C of the DCO.
2. Have the user supply a patch with the sign-off in it. Can be done fairly easily with git. Then again, someone else can submit the pull request under condition C of the DCO.
3. Have the user submit a pull request themselves.

Oh, and Trekkie is right, this isn't criminal law. This is the much uglier civil law side :D The only safe assumption we can make is that we have no rights to the patch unless explicitly given them.

from smf.

Please feel free to apply it to a branch. I don't have it at hand at the moment, but I remember the case and I'll sign off it as far as open licensing goes.

from smf.

There are multiple issues with our OpenID support, not sure this fixes them all or not but its certainly a good start. That said it seems like we are still at odds here between:

The only safe assumption we can make is that we have no rights to the patch unless explicitly given them.

and

I'll sign off it as far as open licensing goes

I honestly don't think there is anything unique/proprietary/copyright/etc in that code, but it's not my project risk call either.

from smf.

Mike is right, in principle. I don't think any assumptions can or should be made on attachments on threads, in particular in the SMF community at this time.
I am saying I have checked though in the past, on this one, and I know it was okay, that's why I can and I am willing to sign off it.

from smf.

But Norv, you aren't the original author :(

If the patch is just fine and we can't reach the original author anymore
then lets just rewrite it, put a proper sign off line and be done with it
:D

It is a shame the original author didn't left any clear indication about
his/her code rights but this is also a good opportunity for us, next time
something like this happens again we will now know how to act and will act
immediately.

En Wed, 17 Oct 2012 20:52:44 -0500, Norv [email protected]
escribió:

Mike is right, in principle. I don't think any assumptions can or should
be made on attachments on threads, in particular in the SMF community at
this time.
I am saying I have checked though in the past, on this one, and I know
it was okay, that's why I can and I am willing to sign off it.

---

Reply to this email directly or view it on GitHub:
#151 (comment)

Suki

from smf.

Part of the DCO covers signing off for someone else, iirc.

from smf.

En Thu, 18 Oct 2012 11:27:56 -0500, Steven Hoffman
[email protected] escribió:

Part of the DCO covers signing off for someone else, iirc.

Oh yes, I'm aware of that, but that only applies if the original author
has given proper permissions and for some reason he/she is unable to
commit it him/herself, in this particular case the original author didn't
clearly specify any rights been given to SM or SMF for his/her code to be
used, thus, we can commit the patch but we will be exposed to legal stuff
since we used a code that, as far as the law knows, its closed.

I just want to avoid/prevent any possible leak that can derivate on legal
stuff later on, safety first!

from smf.

I believe the author in good faith wanted their code contributed back to the project. They provided a diff and attached it to a public location. They made no indication that they wish to restrict their code.

Otherwise somebody else just has to write the code to support OpenID 2.0 themselves, not using the patch.

from smf.

What's the current thinking on this, from what I can see the poster in good faith handed the patch to SMF to be used in the product.

from smf.

from what I can see the poster in good faith handed the patch to SMF to be used in the product.

Just to note, this is not enough of a reason to know a license, in the given conditions.

from smf.

I agree that we need to get explicit permission (preferably in the form of a signed-off PR here on GitHub) from the author. Even if everything appears to be in our favor, it's best to make absolutely sure he's given us the right to use the code the way we want, to avoid any potential legal problems in the future.

from smf.

Understood, might be worth someone writing their own update as you could spend forever trying to get in contact with the user and get nowhere.

from smf.

Can this be closed?

from smf.

i dont believe openID has been fixed yet.

from smf.

@Oldiesmann can give more info.

from smf.

At this point we're just going to remove OpenID support altogether. The latest standard is OpenID Connect (so even OpenID 2.0 is obsolete now) and the only PHP library for that requires a bunch of extra PEAR packages that I'd rather not include (and I don't want to spend time rewriting it to not involve those).

from smf.

Sounds good to me.

On Wed, Aug 6, 2014 at 9:33 AM, Michael Eshom [email protected]
wrote:

At this point we're just going to remove OpenID support altogether. The
latest standard is OpenID Connect (so even OpenID 2.0 is obsolete now) and
the only PHP library for that requires a bunch of extra PEAR packages that
I'd rather not include (and I don't want to spend time rewriting it to not
involve those).

—
Reply to this email directly or view it on GitHub
#151 (comment)
.

from smf.

OpenID support removed in #2166. Closing this now.

from smf.