Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
Hi all, In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive. This causes legal problem. Hope somebody can fix this. Thanks Dominique
How about contacting the author of the answer and asking him for (retroactive) permission to include that in Boost? https://stackoverflow.com/users/968261/alexey-frunze https://www.linkedin.com/in/alexfru/ https://github.com/alexfru/ (I'm assuming it's the first answer on that question page.) Eyal On 02/19/2018 04:34 PM, Dominique CHABAUD via Boost wrote:
Hi all,
In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar
Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive.
This causes legal problem. Hope somebody can fix this.
Thanks Dominique
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Eyal Rozenberg wrote:
How about contacting the author of the answer and asking him for (retroactive) permission to include that in Boost?
https://stackoverflow.com/users/968261/alexey-frunze https://www.linkedin.com/in/alexfru/ https://github.com/alexfru/
(I'm assuming it's the first answer on that question page.)
No, the author of the code in thread_primitives is Harry Johnston. https://stackoverflow.com/users/886887/harry-johnston
On 2/19/2018 4:34 PM, Dominique CHABAUD via Boost wrote:
Hi all,
In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar
Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive.
This causes legal problem. Hope somebody can fix this.
Thanks Dominique
I agree with the point being made, and would also like to add that as far as I can tell, there is a potential incompatibility between the MIT license and the Boost software license. So even with questions posted on Stack Overflow that do fall under the MIT license, there is a potential issue. The Boost license makes it explicitly clear that derived works distributed in object code form do not require attribution in accompanying documentation or similar, while the MIT license is ambiguous on this point. I am referring to this paragraph in the MIT license: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. It is not clear to me what "substantial portions of the software" means. If my reading of the license is correct, however, it does seem like derivative works distributed in object code form *do* require attribution as the license does not state anything to the contrary - at least not in an explicit fashion. So at best there is an ambiguity between the two licenses, in the worst case scenario they are simply incompatible on this point. I am not a lawyer, so anyone with more knowledge on the subject feel free to correct me. Thanks, Philip
On Mon, Feb 19, 2018 at 10:34 AM, Dominique CHABAUD wrote:
Hi all,
In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar
Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive.
This causes legal problem. Hope somebody can fix this.
Niall, you committed this: https://github.com/boostorg/thread/commit/04c53415fd0adc1921d419c54a1e5ec4b1... "Niall Douglas (s [underscore] sourceforge {at} nedprod [dot] com) committed on Jul 5, 2014" Have you already contacted the author(s) before committing it? Glen
This causes legal problem. Hope somebody can fix this.
Niall, you committed this:
https://github.com/boostorg/thread/commit/04c53415fd0adc1921d419c54a1e5ec4b1...
"Niall Douglas (s [underscore] sourceforge {at} nedprod [dot] com) committed on Jul 5, 2014"
Have you already contacted the author(s) before committing it?
As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption. The commit can be reverted if people feel strongly that this is not the case. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption.
I'm not a lawyer but... Better to rewrite this from scratch in terms of boost::atomic_uint64_t IMO. The algorithm is straightforward.
On 02/19/18 22:50, Peter Dimov via Boost wrote:
Niall Douglas wrote:
As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption.
I'm not a lawyer but...
Better to rewrite this from scratch in terms of boost::atomic_uint64_t IMO. The algorithm is straightforward.
+1 FWIW, there is already an implementation in Boost.Log which could be copied into Boost.Thread: https://github.com/boostorg/log/blob/develop/src/timestamp.cpp#L66
As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption.
I'm not a lawyer but...
Better to rewrite this from scratch in terms of boost::atomic_uint64_t IMO. The algorithm is straightforward.
The only reason that the OP raised my specific code is because I followed proper etiquette and linked the snippet back to its stackoverflow source so if bugs/questions/curiosity about the weird looking code ever occurred, the reader would have a URL to more information. This is good practice, Boost's by far most important contribution to C++ is for study by others. There are many other instances of stackoverflow snippets being in Boost, or the other way round, most of which are not linked. Nobody can say where they originated. The OP only raised my code because I had followed good etiquette. Others may not have done so, and may have "polluted" Boost significantly with "foreign" code. There is software available to check for this incidentally. But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all. Now, one can go overboard and insist that no "foreign" code ever exist in Boost. If the OP really cares enough about this, let him go ahead and rewrite the code and submit a pull request, though if I were maintainer, I'd refuse such a pull request because it would actively detract from the readability and value of the code. My opinion is that this is a non-issue, and more importantly, a position needs to be taken on going down such an unproductive path. There is no such thing as pure, wholly original code. The originality lies outside copy and pasting small individual parts, as indeed the Oracle vs Google case result showed, and which is now established case law in the US. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Feb 19, 2018 at 3:41 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all.
In which the courts found copyright infringement over a nine-line literally copied rangeCheck function. (The district court also later ruled that the jury could have validly found for either side on the fair use defense for the APIs. And the jury's fair-use verdict is still under appeal, so it's hardly "established case law".) This copying seems by far closer to the rangeCheck copying than the APIs.
On 19/02/2018 22:57, Tim Song via Boost wrote:
On Mon, Feb 19, 2018 at 3:41 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all.
In which the courts found copyright infringement over a nine-line literally copied rangeCheck function.
That was the jury's verdict in the first case. The judge overrode that in a ruling which can be read at http://www.groklaw.net/pdf3/OraGoogle-1202.pdf. In that he lays out the many cases where copyright cannot be infringed on a snippet, and the importance of originality as far as copyright is concerned. So, for example, a snippet cannot be original if there is only one way of calling a set of system APIs to achieve a goal, and copy-and-paste identicality is not important for copyright infringement, but rather it is the originality in the sequence of steps. So even if Peter takes that snippet and rewrites it, if he duplicates the sequence exactly, it's the same snippet as far as US IP law is concerned. Some code on stackoverflow does not call system APIs, and could have originality in its algorithm or design. Those snippets you don't reuse without permission. But if it mostly calls system APIs, its originality is highly constrained, and it now falls under fair use. The snippet in question calls a lot of system APIs. It is hard to implement very differently without replacing the calls to those system APIs with inferior ones. That's fair use so.
(The district court also later ruled that the jury could have validly found for either side on the fair use defense for the APIs. And the jury's fair-use verdict is still under appeal, so it's hardly "established case law".)
This copying seems by far closer to the rangeCheck copying than the APIs.
If you read the court's judgement, you will find that the rangeCheck issue stemmed from failure to sufficiently document original source, hence the importance of etiquette to comment where you get borrowed code from. The same programmer wrote the same code twice in two separate situations nothing to do with Android, and due to how open source works, one of those copies eventually ended up in Android through no design nor intent of anybody. That's why the court found a technical infringement, but with no damages, especially as once the infringement had been noticed, it was immediately rectified. This is what I've been saying: you can't make pristine open sourced IP. Can't be done. I've spotted on more than one occasion code on SO matching that of Boost. I suspect there's plenty of it, and nothing anyone can do about it. Even if it were all purged through a herculean effort now, a few years from now it would be back to the situation now. IP leaks across boundaries, so channel not damn the flow. Better therefore to attribute sources, cite your references, don't steal but instead borrow. Then if an IP claim lands, you've done everything by the book. Nobody did anything malicious like take somebody else's code, *and hide where they got it from* which is not a technical infringement, but a malicious one with intent to deceive. Everything I said above refers to very small pieces of code where any originality is hard to determine. Anything larger, or obviously novel, is copyright to its author and is not being referred to above. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Feb 19, 2018 at 6:48 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
On 19/02/2018 22:57, Tim Song via Boost wrote:
On Mon, Feb 19, 2018 at 3:41 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all.
In which the courts found copyright infringement over a nine-line literally copied rangeCheck function.
That was the jury's verdict in the first case. The judge overrode that in a ruling which can be read at http://www.groklaw.net/pdf3/OraGoogle-1202.pdf. In that he lays out the many cases where copyright cannot be infringed on a snippet, and the importance of originality as far as copyright is concerned.
The judge most certainly did not override the jury on the rangeCheck issue. And that opinion you cite - dealing with the copyrightability of APIs - is overturned on appeal.
That was the jury's verdict in the first case. The judge overrode that in a ruling which can be read at http://www.groklaw.net/pdf3/OraGoogle-1202.pdf. In that he lays out the many cases where copyright cannot be infringed on a snippet, and the importance of originality as far as copyright is concerned.
The judge most certainly did not override the jury on the rangeCheck issue.
And that opinion you cite - dealing with the copyrightability of APIs - is overturned on appeal.
The Appeal was to overturn the judge's original overriding of the jury's decision, and to put things back to the haphazard way the jury found them. The judge's original verdict text which I linked to is the main contribution to case law and precedent. He is one of America's leading experts on computer IP law, indeed I believe he programs himself. His summary text will be used in all legal arguments relating to computer IP going forth. The fact his judgment was overturned etc is relatively unimportant, as it related to how he implemented legal process, not his legal arguments in summarising the case. Anyway, as interesting as all this is, this is why Boost is part of the Software Freedom Conservancy who employ lawyers specifically for questions of this nature. The only reason that my specific use of SO snippets was noticed is because I added a comment regarding them. All other use of SO snippets are by definition uncommented, and are not being noticed. That makes them far more dangerous and pernicious if my understanding of copyright law is wrong. If Boost feels that this is a problem, the SFC lawyers should be asked and on the basis of their advice, the page at http://www.boost.org/development/requirements.html should be updated to specifically give advice on the use of small, non-standalone code snippets such as from StackOverflow. A commercial program which identifies code snippets borrowed from the internet should be employed to scan the Boost source code, and all infringements fixed. I throw the problem back to you, boost-steering. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On February 20, 2018 3:24:55 AM EST, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Anyway, as interesting as all this is, this is why Boost is part of the Software Freedom Conservancy who employ lawyers specifically for questions of this nature. The only reason that my specific use of SO snippets was noticed is because I added a comment regarding them. All other use of SO snippets are by definition uncommented, and are not being noticed. That makes them far more dangerous and pernicious if my understanding of copyright law is wrong.
If Boost feels that this is a problem, the SFC lawyers should be asked and on the basis of their advice, the page at http://www.boost.org/development/requirements.html should be updated to specifically give advice on the use of small, non-standalone code snippets such as from StackOverflow. A commercial program which identifies code snippets borrowed from the internet should be employed to scan the Boost source code, and all infringements fixed.
I throw the problem back to you, boost-steering.
+1 However, mentioning that on this list is not the same as actually raising this issue on the Steering Committee's discussion group. -- Rob (Sent from my portable computation device.)
I throw the problem back to you, boost-steering.
+1
However, mentioning that on this list is not the same as actually raising this issue on the Steering Committee's discussion group.
True. Those who feel this is a problem ought to submit a formal request to the Boost steering committee. The OP appears to come from a jurisdiction without the fair use exemption, hence their lawyers would have a stricter opinion than others on the practice of use of snippets. Historically Boost has chosen to follow US law, and has done nothing about pleasing other jurisdictions. I actually disagree with that, but my use of the snippets was based on Boost's historical choice on this. Had Boost chosen differently, I'd have done differently. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Niall, I first submitted the case to the Boost Steering Committee... and I was suggested to submit it to this list... I am not a Boost contributor but I agree with those who proposed to rewrite these dozen line of code, that will close the discussions... Dominique 2018-02-20 10:56 GMT+01:00 Niall Douglas via Boost <boost@lists.boost.org>:
I throw the problem back to you, boost-steering.
+1
However, mentioning that on this list is not the same as actually raising this issue on the Steering Committee's discussion group.
True. Those who feel this is a problem ought to submit a formal request to the Boost steering committee. The OP appears to come from a jurisdiction without the fair use exemption, hence their lawyers would have a stricter opinion than others on the practice of use of snippets.
Historically Boost has chosen to follow US law, and has done nothing about pleasing other jurisdictions. I actually disagree with that, but my use of the snippets was based on Boost's historical choice on this. Had Boost chosen differently, I'd have done differently.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 20/02/2018 10:41, Dominique CHABAUD via Boost wrote:
I first submitted the case to the Boost Steering Committee... and I was suggested to submit it to this list...
Yeah the procedure is fairly undocumented. First you approach boost-steering, they usually tell you to go to boost-dev, after some discussion you then have the option to mail boost-steering with the key phrase "I formally request that the Boost Steering Committee consider the following problem: <insert explanation here>". That turns it into a formal request, something they must action upon. Normal email without that key phrase causes no effect on boost-steering.
I am not a Boost contributor but I agree with those who proposed to rewrite these dozen line of code, that will close the discussions...
No copyright applies to those lines, as I've repeated an awful lot of times now. There is nothing to infringe. Rewriting them would detract from the codebase and reduce the study worth of Boost code. So I refuse to do it as to do so is pandering to superstition and ignorance when we should be taking a firm line on this instead, one based on evidence, rationality, common sense and making the best code one can make instead of brushing problems under the carpet, box ticking and refusing to cite, acknowledge nor attribute originators of ideas and inspirations behind great code. As is probably clear by now, I find that whole mentality of hiding your sources disgusting. Though, please do not take this as criticism of you Dominique. I am very grateful to you for raising, and pursuing this issue as it is one too often deliberately ignored lest what vipers may be found under the carpet, and then people would actually have to deal with this issue instead of pretending it doesn't exist. If someone else wants this topic to go away, they can submit a PR. Boost is open source. Be aware there is more than one use of stackoverflow snippets in Boost. If you PR to deal with one, best do them all, as you've just set a precedent. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Hi Niall, Yes, you're right, most of developers are not lawyers. The company I work for did a Third Party dependency scan of all our code. It was done by a company specialized in code check and the report was analyzed by a lawyer office specialized in copyright, licences, IP... They confirmed that this Boost contribution could be a problem at a court. Fortunately we do not use this contribution directly and our Dev team checked that the link step did not include it in our executable files. Dominique 2018-02-20 0:48 GMT+01:00 Niall Douglas via Boost <boost@lists.boost.org>:
On 19/02/2018 22:57, Tim Song via Boost wrote:
On Mon, Feb 19, 2018 at 3:41 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all.
In which the courts found copyright infringement over a nine-line literally copied rangeCheck function.
That was the jury's verdict in the first case. The judge overrode that in a ruling which can be read at http://www.groklaw.net/pdf3/OraGoogle-1202.pdf. In that he lays out the many cases where copyright cannot be infringed on a snippet, and the importance of originality as far as copyright is concerned.
So, for example, a snippet cannot be original if there is only one way of calling a set of system APIs to achieve a goal, and copy-and-paste identicality is not important for copyright infringement, but rather it is the originality in the sequence of steps. So even if Peter takes that snippet and rewrites it, if he duplicates the sequence exactly, it's the same snippet as far as US IP law is concerned.
Some code on stackoverflow does not call system APIs, and could have originality in its algorithm or design. Those snippets you don't reuse without permission. But if it mostly calls system APIs, its originality is highly constrained, and it now falls under fair use.
The snippet in question calls a lot of system APIs. It is hard to implement very differently without replacing the calls to those system APIs with inferior ones. That's fair use so.
(The district court also later ruled that the jury could have validly found for either side on the fair use defense for the APIs. And the jury's fair-use verdict is still under appeal, so it's hardly "established case law".)
This copying seems by far closer to the rangeCheck copying than the APIs.
If you read the court's judgement, you will find that the rangeCheck issue stemmed from failure to sufficiently document original source, hence the importance of etiquette to comment where you get borrowed code from. The same programmer wrote the same code twice in two separate situations nothing to do with Android, and due to how open source works, one of those copies eventually ended up in Android through no design nor intent of anybody. That's why the court found a technical infringement, but with no damages, especially as once the infringement had been noticed, it was immediately rectified.
This is what I've been saying: you can't make pristine open sourced IP. Can't be done. I've spotted on more than one occasion code on SO matching that of Boost. I suspect there's plenty of it, and nothing anyone can do about it. Even if it were all purged through a herculean effort now, a few years from now it would be back to the situation now. IP leaks across boundaries, so channel not damn the flow.
Better therefore to attribute sources, cite your references, don't steal but instead borrow. Then if an IP claim lands, you've done everything by the book. Nobody did anything malicious like take somebody else's code, *and hide where they got it from* which is not a technical infringement, but a malicious one with intent to deceive.
Everything I said above refers to very small pieces of code where any originality is hard to determine. Anything larger, or obviously novel, is copyright to its author and is not being referred to above.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
On 20/02/2018 07:55, Dominique CHABAUD via Boost wrote:
Hi Niall, Yes, you're right, most of developers are not lawyers. The company I work for did a Third Party dependency scan of all our code. It was done by a company specialized in code check and the report was analyzed by a lawyer office specialized in copyright, licences, IP... They confirmed that this Boost contribution could be a problem at a court. Fortunately we do not use this contribution directly and our Dev team checked that the link step did not include it in our executable files. Dominique
Let me repeat: the only reason that my use of SO code snippets was noticed is because I added a comment linking back to the original. For all the other uses of SO code snippets which are uncommented, anyone using Boost is in technical infringement. You just don't know that you are. And that's fine. All open source comes with the same risk, it's why historically Legal banned the use of open source because there's nobody worth suing standing behind its IP hygiene. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Feb 20, 2018 at 08:15:01AM +0000, Niall Douglas via Boost wrote:
On 20/02/2018 07:55, Dominique CHABAUD via Boost wrote:
Hi Niall, Yes, you're right, most of developers are not lawyers. The company I work for did a Third Party dependency scan of all our code. It was done by a company specialized in code check and the report was analyzed by a lawyer office specialized in copyright, licences, IP... They confirmed that this Boost contribution could be a problem at a court. Fortunately we do not use this contribution directly and our Dev team checked that the link step did not include it in our executable files. Dominique
Let me repeat: the only reason that my use of SO code snippets was noticed is because I added a comment linking back to the original.
Hi Niall Current generation software designed to find copyright and IP code infringement in source code do not need the author to put notices in the source code. They can even find instances of infringement where the author deliberately acted to obscure the infringement, by, for example, changing variables or hiding critical code in small functions or macros or etc. You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time. Karen. For
all the other uses of SO code snippets which are uncommented, anyone using Boost is in technical infringement. You just don't know that you are.
And that's fine. All open source comes with the same risk, it's why historically Legal banned the use of open source because there's nobody worth suing standing behind its IP hygiene.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost --- end quoted text ---
-- Karen Shaeffer The subconscious mind is driven by your deeply Neuralscape Services held beliefs -- not your deeply held desires.
On Tue, Feb 20, 2018 at 10:39 AM, Karen Shaeffer via Boost < boost@lists.boost.org> wrote:
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
Most of us are not lawyers. None of us are lawyers representing Boost as a legal entity. The rationale path is to bring this up with the steering committee, who can consult with Boost's legal representation if they deem it necessary, and get back to us with what we should do now and in the future. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Nevin Liber via Boost Sent: 20 February 2018 16:52 To: boost@lists.boost.org Cc: Nevin Liber Subject: Re: [boost] Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
On Tue, Feb 20, 2018 at 10:39 AM, Karen Shaeffer via Boost < boost@lists.boost.org> wrote:
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
Most of us are not lawyers. None of us are lawyers representing Boost as a legal entity.
The rationale path is to bring this up with the steering committee, who can consult with Boost's legal representation if they deem it necessary, and get back to us with what we should do now and in the future.
+1 Paul PS I think Niall is right on this, but it's a useful test case, and sets a precedent. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Wed, Feb 21, 2018 at 4:13 AM, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Nevin Liber via Boost Sent: 20 February 2018 16:52 To: boost@lists.boost.org Cc: Nevin Liber Subject: Re: [boost] Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
On Tue, Feb 20, 2018 at 10:39 AM, Karen Shaeffer via Boost < boost@lists.boost.org> wrote:
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
Most of us are not lawyers. None of us are lawyers representing Boost as a legal entity.
The rationale path is to bring this up with the steering committee, who can consult with Boost's legal representation if they deem it necessary, and get back to us with what we should do now and in the future.
+1
Paul
PS I think Niall is right on this, but it's a useful test case, and sets a precedent.
-1 My slack response about this: "There’s no point in getting the BSC involved (unless you want to wait around for some indefinite amount of time for an answer). Just contact the SFC directly. The SFC’s lawyers are likely to tell you the same thing that we already know. That’s it’s a possible concern. And that it’s up to you to decide what to do given that there’s a concern, even if minor, because it’s not their job to make your decision for you. Hence, it saves everyone time and effort to just deal with it now." Additionally there are at least two ways to deal with it: rewrite the code in question with a new license, obtain permission to use the code with a new license. Both of which naturally fell out of this conversation instead of the likely conversation with the SFC. So.. good job everyone :-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Let me repeat: the only reason that my use of SO code snippets was noticed is because I added a comment linking back to the original.
Current generation software designed to find copyright and IP code infringement in source code do not need the author to put notices in the source code. They can even find instances of infringement where the author deliberately acted to obscure the infringement, by, for example, changing variables or hiding critical code in small functions or macros or etc.
I am more familiar with this than most. You can rewrite code into a different programming language and it may still infringe. Simply rewriting a routine will not make infringement magically disappear, despite most programmers thinking this to be the case that if it isn't exactly the same, it's not infringing. But in any case all this is moot. No copyright is being infringed in any case due to the AFC test, which for the record I applied before choosing to reuse this snippet, as I do for all snippets I reuse from StackOverflow. This eliminates problems with IP ownership, which is why I do it. I am not incompetent at my job or as a software engineer. I do not make choices on IP in ignorance or laziness. Unlike most engineers, I actively read case law as a hobby. In a different life I would have entered law. I know what I am talking about, and I would have wished to have been trusted on my opinion on this. But okay, let's take the long road on this, as my expert opinion clearly carries zero weight here.
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
No, he said that his legal team flagged it. And that's because it has a source attributing comment. Had I not commented on its source, nothing would have been flagged by his legal team. Like all the other stackoverflow reuse, it would have slipped by without comment. Here is the "problem" routine in full: ``` ULONGLONG MyTickCount64(void) { static volatile DWORD count = 0xFFFFFFFF; DWORD previous_count, current_tick32, previous_count_zone, current_tick32_zone; ULONGLONG current_tick64; previous_count = InterlockedCompareExchange(&count, 0, 0); current_tick32 = GetTickCount(); if (previous_count == 0xFFFFFFFF) { // count has never been written DWORD initial_count; initial_count = current_tick32 >> 28; previous_count = InterlockedCompareExchange(&count, initial_count, 0xFFFFFFFF); current_tick64 = initial_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } previous_count_zone = previous_count & 15; current_tick32_zone = current_tick32 >> 28; if (current_tick32_zone == previous_count_zone) { // The top four bits of the 32-bit tick count haven't changed since count was last written. current_tick64 = previous_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } if (current_tick32_zone == previous_count_zone + 1 || (current_tick32_zone == 0 && previous_count_zone == 15)) { // The top four bits of the 32-bit tick count have been incremented since count was last written. InterlockedCompareExchange(&count, previous_count + 1, previous_count); current_tick64 = previous_count + 1; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } // Oops, we weren't called often enough, we're stuck return 0xFFFFFFFF; } ``` Let's apply https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test, so stage 1 is Abstraction into individual operations which is what copyright is actually on, not the specific textual form as most programmer think: 1. Persist a count variable across calls of the function. 2. If count is not initialised, store the top four bits of the 32 bit count, and exit. 3. Are the top four bits of the 32 bit count same as last time we were called? If so, exit. 4. Update the persisted count variable with the new top four bits of the 32 bit count, and adjust the value returned to account for the 32 bit wrap so it is accurate. 5. If the top four bits overflowed since the last time we were called, return a failure. Now apply the Filtration stage where we remove (i) elements dictated by efficiency, (ii) elements dictated by external factors, and (iii) elements taken from the public domain: 1. This is standard programming, and so in the public domain. Remove. 2. The call to fetch the 32 bit count and use of atomics is dictated by external factors. Remove. The only remaining item is the choice of top four bits. 3. All standard programming. Remove. 4. All standard programming and external factors. Remove. 5. Returning from a function is standard programming. Remove. That leaves those top four bits again. The final part of Filtration stage is whether the choice of four bits is an element dictated by efficiency. Two bits wouldn't allow detection of overflow. Six bits is overkill and detracts from efficiency. So we can remove the choice of four bits. Finally we move onto the Comparison stage: compare what is remaining after the previous two stages to see if copyright has been infringed. Except, as I just proved, **there is nothing remaining**. So therefore copyright cannot have been infringed by the AFC legal test. The routine is not different from what any skilled programmer would have written if implementing the same thing. Therefore no copyright applies. This use is fair use under US law, de minimis under other jurisdictions. *Every programmer* should be applying the AFC test to any code they study if they are replicating any of its behaviour. Otherwise they may quite easily infringe on copyright. Simply rewriting a routine does not help. Using a different programming language does not help. Replacing one routine with another which does the exact same thing does not help. I stand by my claim that no copyright violation has occurred here. There is nothing to hold copyright upon. I look forward to seeing what the SFC lawyers say regarding this specific instance (feel free to send them a copy of the above discussion). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Feb 20, 2018 at 07:07:26PM +0000, Niall Douglas via Boost wrote:
Let me repeat: the only reason that my use of SO code snippets was noticed is because I added a comment linking back to the original.
Current generation software designed to find copyright and IP code infringement in source code do not need the author to put notices in the source code. They can even find instances of infringement where the author deliberately acted to obscure the infringement, by, for example, changing variables or hiding critical code in small functions or macros or etc.
I am more familiar with this than most. You can rewrite code into a different programming language and it may still infringe. Simply rewriting a routine will not make infringement magically disappear, despite most programmers thinking this to be the case that if it isn't exactly the same, it's not infringing.
But in any case all this is moot. No copyright is being infringed in any case due to the AFC test, which for the record I applied before choosing to reuse this snippet, as I do for all snippets I reuse from StackOverflow. This eliminates problems with IP ownership, which is why I do it.
I am not incompetent at my job or as a software engineer. I do not make choices on IP in ignorance or laziness. Unlike most engineers, I actively read case law as a hobby. In a different life I would have entered law. I know what I am talking about, and I would have wished to have been trusted on my opinion on this.
But okay, let's take the long road on this, as my expert opinion clearly carries zero weight here.
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
No, he said that his legal team flagged it. And that's because it has a source attributing comment. Had I not commented on its source, nothing would have been flagged by his legal team. Like all the other stackoverflow reuse, it would have slipped by without comment.
Hi Niall, This is what he said: <quote> The company I work for did a Third Party dependency scan of all our code. It was done by a company specialized in code check and the report was analyzed by a lawyer office specialized in copyright, licences, IP... </quote> My interpretation is that the third party dependency scan flagged the code. Then, the lawyer reviewed the report from the third party dependency scan. And the lawyer simply concurred. This is none of my business and I have no more time for it. Karen.
Here is the "problem" routine in full:
``` ULONGLONG MyTickCount64(void) { static volatile DWORD count = 0xFFFFFFFF; DWORD previous_count, current_tick32, previous_count_zone, current_tick32_zone; ULONGLONG current_tick64;
previous_count = InterlockedCompareExchange(&count, 0, 0); current_tick32 = GetTickCount();
if (previous_count == 0xFFFFFFFF) { // count has never been written DWORD initial_count; initial_count = current_tick32 >> 28; previous_count = InterlockedCompareExchange(&count, initial_count, 0xFFFFFFFF);
current_tick64 = initial_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; }
previous_count_zone = previous_count & 15; current_tick32_zone = current_tick32 >> 28;
if (current_tick32_zone == previous_count_zone) { // The top four bits of the 32-bit tick count haven't changed since count was last written. current_tick64 = previous_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; }
if (current_tick32_zone == previous_count_zone + 1 || (current_tick32_zone == 0 && previous_count_zone == 15)) { // The top four bits of the 32-bit tick count have been incremented since count was last written. InterlockedCompareExchange(&count, previous_count + 1, previous_count); current_tick64 = previous_count + 1; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; }
// Oops, we weren't called often enough, we're stuck return 0xFFFFFFFF; } ```
Let's apply https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test, so stage 1 is Abstraction into individual operations which is what copyright is actually on, not the specific textual form as most programmer think:
1. Persist a count variable across calls of the function.
2. If count is not initialised, store the top four bits of the 32 bit count, and exit.
3. Are the top four bits of the 32 bit count same as last time we were called? If so, exit.
4. Update the persisted count variable with the new top four bits of the 32 bit count, and adjust the value returned to account for the 32 bit wrap so it is accurate.
5. If the top four bits overflowed since the last time we were called, return a failure.
Now apply the Filtration stage where we remove (i) elements dictated by efficiency, (ii) elements dictated by external factors, and (iii) elements taken from the public domain:
1. This is standard programming, and so in the public domain. Remove.
2. The call to fetch the 32 bit count and use of atomics is dictated by external factors. Remove. The only remaining item is the choice of top four bits.
3. All standard programming. Remove.
4. All standard programming and external factors. Remove.
5. Returning from a function is standard programming. Remove. That leaves those top four bits again.
The final part of Filtration stage is whether the choice of four bits is an element dictated by efficiency. Two bits wouldn't allow detection of overflow. Six bits is overkill and detracts from efficiency. So we can remove the choice of four bits.
Finally we move onto the Comparison stage: compare what is remaining after the previous two stages to see if copyright has been infringed. Except, as I just proved, **there is nothing remaining**. So therefore copyright cannot have been infringed by the AFC legal test. The routine is not different from what any skilled programmer would have written if implementing the same thing. Therefore no copyright applies. This use is fair use under US law, de minimis under other jurisdictions.
*Every programmer* should be applying the AFC test to any code they study if they are replicating any of its behaviour. Otherwise they may quite easily infringe on copyright. Simply rewriting a routine does not help. Using a different programming language does not help. Replacing one routine with another which does the exact same thing does not help.
I stand by my claim that no copyright violation has occurred here. There is nothing to hold copyright upon. I look forward to seeing what the SFC lawyers say regarding this specific instance (feel free to send them a copy of the above discussion).
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- end quoted text --- -- Karen Shaeffer The subconscious mind is driven by your deeply Neuralscape Services held beliefs -- not your deeply held desires.
Niall, I confirm what Karen said: the scanning software automatically flagged your contribution. As Karen explained such software are able to flag using different techniques, one is code signature comparison with a database of code signatures which they explained me is automatically enriched by web repositories and forums scanning. I do not have the information how your contribution has been flagged. And for the things to be clear this is not the legal department of my company which said it's a problem, this is an independent lawyer office, different than the external company which made the scan. I do not agree with your approach to check the IP of a function piece by piece and saying as each piece is not covered by IP, the assembly of all pieces is also not covered by IP. If you compare to a patented hardware for example, it is probable that each individual piece is not covered by any IP or patent, but the assembly of all pieces make something original and provide a new feature which can be patented. What lawyers explained me is that there is a risk, when there is a risk the decision could be lawyers against lawyers, and companies do not like such risks. I will now stop this discussion, my company found a solution for delivering our software products without this polluting contribution. I am sure Boost contributors or Steering Committee will make the good decision. Dominique -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: mardi 20 février 2018 20:07 To: Boost Developers List Cc: Niall Douglas; Boost Steering Committee Subject: Re: [boost] Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
Let me repeat: the only reason that my use of SO code snippets was noticed is because I added a comment linking back to the original.
Current generation software designed to find copyright and IP code infringement in source code do not need the author to put notices in the source code. They can even find instances of infringement where the author deliberately acted to obscure the infringement, by, for example, changing variables or hiding critical code in small functions or macros or etc.
I am more familiar with this than most. You can rewrite code into a different programming language and it may still infringe. Simply rewriting a routine will not make infringement magically disappear, despite most programmers thinking this to be the case that if it isn't exactly the same, it's not infringing. But in any case all this is moot. No copyright is being infringed in any case due to the AFC test, which for the record I applied before choosing to reuse this snippet, as I do for all snippets I reuse from StackOverflow. This eliminates problems with IP ownership, which is why I do it. I am not incompetent at my job or as a software engineer. I do not make choices on IP in ignorance or laziness. Unlike most engineers, I actively read case law as a hobby. In a different life I would have entered law. I know what I am talking about, and I would have wished to have been trusted on my opinion on this. But okay, let's take the long road on this, as my expert opinion clearly carries zero weight here.
You obviously didn't act to obscure anything. But Dominique has said such software has flagged the code. Enough said. The rational path is to just rewrite the code and move on. Honest mistakes happen in code all the time.
No, he said that his legal team flagged it. And that's because it has a source attributing comment. Had I not commented on its source, nothing would have been flagged by his legal team. Like all the other stackoverflow reuse, it would have slipped by without comment. Here is the "problem" routine in full: ``` ULONGLONG MyTickCount64(void) { static volatile DWORD count = 0xFFFFFFFF; DWORD previous_count, current_tick32, previous_count_zone, current_tick32_zone; ULONGLONG current_tick64; previous_count = InterlockedCompareExchange(&count, 0, 0); current_tick32 = GetTickCount(); if (previous_count == 0xFFFFFFFF) { // count has never been written DWORD initial_count; initial_count = current_tick32 >> 28; previous_count = InterlockedCompareExchange(&count, initial_count, 0xFFFFFFFF); current_tick64 = initial_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } previous_count_zone = previous_count & 15; current_tick32_zone = current_tick32 >> 28; if (current_tick32_zone == previous_count_zone) { // The top four bits of the 32-bit tick count haven't changed since count was last written. current_tick64 = previous_count; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } if (current_tick32_zone == previous_count_zone + 1 || (current_tick32_zone == 0 && previous_count_zone == 15)) { // The top four bits of the 32-bit tick count have been incremented since count was last written. InterlockedCompareExchange(&count, previous_count + 1, previous_count); current_tick64 = previous_count + 1; current_tick64 <<= 28; current_tick64 += current_tick32 & 0x0FFFFFFF; return current_tick64; } // Oops, we weren't called often enough, we're stuck return 0xFFFFFFFF; } ``` Let's apply https://en.wikipedia.org/wiki/Abstraction-Filtration-Comparison_test, so stage 1 is Abstraction into individual operations which is what copyright is actually on, not the specific textual form as most programmer think: 1. Persist a count variable across calls of the function. 2. If count is not initialised, store the top four bits of the 32 bit count, and exit. 3. Are the top four bits of the 32 bit count same as last time we were called? If so, exit. 4. Update the persisted count variable with the new top four bits of the 32 bit count, and adjust the value returned to account for the 32 bit wrap so it is accurate. 5. If the top four bits overflowed since the last time we were called, return a failure. Now apply the Filtration stage where we remove (i) elements dictated by efficiency, (ii) elements dictated by external factors, and (iii) elements taken from the public domain: 1. This is standard programming, and so in the public domain. Remove. 2. The call to fetch the 32 bit count and use of atomics is dictated by external factors. Remove. The only remaining item is the choice of top four bits. 3. All standard programming. Remove. 4. All standard programming and external factors. Remove. 5. Returning from a function is standard programming. Remove. That leaves those top four bits again. The final part of Filtration stage is whether the choice of four bits is an element dictated by efficiency. Two bits wouldn't allow detection of overflow. Six bits is overkill and detracts from efficiency. So we can remove the choice of four bits. Finally we move onto the Comparison stage: compare what is remaining after the previous two stages to see if copyright has been infringed. Except, as I just proved, **there is nothing remaining**. So therefore copyright cannot have been infringed by the AFC legal test. The routine is not different from what any skilled programmer would have written if implementing the same thing. Therefore no copyright applies. This use is fair use under US law, de minimis under other jurisdictions. *Every programmer* should be applying the AFC test to any code they study if they are replicating any of its behaviour. Otherwise they may quite easily infringe on copyright. Simply rewriting a routine does not help. Using a different programming language does not help. Replacing one routine with another which does the exact same thing does not help. I stand by my claim that no copyright violation has occurred here. There is nothing to hold copyright upon. I look forward to seeing what the SFC lawyers say regarding this specific instance (feel free to send them a copy of the above discussion). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I confirm what Karen said: the scanning software automatically flagged your contribution.
These guys https://www.safe-corp.com/ are the most common vendor of scanning software by IP firms. I've been at clients where we used them in the past. As they say at https://www.safe-corp.com/company_process.htm, correlations flagged by the software do not imply infringement. One of the very specific points they make is that unauthorised copying is plagiarism, but authorising copying is not. Hence the importance of attribution so authorisation can be easily traced if needed by some end user.
I do not agree with your approach to check the IP of a function piece by piece and saying as each piece is not covered by IP, the assembly of all pieces is also not covered by IP. If you compare to a patented hardware for example, it is probable that each individual piece is not covered by any IP or patent, but the assembly of all pieces make something original and provide a new feature which can be patented.
Patents protect ideas and processes. Copyright protects the *expression* of facts and ideas. Not the ideas nor facts themselves. Not the processes. You are conflating the two. The AFC test I mentioned is very widely used around the world by legal systems when dealing with copyright of software in particular. The only major jurisdiction which doesn't use it is the United Kingdom as far as I know. Small code snippets are very often the *only* way of doing something *efficiently* (the efficiency point is very important and unique to software copyright consideration). Hence two skilled engineers would be highly likely to write the same piece of code in the same circumstances. In this situation no copyright infringement can occur. (Most interestingly, if the original source stuck in a pointless inefficient piece of code in the middle, now copyright infringement *would* apply because now there is unique expression that would not be reasonably introduced by a different skilled programmer working independently. On this point many a copyright infringing startup has fallen)
What lawyers explained me is that there is a risk, when there is a risk the decision could be lawyers against lawyers, and companies do not like such risks.
All open source code is full of such risks, and a company is absolutely right to perform a scan for IP problems before using it. I've been at multinationals before where we were given a list of legally flagged problem sections in an open source library which had to be rewritten before we could use that library. Ideally, the company should really send those rewrites back to the open source library as a PR. But they never seem to do so :(. They ought to do so in thanks for the software. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 19 February 2018 23:49 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
On 19/02/2018 22:57, Tim Song via Boost wrote:
On Mon, Feb 19, 2018 at 3:41 PM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But it's a non-point. If you follow the full discussion of the reuse of snippets on stackoverflow, reuse of small pieces of code which are not self standing programs, or functionality in themselves, is not copyright infringement in most jurisdictions. cf https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc. after all.
In which the courts found copyright infringement over a nine-line literally copied rangeCheck function.
That was the jury's verdict in the first case. The judge overrode that in a ruling which can be read at http://www.groklaw.net/pdf3/OraGoogle-1202.pdf. In that he lays out the many cases where copyright cannot be infringed on a snippet, and the importance of originality as far as copyright is concerned.
So, for example, a snippet cannot be original if there is only one way of calling a set of system APIs to achieve a goal, and copy-and-paste identicality is not important for copyright infringement, but rather it is the originality in the sequence of steps. So even if Peter takes that snippet and rewrites it, if he duplicates the sequence exactly, it's the same snippet as far as US IP law is concerned.
Some code on stackoverflow does not call system APIs, and could have originality in its algorithm or design. Those snippets you don't reuse without permission. But if it mostly calls system APIs, its originality is highly constrained, and it now falls under fair use.
The snippet in question calls a lot of system APIs. It is hard to implement very differently without replacing the calls to those system APIs with inferior ones. That's fair use so.
(The district court also later ruled that the jury could have validly found for either side on the fair use defense for the APIs. And the jury's fair-use verdict is still under appeal, so it's hardly "established case law".)
This copying seems by far closer to the rangeCheck copying than the APIs.
If you read the court's judgement, you will find that the rangeCheck issue stemmed from failure to sufficiently document original source, hence the importance of etiquette to comment where you get borrowed code from. The same programmer wrote the same code twice in two separate situations nothing to do with Android, and due to how open source works, one of those copies eventually ended up in Android through no design nor intent of anybody. That's why the court found a technical infringement, but with no damages, especially as once the infringement had been noticed, it was immediately rectified.
This is what I've been saying: you can't make pristine open sourced IP. Can't be done. I've spotted on more than one occasion code on SO matching that of Boost. I suspect there's plenty of it, and nothing anyone can do about it. Even if it were all purged through a herculean effort now, a few years from now it would be back to the situation now. IP leaks across boundaries, so channel not damn the flow.
Better therefore to attribute sources, cite your references, don't steal but instead borrow. Then if an IP claim lands, you've done everything by the book. Nobody did anything malicious like take somebody else's code, *and hide where they got it from* which is not a technical infringement, but a malicious one with intent to deceive.
Everything I said above refers to very small pieces of code where any originality is hard to determine. Anything larger, or obviously novel, is copyright to its author and is not being referred to above.
+1 (And anyway, it's only honest good manners and helpful to any poor code reader). Paul
On Mon, Feb 19, 2018 at 2:50 PM, Peter Dimov wrote:
Niall Douglas wrote:
As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption.
I'm not a lawyer but...
Better to rewrite this from scratch in terms of boost::atomic_uint64_t IMO. The algorithm is straightforward.
Agreed. Dominique, thank you for raising this concern. Glen
Le 19/02/2018 à 20:16, Niall Douglas via Boost a écrit :
This causes legal problem. Hope somebody can fix this. Niall, you committed this:
https://github.com/boostorg/thread/commit/04c53415fd0adc1921d419c54a1e5ec4b1...
"Niall Douglas (s [underscore] sourceforge {at} nedprod [dot] com) committed on Jul 5, 2014"
Have you already contacted the author(s) before committing it? As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption. The commit can be reverted if people feel strongly that this is not the case.
Niall
Niall please, could you provide a PR with the adaptation from Boost.Log? Thanks in advance, Vicente
Have you already contacted the author(s) before committing it? As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption. The commit can be reverted if people feel strongly that this is not the case.
Niall please, could you provide a PR with the adaptation from Boost.Log?
I refuse to do so as there is no valid reason to do so. Please see my other reply. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Le 20/02/2018 à 20:08, Niall Douglas via Boost a écrit :
Have you already contacted the author(s) before committing it? As I've already said on boost-steering regarding this issue, I feel the code snippet in question falls under the fair use exemption. The commit can be reverted if people feel strongly that this is not the case.
Niall please, could you provide a PR with the adaptation from Boost.Log? I refuse to do so as there is no valid reason to do so. Please see my other reply.
I could understand that you could have good reasons to don't change. You always have good reasons. Sorry, I've not read the whole thread. Nevertheless doing such minor change is not costly at all. Andrey Semashev has proposed himself to provide a patch. Thanks again Andrey. Vicente
I could understand that you could have good reasons to don't change. You always have good reasons.
For an industry mostly concerned with generating valuable IP, the widespread school child level of ignorance regarding how law treats IP is consistently stunning. Otherwise intelligent engineers regularly conflate copyright, patents and trademarks, and consistently get wrong what is and is not plagiarism. They think that copy and paste is bad, and rewriting code they find on the internet is good. Many open source projects operate a "10 lines" rule, where if a snippet is less than ten lines long, then treat it as free of ownership. It's not that simple in the real world, and many, many startups have come very badly unstuck after they reach a certain size despite having written great code which usefully was disrupting an entire industry. Yet stupid, school child mistakes in how they wrote their code kills off the company. Despite all this, an industry wide tolerance of profound ignorance of IP continues. We need to do better.
Sorry, I've not read the whole thread.
Nevertheless doing such minor change is not costly at all.
Andrey Semashev has proposed himself to provide a patch.
Open source lets anybody modify any code for whatever reasons they have. But I will not personally engage in brushing a problem under the carpet. It's wrong to hide problems instead of dealing with them. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 21/02/2018 09:06, Niall Douglas via Boost wrote:
I could understand that you could have good reasons to don't change. You always have good reasons.
FYI Jon Kalb reached out to the author of the SO snippet in question and has acquired his permission for the snippet to be licensed under the Boost licence. He also has mentioned that it has a race condition. Bugs I am happy to fix. Expect a PR shortly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Wed, Feb 21, 2018 at 4:41 AM, Niall Douglas wrote:
On 21/02/2018 09:06, Vicente J. Botet Escriba wrote:
I could understand that you could have good reasons to don't change. You always have good reasons.
FYI Jon Kalb reached out to the author of the SO snippet in question and has acquired his permission for the snippet to be licensed under the Boost licence.
He also has mentioned that it has a race condition. Bugs I am happy to fix. Expect a PR shortly.
If Andrey has a solution (and apparently a PR already) that can resolve this by eliminating the code Niall borrowed from Stackoverflow, I'd prefer if Vicente adopted Andrey's solution instead. My thanks to Andrey for acting so quickly. Glen
On Mon, Feb 19, 2018 at 10:34 AM, Dominique CHABAUD via Boost <boost@lists.boost.org> wrote:
Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive.
Side note: Everything on StackOverflow remains CC-BY-SA only. That MIT relicensing was proposed, but never went through: https://meta.stackexchange.com/questions/285711/source-code-on-stack-overflo...
Side note: Everything on StackOverflow remains CC-BY-SA only. That MIT relicensing was proposed, but never went through: https://meta.stackexchange.com/questions/285711/source-code-on-stack-overflo...
Useful to know, thank you. Half those against the change said MIT was too strong, the other half felt an explicit declaration was better. So they changed nothing. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (15)
-
Andrey Semashev -
Dom -
Dominique CHABAUD
-
Eyal Rozenberg -
Glen Fernandes -
Karen Shaeffer -
Nevin Liber -
Niall Douglas -
Paul A. Bristow -
Peter Dimov -
Philip Bennefall -
Rene Rivera -
Rob Stewart -
Tim Song -
Vicente J. Botet Escriba