-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
On Thursday 16 of October 2014 19:16:32 Timothy Pearson wrote:
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
I have a question:
I often process patches from François, making adjustments as needed, and then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
I have a question:
I often process patches from François, making adjustments as needed, and then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
I have a question:
I often process patches from François, making adjustments as needed, and then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
I need to be clearer about one thing: If an author has not provided a signed-off-by line, do NOT add it for him under any circumstances. Especially in the United States and the UK the author may or may not have the legal right to license his or her work to anyone, so the signed-off-by line should not always be populated with the author's information.
In the special case of open source patches from other projects, the person that pulls the patch from that project and submits it to us should sign off on it. In this case the patch handler is asserting, via the license granted to him or her, that he or she has the right to relicense the patch to us. If this is not possible then there must be no signed-off-by line in the GIT commit message, and the patch needs to be reviewed by the core development team to verify its origin and license compatibility before committing.
Tim
On Thursday 16 of October 2014 21:14:26 Timothy Pearson wrote:
I have a question:
I often process patches from François, making adjustments as needed, and then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
Yes, I assumed that I start using '-s' at commit. I just did not know what the outcome will be using --author '...' together with '-s'.
At the same time, I also hesitated over the procedure of processing patches that need to be corrected before commit. If I had to incorporate a patch in its original form and as a subsequent commit make the necessary changes?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Thursday 16 of October 2014 21:14:26 Timothy Pearson wrote:
I have a question:
I often process patches from François, making adjustments as needed,
and
then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
Yes, I assumed that I start using '-s' at commit. I just did not know what the outcome will be using --author '...' together with '-s'.
I honestly don't know what the outcome of that would be. Probably best would be to either test it to see what happens or just manually add the appropriate signed-off-by line to the bottom of the commit message.
If you do test it let us know how GIT handles those simultaneous flags!
At the same time, I also hesitated over the procedure of processing patches that need to be corrected before commit. If I had to incorporate a patch in its original form and as a subsequent commit make the necessary changes?
This StackOverflow answer handles this case well: http://stackoverflow.com/a/14044024
Tim
On Thursday 16 of October 2014 21:42:39 Timothy Pearson wrote:
On Thursday 16 of October 2014 21:14:26 Timothy Pearson wrote:
I have a question:
I often process patches from François, making adjustments as needed,
and
then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
Yes, I assumed that I start using '-s' at commit. I just did not know what the outcome will be using --author '...' together with '-s'.
I honestly don't know what the outcome of that would be. Probably best would be to either test it to see what happens or just manually add the appropriate signed-off-by line to the bottom of the commit message.
If you do test it let us know how GIT handles those simultaneous flags!
Such was the command:
git commit --author "François Andriot <francois.andriot@....>" -s -m "Test author × signoff"
And this is the result:
commit 24e312eaf69fbbdadea6d22f3e29a55951a133cb Author: François Andriot <francois.andriot@....> AuthorDate: Thu Oct 16 21:50:17 2014 +0200 Commit: Slávek Banko <slavek.banko@....> CommitDate: Thu Oct 16 21:50:17 2014 +0200
Test author × signoff
Signed-off-by: Slávek Banko <slavek.banko@....>
At the same time, I also hesitated over the procedure of processing patches that need to be corrected before commit. If I had to incorporate a patch in its original form and as a subsequent commit make the necessary changes?
This StackOverflow answer handles this case well: http://stackoverflow.com/a/14044024
Oh, yeah, that's good.
Tim
Am Donnerstag, 16. Oktober 2014 schrieb Timothy Pearson:
I have a question:
I often process patches from François, making adjustments as needed, and then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If so, how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
"How do you call it when a bus full of lawers goes over the cliffs?" "A good beginning!"
What about just demanding form every contributor for his/her patches/bugreports to be accepted the patches/report must comply to GPL v2/v3/BSD ... ? Place it in the bugtracker, place it on the list, be done.
If somebody wants to sue you, he/she will do despite whaterver contract was signed - especally in the "free" US. In the rest of the world that signed CLA will most likely not be valid at all (in most cases it's sufficent to claim you have not comprehended the text in its full extent, 'cause it's not written in your tongue)
Nik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Am Donnerstag, 16. Oktober 2014 schrieb Timothy Pearson:
I have a question:
I often process patches from François, making adjustments as needed,
and
then commit. For such posts will be listed as an author François and as Signed-off will be mine. Is this the correct procedure?
Actually he needs to sign off on them. It gets a bit confusing because there are actually three authorship fields in GIT that we are interested in: author, signed-off-by, and committer. In this case his name goes into author and signed-off-by, and your name goes into committer. So when you process the patches, if he provided a signed-off-by line for that patch in Bugzilla then you copy that into the commit message on the last line of the commit message, separated by a blank line.
As I am still phasing the CLA system in, and I trust the core team not to sue, include copyrighted code, etc., if he has not provided a signed-off-by line for the patches go ahead and commit them without a signed-off-by line.
For developers with GIT accounts you can commit and sign off all in one step by passing the -s flag to git commit. Just be aware that you are stating you have the legal right to license the commit when you do this; philosophically this is the same as before but the procedure is a bit more formal now.
Or contributions should be Signed-off at the same time by François? If
so,
how should it be implemented technically?
When he submits patches he should provide a signed-off-by line for that patch in the bugtracker. If anyone outside of the core team submits a patch without a signed-off-by line for that patch in the bug report we need to request that they provide one--the patch itself does not have to be resubmitted, but the submitter needs to add a comment stating they are signing off on that patch and appending the appropriate signed-off-by line to that comment.
Similarly, in cases of occasional contributors who do not have commit access? For example, during the integration of the translations.
Same as above; if patch is submitted via Email then the Email should contain the signed-off-by line. It's always OK to reply to a patch submission and request that a signed-off-by line be provided.
Does this make sense? Basically we're just fixing the bookkeeping end of the project so that we know who authored, who owns, who released, and who committed anything and can thereby better avoid any potential legal issues.
Tim
"How do you call it when a bus full of lawers goes over the cliffs?" "A good beginning!"
Heh. :-)
What about just demanding form every contributor for his/her patches/bugreports to be accepted the patches/report must comply to GPL v2/v3/BSD ... ? Place it in the bugtracker, place it on the list, be done.
The problem (explained below) boils down to at least in the USA/UK (unsure of elsewhere) a person may not actually have the legal rights to release their work under the GPL. If the true rights holder comes after me, which do you think will shorten the legal trouble: "I had a notice on the website so I thought they read and followed it..." or "this person was in breach of contract with me, here's the paperwork they read, signed, and violated!". I vote for the latter, as does every major open source project I know of: http://en.wikipedia.org/wiki/Contributor_License_Agreement
If somebody wants to sue you, he/she will do despite whaterver contract was signed - especally in the "free" US. In the rest of the world that signed CLA will most likely not be valid at all (in most cases it's sufficent to claim you have not comprehended the text in its full extent, 'cause it's not written in your tongue)
While I understand fully what you are saying, in all honesty I am not concerned about problems from contributors outside of the USA/UK. I think most of the free world understands what contributing to open source means; it's just our two countries (and maybe one or two others, not sure) where people seem to want to have their cake and eat it too.
This whole CLA thing kicked off many months ago because I have someone who lives in the USA and works for a USA-based engineering firm; basically in this situation the person's employer de facto owns all works created by the employee even in their off time unless the company explicitly releases those rights. Previously we had no mechanism by which the employee could ask the company to do that, and therefore no way for that person to ever contribute to TDE; now we have a mechanism in place.
Tim
Am Freitag, 17. Oktober 2014 schrieb Timothy Pearson:
While I understand fully what you are saying, in all honesty I am not concerned about problems from contributors outside of the USA/UK. I think most of the free world understands what contributing to open source means; it's just our two countries (and maybe one or two others, not sure) where people seem to want to have their cake and eat it too.
This whole CLA thing kicked off many months ago because I have someone who lives in the USA and works for a USA-based engineering firm; basically in this situation the person's employer de facto owns all works created by the employee even in their off time unless the company explicitly releases those rights. Previously we had no mechanism by which the employee could ask the company to do that, and therefore no way for that person to ever contribute to TDE; now we have a mechanism in place.
Tim
I'd call this kind of contract slavery.
Anyway, I'd go for a shorter license agreement. Something in the kind of "I, the contributor, own all rights of my contribution. I hold the project harmless against any third-party claims" (don't know if that's the correct term, in german it's "schad und klaglos halten").
As far as my experience with lawyers goes, these kind of folk hate simple terms. Judges on the other hand love simple terms.
Nik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Am Freitag, 17. Oktober 2014 schrieb Timothy Pearson:
While I understand fully what you are saying, in all honesty I am not concerned about problems from contributors outside of the USA/UK. I think most of the free world understands what contributing to open source means; it's just our two countries (and maybe one or two others, not sure) where people seem to want to have their cake and eat it too.
This whole CLA thing kicked off many months ago because I have someone who lives in the USA and works for a USA-based engineering firm; basically in this situation the person's employer de facto owns all works created by the employee even in their off time unless the company explicitly releases those rights. Previously we had no mechanism by which the employee could ask the company to do that, and therefore no way for that person to ever contribute to TDE; now we have a mechanism in place.
Tim
I'd call this kind of contract slavery.
As would I, however it's the norm rather than the exception over here. I wish we would start adopting some of your laws on work and privacy, but that is never going to happen; this country outsourced most of its technology manufacturing long ago and seems to have put a death grip on its (rapidly fading) intellectual property as a result.
Anyway, I'd go for a shorter license agreement. Something in the kind of "I, the contributor, own all rights of my contribution. I hold the project harmless against any third-party claims" (don't know if that's the correct term, in german it's "schad und klaglos halten").
- From what I understand under our laws that wouldn't be sufficient. The legal rights holder would win with no recourse on my part even if the original author signed that.
My kindergarten-level German is a bit strained here (not sure exactly what "klaglos" means in this context) but I think it translates most closely as "waive all rights and damages"?
As far as my experience with lawyers goes, these kind of folk hate simple terms. Judges on the other hand love simple terms.
I tried to pick the least-complicated CLA I could find that would still hold up under USA/UK law. If David Rankin is around perhaps he could shed some light on whether I am being too careful or not careful enough?
Thanks for your input!
Tim
Am Freitag, 17. Oktober 2014 schrieb Timothy Pearson:
My kindergarten-level German is a bit strained here (not sure exactly what "klaglos" means in this context) but I think it translates most closely as "waive all rights and damages"?
Not exactly. It means if you get sued by C 'cause B's contribution violates C's "rights", then B has to take the call, not you, and in case any damage from the action of B comes to you, B has to stand for it.
Nik
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Am Freitag, 17. Oktober 2014 schrieb Timothy Pearson:
My kindergarten-level German is a bit strained here (not sure exactly what "klaglos" means in this context) but I think it translates most closely as "waive all rights and damages"?
Not exactly. It means if you get sued by C 'cause B's contribution violates C's "rights", then B has to take the call, not you, and in case any damage from the action of B comes to you, B has to stand for it.
Nik
OK, thanks for the explaination. I'm still trying to learn German, but obviously have a long way to go. :-)
We do not have that concept in US law. I wish we did, it would make things so much simpler (we have even had Google and YouTube sued for linking to users' content)!
Tim
On Thursday 16 of October 2014 19:16:32 Timothy Pearson wrote:
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
Some technical questions:
1) It would be useful to either pre-fill 'Us' or add instructions how it should be filled.
2) Remember that the contributors can be from all over the world, and it would be good to specify the fax number including international callsign - ie: +1 (415) 639-6630.
3) If sending by email procedure should be what? Print, fill in informations 'You', be signed, scanned and sent as images? It would be good instructions also add to the web page.
<snip>
Some technical questions:
- It would be useful to either pre-fill 'Us' or add instructions how it
should be filled.
- Remember that the contributors can be from all over the world, and it would
be good to specify the fax number including international callsign - ie: +1 (415) 639-6630.
- If sending by email procedure should be what? Print, fill in
informations 'You', be signed, scanned and sent as images? It would be good instructions also add to the web page.
Slavek raised some good points.
I went through the individual CLA and my understanding is that it should be signed by both the Contributor and by "Us". Am I right? How is the Contributor getting a copy from "Us" after the signature? It would be good to add some information as well.
As a general observation, I have no problem with a CLA (as long as my employer approves that) and I do understand why you want to introduce them, but I think it may scare away potentially new contributors in case they come along, especially people from outside the US. The contents of the CLA is "nothing new", but being a legally binding document, some people may just think "What the hell? I will join another open project".
Just my 2 cents.
Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
<snip> > > Some technical questions: > > 1) It would be useful to either pre-fill 'Us' or add instructions how it > should be filled. > > 2) Remember that the contributors can be from all over the world, and it > would > be good to specify the fax number including international callsign - > ie: +1 (415) 639-6630. > > 3) If sending by email procedure should be what? Print, fill in > informations 'You', be signed, scanned and sent as images? > It would be good instructions also add to the web page. >
Slavek raised some good points.
I went through the individual CLA and my understanding is that it should be signed by both the Contributor and by "Us". Am I right? How is the Contributor getting a copy from "Us" after the signature? It would be good to add some information as well.
This should now be clearer; as mentioned in my prior message I have now signed the documents and the GPG signatures can be downloaded from the CLA page.
As a general observation, I have no problem with a CLA (as long as my employer approves that) and I do understand why you want to introduce them, but I think it may scare away potentially new contributors in case they come along, especially people from outside the US. The contents of the CLA is "nothing new", but being a legally binding document, some people may just think "What the hell? I will join another open project".
Yes, this was my concern too. However it seems that not having a CLA is really leaving yourself open to project-killing lawsuits; even if you "win" in the end you still lose the project and (in many cases) everything you own. We aren't as civilized here as other countries; there are no maximum penalties in copyright-related matters and one accusation brought to court can ruin a life, even if proven baseless.
I looked around some and every major open source project including KDE requires a CLA at this point. Seems it just comes with the territory; if we scare a potential contributor with our CLA they will probably be scared off of any other major project as well. I've tried to lay out the rationale and mechanics of the CLA in plain English on the site; hopefully this helps to mitigate the "scariness" factor.
Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Thursday 16 of October 2014 19:16:32 Timothy Pearson wrote:
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
Some technical questions:
- It would be useful to either pre-fill 'Us' or add instructions how it
should be filled.
Good catch. I had wanted to use the PDFs generated on the Harmony site to avoid any potential introduction of errors, but that doesn't appear to be an option. I have *carefully* regenerated the PDFs from the Harmony templates and prefilled the "Us" fields, as well as added editable fields for the contributor section.
- Remember that the contributors can be from all over the world, and it
would be good to specify the fax number including international callsign - ie: +1 (415) 639-6630.
Whoops! I do business internationally and therefore religiously tack on the "+1" prefix; not sure how I managed to leave it off that page.
- If sending by email procedure should be what? Print, fill in
informations 'You', be signed, scanned and sent as images? It would be good instructions also add to the web page.
As there is now fillable field support I think it is a bit more obvious what is intended? Either way is fine, though if it's signed on paper then scanned there is no need for a digital signature and vice versa.
I have also generated GPG digital signatures for the two PDFs on the site; these constitute my signing of the agreements the same way as if someone else had sent in a digital signature for a CLA via Email.
I could use some help from David Rankin if he's on the list to make sure I have done this all correctly, but at least this is a good start.
Thanks all for your input!
Tim
On Friday 17 of October 2014 08:20:42 Timothy Pearson wrote:
On Thursday 16 of October 2014 19:16:32 Timothy Pearson wrote:
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
Some technical questions:
- It would be useful to either pre-fill 'Us' or add instructions how it
should be filled.
Good catch. I had wanted to use the PDFs generated on the Harmony site to avoid any potential introduction of errors, but that doesn't appear to be an option. I have *carefully* regenerated the PDFs from the Harmony templates and prefilled the "Us" fields, as well as added editable fields for the contributor section.
- Remember that the contributors can be from all over the world, and it
would be good to specify the fax number including international callsign - ie: +1 (415) 639-6630.
Whoops! I do business internationally and therefore religiously tack on the "+1" prefix; not sure how I managed to leave it off that page.
- If sending by email procedure should be what? Print, fill in
informations 'You', be signed, scanned and sent as images? It would be good instructions also add to the web page.
As there is now fillable field support I think it is a bit more obvious what is intended? Either way is fine, though if it's signed on paper then scanned there is no need for a digital signature and vice versa.
I have also generated GPG digital signatures for the two PDFs on the site; these constitute my signing of the agreements the same way as if someone else had sent in a digital signature for a CLA via Email.
I could use some help from David Rankin if he's on the list to make sure I have done this all correctly, but at least this is a good start.
Thanks all for your input!
Tim
Great, it looks good. Now I have yet to find a pdf viewer that support form fields, because usually I have installed only kpdf :)
Just wondering: what is the status of CLAs? Have they been finalized? Cheers Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Just wondering: what is the status of CLAs? Have they been finalized? Cheers Michele
Considering that the feedback we received was mostly neutral/positive, and that we haven't received any additional feedback for quite some time I think we can consider them finalized. I'll hold off for a couple days just in case this message triggers further discussion.
Tim
On Saturday 01 of November 2014 04:33:50 Timothy Pearson wrote:
Just wondering: what is the status of CLAs? Have they been finalized? Cheers Michele
Considering that the feedback we received was mostly neutral/positive, and that we haven't received any additional feedback for quite some time I think we can consider them finalized. I'll hold off for a couple days just in case this message triggers further discussion.
Tim
I note that almost the same question I posted more than 10 days ago and there was no further discussion. See:
http://trinity-devel.pearsoncomputing.net/?0::13977
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Saturday 01 of November 2014 04:33:50 Timothy Pearson wrote:
Just wondering: what is the status of CLAs? Have they been finalized? Cheers Michele
Considering that the feedback we received was mostly neutral/positive, and that we haven't received any additional feedback for quite some time I think we can consider them finalized. I'll hold off for a couple days just in case this message triggers further discussion.
Tim
I note that almost the same question I posted more than 10 days ago and there was no further discussion. See:
http://trinity-devel.pearsoncomputing.net/?0::13977
-- Slávek
OK, I am going to consider the CLAs finalized at this time.
Current TDE developers: please sign and return a copy via the instructions on the Web site (assuming of course you have the legal right to do so--if you do not, please contact me directly).
Thanks!
Tim
On Thursday 16 of October 2014 19:16:32 Timothy Pearson wrote:
All,
After much consideration I have decided it would be safest to require our developers to formalize their open-source contributions with a CLA.
The CLA on the main TDE site does not transfer copyright or do anything objectionable like Canonical's old CLA did; it simply formalizes the long-standing intuitive agreement between open-source contributors and open-source projects. Specifically, contributors grant a license to use, redistribute, modify, etc. the contributed work under our approved open-source licenses (sadly this formalization is required even though most people would think contributing to an open source project automatically granted those rights!), waive any patent rights they may otherwise hold for the contribution (some people contribute then sue for high damages), etc. Fairly standard stuff but in the increasingly litigious environment of the United States the risks are just too high to continue without a CLA.
I have not arrived at this decision lightly, but have tried to keep the CLA as minimal as possible while protecting the project. I don't believe the CLA grants any further rights to the project than already intuitively granted when people contribute to an open source project; if I am in error please let me know ASAP!
Until I get feedback from the core team this is not mandatory for anyone who has already contributed to the project. Above all I do not want to alienate the core development team without whom this project would not be possible.
The agreements (and rationale) are available here: https://www.trinitydesktop.org/cla/
Thank you for your consideration,
Timothy Pearson Trinity Desktop Project
Please, there are no further comments for CLA? We therefore consider the current form for the final?
-
Dr. Nikolaus Klepp -
Michele Calgaro -
Slávek Banko -
Timothy Pearson