Boost.SIMD only supports x86. Are there plans for ARM NEON and/or MIPS SIMD? What does Boost.SIMD currently do on unsupported platforms? Revert back to SISD?
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/ Earlier versions of the IBM POWER and PowerPC support used to be open-source as well. What does Boost.SIMD currently do on unsupported platforms? Revert
back to SISD?
Yes, likewise if you're on x86 but requesting an operation that your hardware does not support, it will still work using the best possible implementation.
On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
Will those be eventually included in Boost.SIMD, if it's accepted into Boost? This is an important point, IMO, and it should be clarified before review. If there are no plans to improve Boost.SIMD in order not to harm the commercial version then that makes Boost.SIMD significantly less attractive. Personally, I would vote for rejection in this case.
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
Will those be eventually included in Boost.SIMD, if it's accepted into Boost?
This is an important point, IMO, and it should be clarified before review. If there are no plans to improve Boost.SIMD in order not to harm the commercial version then that makes Boost.SIMD significantly less attractive. Personally, I would vote for rejection in this case.
I am sympathetic to this opinion. But strictly speaking Boost libraries if they work without error on some architecture, rather than being optimal on some architecture, then that is good enough for the portability requirement. Now, as to whether the Boost edition of the library is a loss leader for the commercial edition ... again, I am sympathetic, but if the library as presented is useful to a majority of people (and indeed a majority are on Intel), then I think it must be allowable. I certainly don't think a rejection just because of either of these two features is right. The library as presented should be judged as presented. Whether stuff is being held back or not shouldn't matter. Down the line, I hope to have some of my Boost libraries come with an open source edition with acceptable performance and guarantees, and commercial editions with much superior performance and guarantees. I think this would be a healthy development for Boost, if not pushed into silliness. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 04/08/17 16:01, Niall Douglas via Boost wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
Will those be eventually included in Boost.SIMD, if it's accepted into Boost?
This is an important point, IMO, and it should be clarified before review. If there are no plans to improve Boost.SIMD in order not to harm the commercial version then that makes Boost.SIMD significantly less attractive. Personally, I would vote for rejection in this case.
I am sympathetic to this opinion.
But strictly speaking Boost libraries if they work without error on some architecture, rather than being optimal on some architecture, then that is good enough for the portability requirement.
Well, the point of a SIMD library is to employ SIMD supported by the hardware. If I'm content with non-SIMD execution, I would probably not bother with a SIMD library. So, yes, performance is crucial for a SIMD library, and serial execution is only acceptable if a given operation is not available as SIMD in hardware, or is not *yet* supported (meaning that the support is at least planned).
Now, as to whether the Boost edition of the library is a loss leader for the commercial edition ... again, I am sympathetic, but if the library as presented is useful to a majority of people (and indeed a majority are on Intel), then I think it must be allowable.
I certainly don't think a rejection just because of either of these two features is right. The library as presented should be judged as presented. Whether stuff is being held back or not shouldn't matter.
Down the line, I hope to have some of my Boost libraries come with an open source edition with acceptable performance and guarantees, and commercial editions with much superior performance and guarantees. I think this would be a healthy development for Boost, if not pushed into silliness.
While I respect the will to commercialize people's work, I wouldn't want Boost to become an advertisement platform. Authors coming with their libraries to Boost should be committed to provide a fair and proper support of their libraries (i.e. those versions of their libraries that entered Boost). That includes adding features to their libraries that have demand in the community and are also present in commercial versions of their libraries. When that is not the case, I would rather prefer such libraries not be accepted into Boost. They can still be opensource and offered as a trial to the full product, but they should not be associated with Boost, IMO.
Down the line, I hope to have some of my Boost libraries come with an open source edition with acceptable performance and guarantees, and commercial editions with much superior performance and guarantees. I think this would be a healthy development for Boost, if not pushed into silliness.
While I respect the will to commercialize people's work, I wouldn't want Boost to become an advertisement platform. Authors coming with their libraries to Boost should be committed to provide a fair and proper support of their libraries (i.e. those versions of their libraries that entered Boost). That includes adding features to their libraries that have demand in the community and are also present in commercial versions of their libraries.
When that is not the case, I would rather prefer such libraries not be accepted into Boost. They can still be opensource and offered as a trial to the full product, but they should not be associated with Boost, IMO.
I know what you mean. But consider this. Imagine I make a toy key-value store and hand it over to Boost. It works well enough for most people. I then invest twelve months full time work into a serious key-value store which has been exhaustively tested in many major storage designs for correctness, costing me at least $150,000 to develop. I think it's highly unreasonable to expect that serious key-value store, even if 100% API compatible but just faster and better in every way to the toy store, to be released as open source until the cost of developing it is recouped from commercial licences. After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 08 Apr 2017, at 15:55, Niall Douglas via Boost <boost@lists.boost.org> wrote:
Down the line, I hope to have some of my Boost libraries come with an open source edition with acceptable performance and guarantees, and commercial editions with much superior performance and guarantees. I think this would be a healthy development for Boost, if not pushed into silliness.
While I respect the will to commercialize people's work, I wouldn't want Boost to become an advertisement platform. Authors coming with their libraries to Boost should be committed to provide a fair and proper support of their libraries (i.e. those versions of their libraries that entered Boost). That includes adding features to their libraries that have demand in the community and are also present in commercial versions of their libraries.
When that is not the case, I would rather prefer such libraries not be accepted into Boost. They can still be opensource and offered as a trial to the full product, but they should not be associated with Boost, IMO.
I know what you mean.
But consider this. Imagine I make a toy key-value store and hand it over to Boost. It works well enough for most people. I then invest twelve months full time work into a serious key-value store which has been exhaustively tested in many major storage designs for correctness, costing me at least $150,000 to develop.
I think it's highly unreasonable to expect that serious key-value store, even if 100% API compatible but just faster and better in every way to the toy store, to be released as open source until the cost of developing it is recouped from commercial licences.
After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow.
Niall I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow.
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
I've never been in that situation, but what I have in mind has pluggable storage backends with a single frontend API. So if someone wants to develop a competing backend superior to the open source one which directly competes with my commercial one, I'd say rock on. Competition is good! If on the other hand they wanted to extend or modify the frontend API in a way which severely breaks things for my commercial backend, the chances are I'd say no unless it fixes an obvious bug or problem. I would prefer a new breaking version of the library to that, which of course they are free to fork. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Sorry if this has been answered already but what is the incentive to evolve the Boost version instead of the commercial version (or both)? Boost libraries seem like they can be quite labor intensive to maintain, especially libraries targeting specific architectures; is there not a clear conflict of interest with respect to development time being split across a for-pay and a for-free version of the same library?
On 08/04/2017 16:40, Vinnie Falco via Boost wrote:
Sorry if this has been answered already but what is the incentive to evolve the Boost version instead of the commercial version (or both)? Boost libraries seem like they can be quite labor intensive to maintain, especially libraries targeting specific architectures; is there not a clear conflict of interest with respect to development time being split across a for-pay and a for-free version of the same library?
As I said, NumScale has no *short term* (first key point) intention into releasing *their own implementation* (second key point) of some architecture support. If someone want to invest time into supporting some architectures, they are free to do it and we'll give it a fair code review if they send us a pull request. Also consider that we daily end up patching the OS version because of bugs raised from the behind the pay wall. Our issues list on github is also full of stuff we want to do and we deemed that their support could be done in the OS version.
On 08/04/2017 16:07, Thijs (M.A.) van den Berg via Boost wrote:
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
Such case already happen, we have a bunch of contributors sending us patches and we treat the PR fairly. As I said earlier, the effort into adding the full support for a given arch can be non-trivial but if the PR is good enough, we'll give it an actual look and see if it is indeed worth merging. As for our business, be assured we don't run on bSIMD licence only ;)
Thijs (M.A.) van den Berg wrote:
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. ... So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
As Joel has stated later in this thread, it's not their intention to do so, and (IIUC) they already take patches to the OS version that adds support for things from the closed source version. He also mentioned that bSIMD licensing is not their only way of making money on their work. Is the concern here that Joel/NumScale might not be able to stick to this policy in the future? Would people be less concerned if the library had other maintainers with no commercial interest in bSIMD? -- View this message in context: http://boost.2283326.n4.nabble.com/simd-Hardware-support-tp4693499p4693544.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
On Sat, Apr 8, 2017 at 11:37 PM, Bryce Adelstein Lelbach via Boost <boost@lists.boost.org> wrote:
Thijs (M.A.) van den Berg wrote:
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. ... So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
As Joel has stated later in this thread, it's not their intention to do so, and (IIUC) they already take patches to the OS version that adds support for things from the closed source version. He also mentioned that bSIMD licensing is not their only way of making money on their work.
I think there are two issues raised in the discussion: 1. Licensing and IP issues. While Joel's statements in this thread are reassuring, I don't know his position in NumScale and whether he represents the company's official position. I don't know what exact steps need to be taken to resolve this matter, but probably there needs to be an official (likely, off-list) exchange between NumScale and Boost/SFF representatives. After that is done, this unpleasant issue can be put to rest. 2. Whether Boost.SIMD will be properly maintained after acceptance given the commercial version. Things are less optimistic on this front - no concrete plans on supporting other architectures, but at least Joel promises to give fair consideration to pull requests. Whether that is acceptable or not the review will show. #1 is critical. Without it being done there's nothing to review.
Is the concern here that Joel/NumScale might not be able to stick to this policy in the future?
I don't want to put mistrust on Joel, but NumScale is a commercial company, so we can't deny the possibility.
Would people be less concerned if the library had other maintainers with no commercial interest in bSIMD?
I think that would be ideal.
On 08/04/2017 23:57, Andrey Semashev via Boost wrote:
2. Whether Boost.SIMD will be properly maintained after acceptance given the commercial version. Things are less optimistic on this front - no concrete plans on supporting other architectures, but at least Joel promises to give fair consideration to pull requests. Whether that is acceptable or not the review will show.
Another point that occur to me is that: how much different is this situation than with other existing library that has a different pace of updates (like ASIO for ex.) than regular Boost and for which the asymmetry between the current version in boost and the current free standing version may be large but get fixed at some later point ? In both case we have a software that lives following its own agenda then get merged back into boost at some (ir)regular intervals.
2. Whether Boost.SIMD will be properly maintained after acceptance given the commercial version. Things are less optimistic on this front - no concrete plans on supporting other architectures, but at least Joel promises to give fair consideration to pull requests. Whether that is acceptable or not the review will show.
I see no evidence, nor any reason, why SIMD would be maintained worse than any library maintained in someone's spare time outside of work. If anything, being related to a commercial product means that bug fixes and improvements would land more frequently and timely.
#1 is critical. Without it being done there's nothing to review.
I'd tend to agree with Robert's view on this. If it's under the Boost licence, then it's just like any other library. If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
Would people be less concerned if the library had other maintainers with no commercial interest in bSIMD?
I think that would be ideal.
I see no inherent difficulty here, and as I have mentioned I think commercial extensions of Boost libraries is a thing to be encouraged maybe. I also think that people who have never gone out and sold their code directly for money think there is more risk of "commercial taint" than there actually is. I can assure you that most of my clients will not touch any code written nor designed in recent years - they hate being guinea pigs, or getting locked into niche technologies which cause future problems for maintenance. Indeed, most clients I have worked for use a version of Boost at least two years old precisely avoid surprises. A funny thing is that I have never used a single line of my Boost-like code ever in any work done for clients. Too risky and experimental. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 9 April 2017 at 09:30, Niall Douglas via Boost <boost@lists.boost.org> wrote:
If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it. AFAIK the Boost Software License requires keeping the copyright notices of any work it is derived from, so this is a violation of the BSL. Boost.SIMD is derived from the NT2 library which was a BSL-licensed collaboration between various parties. I warned NumScale about this a few years ago, but they dismissed it.
On 4/9/17 5:29 AM, Mathias Gaunard via Boost wrote:
On 9 April 2017 at 09:30, Niall Douglas via Boost <boost@lists.boost.org> wrote:
If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it.
I'm not a lawyer. The Boost license was vetted very carefully by specialized legal counsel. No one has yet raised the possibility that a license, once granted, could be revoked. So whatever NumScale were to do in the future, would not affect Boost.
AFAIK the Boost Software License requires keeping the copyright notices of any work it is derived from, so this is a violation of the BSL.
This is not clear to me from reading the actual license. http://www.boost.org/users/license.htmlhttp://www.boost.org/users/license.ht...
Boost.SIMD is derived from the NT2 library which was a BSL-licensed collaboration between various parties.
I have not idea what a "BSL-licensed collaboration" is Robert Ramey
On 9 April 2017 at 17:21, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 4/9/17 5:29 AM, Mathias Gaunard via Boost wrote:
On 9 April 2017 at 09:30, Niall Douglas via Boost <boost@lists.boost.org> wrote:
If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it.
I'm not a lawyer. The Boost license was vetted very carefully by specialized legal counsel. No one has yet raised the possibility that a license, once granted, could be revoked. So whatever NumScale were to do in the future, would not affect Boost.
They cannot be revoked. My understanding was that we were discussing the possibility that Boost.SIMD could also be licensed under a license providing stronger guarantees than the Boost Software License so as to better protect the end user.
AFAIK the Boost Software License requires keeping the copyright notices of
any work it is derived from, so this is a violation of the BSL.
This is not clear to me from reading the actual license.
http://www.boost.org/users/license.htmlhttp://www.boost.org/ users/license.html
That's pretty clear to me. Attribution of ownership (aka copyright notices) must be preserved in source form, but not compiled form. The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.
I have not idea what a "BSL-licensed collaboration" is
I'm not sure what's confusing here, but let me rephrase if that helps. "A work developed by various parties working together and licensed under the Boost Software License." The NT2 library had copyright notices attributing ownership to LRI and LASMEA -- two French public research laboraties -- in addition to NumScale; those copyright notices should have been preserved. The latest version of Boost.SIMD attributes ownership to NumScale exclusively.
If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
The library only has NumScale copyright notices, so they claim ownership of the library, and could re-license it.
They could relicence *subsequent editions* of it, but not any already released edition. Just the same as Oracle made subsequent editions of ZFS proprietary, but could not retract the licence for already released editions.
AFAIK the Boost Software License requires keeping the copyright notices of any work it is derived from, so this is a violation of the BSL. Boost.SIMD is derived from the NT2 library which was a BSL-licensed collaboration between various parties.
I warned NumScale about this a few years ago, but they dismissed it.
It would be highly common for a software startup being spun out of a university to have the ownership of any relevant IP held by the university transferred or sold to it. Because the startup owns the copyright, and is not a licensee, it can do anything it likes with the copyrighted IP, including deleting any text such as prior copyright notices. You only need preserve licence notices where the licence you are placed under demands it because you don't own the IP and can't do whatever you want. Now, as to whether misrepresenting the provenance of software is moral or not is another question, but if you own the IP, it's legal. And it is certainly common in the industry, one contract I had with a household name multinational had me convert a third party software library over to eliminate all evidence of its true origin. They had bought a full owning copy from the IP originators, which is also possible BTW, but now it was theirs it laboriously needed to be made to look so. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
They had bought a full owning copy from the IP originators, which is also possible BTW, ...
Not necessarily. It's possible under American copyright law, not possible under at least some European copyright laws. You can only get a full owning copy if it's work for hire (in which case you become the owner of the work). You can never get a full owning copy by buying it from the owner. Ownership is fixed at the moment of creation and is not for sale. All this does not appear to be of consequence with respect to the Boost-licensed portions though.
On 9 April 2017 at 22:22, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Niall Douglas wrote:
They had bought a full owning copy from the IP originators, which is also
possible BTW, ...
Not necessarily. It's possible under American copyright law, not possible under at least some European copyright laws. You can only get a full owning copy if it's work for hire (in which case you become the owner of the work). You can never get a full owning copy by buying it from the owner. Ownership is fixed at the moment of creation and is not for sale.
That is correct, IANAL, but my understanding is that French law does not allow transfer of ownership of intellectual property, and that it stays with the author until death. In any case, I am listed as one of the main authors in legally-binding registrations of various pieces of software managed by the University of Paris-Sud, including NT2 on which this library is based on, and would have to give my agreement for any special licensing deal. This is mostly a technicality, as all of this is licensed under the Boost Software License and there are little damages to speak of, but still something that needs fixing.
On 09/04/2017 23:20, Mathias Gaunard via Boost wrote:
That is correct, IANAL, but my understanding is that French law does not allow transfer of ownership of intellectual property, and that it stays with the author until death.
Moral rights cannot be transferred in many European countries, but economic rights can be. One can also sign a contract binding you to never assert your moral rights. The end result looks very similar to outright sale or transfer of IP as under English law.
In any case, I am listed as one of the main authors in legally-binding registrations of various pieces of software managed by the University of Paris-Sud, including NT2 on which this library is based on, and would have to give my agreement for any special licensing deal. This is mostly a technicality, as all of this is licensed under the Boost Software License and there are little damages to speak of, but still something that needs fixing.
One of the big problems with the older open source licences such as the Boost licence was a lack of awareness at the time of writing of different copyright regimes outside the English law ones. Newer open source licences are much better designed in this regard, and the EU in 2009 published the EUPL licence specifically designed for maximum global compatibility. (Incidentally I really wish US-centric open source orgs would use something like the EUPL https://joinup.ec.europa.eu/sites/default/files/eupl1.1.-licence-en_0.pdf rather than their US-centric licences which are problematic outside English law jurisdictions) One might think that a lawyer in a European country could assert that due to the impermeability of moral rights, that the failure to comply with the Boost licence requirement of preservation of copyright notices is a problem, but that would only be in countries where moral rights are impermeable. The argument wouldn't fly in the US or the UK, except when applied to visual artwork. However, in Europe legal precedent holds that licences cannot impose conditions on a sale of software, where "sale" is defined to be any distribution such as a download. So as soon as a European downloads an open source library, they are free to ignore any conditions in any licence. This is probably surprising to most readers on here as it makes licences such as the GPL unenforceable in the EU, see http://www.lexology.com/library/detail.aspx?g=91b10f02-8ae0-4e2d-bd20-4bba0e.... Obviously this is a recent (2013) ruling to a specific case, but it was by the EU supreme court, so any further legal cases would likely be decided the same way. So, and stressing IANAL, I think Numscale are on solid legal ground here, at least both in the US and Europe. As a spinout from a university, I think it would be extremely unlikely that the university's legal department haven't gone through the situation with a fine tooth comb beforehand. tl;dr; I see no problem with Boost.SIMD's IP provenance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Niall Douglas wrote:
Moral rights cannot be transferred in many European countries, but economic rights can be. One can also sign a contract binding you to never assert your moral rights. The end result looks very similar to outright sale or transfer of IP as under English law.
That's not true in general. Sure you can sign a contract saying whatever, but the copyright law may say that said contract is null and void. You have to read what the specific law says. Some prohibit granting exclusive rights, some prohibit granting perpetual rights, some prohibit signing away moral rights. It's all very alien to people accustomed to English/American copyright.
On 4/9/17 1:30 AM, Niall Douglas via Boost wrote:
#1 is critical. Without it being done there's nothing to review.
I'd tend to agree with Robert's view on this. If it's under the Boost licence, then it's just like any other library.
If copyright weren't a problem, I'd suggest the Apache 2.0 licence which gives stronger guarantees to the end user (a Boost library doesn't actually have to have the Boost licence, it's just strongly recommended). But you don't own the copyright to the entire library.
When I first read this I thought it was wrong. I always thought that a boost license was a requirement for inclusion in Boost. It turns out that I been wrong about this. http://www.boost.org/development/requirements.html#License So I guess it's more correct to say that a) if a library has Boost license, fine it can be reviewed. b) if a library has a Boost Compatible license, it can also be reviewed. But it's not clear to me who determines this. I guess this would be the review wizard who decides to add (or not add) a library to the review queue. c) If a library doesn't have a Boost compatible license, it can be added to boost so there is no point to subjecting it to review. The Boost Compatible license is important because it allows users to incorporate boost code with confidence that there will likely be no legal issues arising from such incorporation. I hope that we can all agree on the above. There is one issue still pending. Suppose one submits a library with a compatible license which incorporates code which from another source in such a way that the right to use the incorporated code is in question. I'm not really sure, but it seems that Mathias has (among other things) raised this as an issue. I would guess that places the onus on Joel to explain why he feels that this is not a problem in this case and finally the review wizard will have to consider the point in his decision to accept the request to place the library in the review queue. I'm aware that decisions such of this can never be resolved definitively. It's a feature of the legal system that the more time is expended, the more it serves the system rather then the rest of us. Basically they get paid to bikeshed. That's why we like to stay away from it. But, I'm hopeful that we can get legitimate concerns addressed one way or another in an expedient way so we can all move forward. Robert Ramey
On 4/9/17 09:08, Robert Ramey via Boost wrote:
http://www.boost.org/development/requirements.html#License
So I guess it's more correct to say that
a) if a library has Boost license, fine it can be reviewed. b) if a library has a Boost Compatible license, it can also be reviewed.
But it's not clear to me who determines this. I guess this would be the review wizard who decides to add (or not add) a library to the review queue.
Legal guidance would need to be provided by the Software Freedom Conservancy's (of which Boost belongs) legal counsel.
There is one issue still pending. Suppose one submits a library with a compatible license which incorporates code which from another source in such a way that the right to use the incorporated code is in question. I'm not really sure, but it seems that Mathias has (among other things) raised this as an issue. I would guess that places the onus on Joel to explain why he feels that this is not a problem in this case and finally the review wizard will have to consider the point in his decision to accept the request to place the library in the review queue.
I'm aware that decisions such of this can never be resolved definitively. It's a feature of the legal system that the more time is expended, the more it serves the system rather then the rest of us. Basically they get paid to bikeshed. That's why we like to stay away from it.
But, I'm hopeful that we can get legitimate concerns addressed one way or another in an expedient way so we can all move forward.
I'll be contacting the Conservancy's counsel to help navigate this. I'm primarily concerned as member of the steering committee and secondarily concerned as the review manager. michael -- Michael Caisse Ciere Consulting ciere.com
On 04/08/17 16:55, Niall Douglas via Boost wrote:
Down the line, I hope to have some of my Boost libraries come with an open source edition with acceptable performance and guarantees, and commercial editions with much superior performance and guarantees. I think this would be a healthy development for Boost, if not pushed into silliness.
While I respect the will to commercialize people's work, I wouldn't want Boost to become an advertisement platform. Authors coming with their libraries to Boost should be committed to provide a fair and proper support of their libraries (i.e. those versions of their libraries that entered Boost). That includes adding features to their libraries that have demand in the community and are also present in commercial versions of their libraries.
When that is not the case, I would rather prefer such libraries not be accepted into Boost. They can still be opensource and offered as a trial to the full product, but they should not be associated with Boost, IMO.
I know what you mean.
But consider this. Imagine I make a toy key-value store and hand it over to Boost. It works well enough for most people. I then invest twelve months full time work into a serious key-value store which has been exhaustively tested in many major storage designs for correctness, costing me at least $150,000 to develop.
I think it's highly unreasonable to expect that serious key-value store, even if 100% API compatible but just faster and better in every way to the toy store, to be released as open source until the cost of developing it is recouped from commercial licences.
After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow.
I can understand if you want to keep certain features in the closed-source version to return the costs and make profit. But that shouldn't impede the Boost version from evolving. If that feature has high demand, I would expect it to eventually appear in the open-source version. If soneone offers a patch implementing that feature, I would expect you to give a fair consideration of it, even if it makes things differently to your closed-source code. What I wouldn't expect or want to see is the author referring the community to the commercial version instead. I'd like to make myself clear. I'm absolutely not against people making money on the software they write. But at the same time, if those people come to Boost I think they should be aware and committed to Boost and open-source community. If there is a chance of a conflict between making profit and commitment to opensource, I'd rather them avoid that conflict by not coming to Boost in the first place.
After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow.
I can understand if you want to keep certain features in the closed-source version to return the costs and make profit. But that shouldn't impede the Boost version from evolving. If that feature has high demand, I would expect it to eventually appear in the open-source version. If soneone offers a patch implementing that feature, I would expect you to give a fair consideration of it, even if it makes things differently to your closed-source code. What I wouldn't expect or want to see is the author referring the community to the commercial version instead.
I'd hope to allow competition. But if you think developing high quality C++ code is expensive, then developing high quality storage code is considerably more so. I think recouping the cost of development is very reasonable, after which it can be open sourced.
I'd like to make myself clear. I'm absolutely not against people making money on the software they write. But at the same time, if those people come to Boost I think they should be aware and committed to Boost and open-source community. If there is a chance of a conflict between making profit and commitment to opensource, I'd rather them avoid that conflict by not coming to Boost in the first place.
Profit and open source are not in conflict. If anything, especially in recent years, there is plenty of profit in open source. I, and many others even on here, make a living from it. I'm also mindful of Anthony Williams' Just Threads! which is effectively a v4 complete rewrite of Boost.Thread. That's a commercial product held totally separate to Boost, and it has been woefully underused because people didn't know it existed. Some would argue - and I'm not sure I include myself here - that if Just Threads! were the all new singing and dancing Boost.Thread rewrite, and if people running into problems with Boost.Thread could pay the fee for the new rewrite until its development costs were paid off, that could bring new very high quality developed for profit libraries to Boost. As I said, I'm not sure I agree with that myself, lots of slippery slopes in there. But equally I've seen old versions of big games engines released to open source after they no longer make money, and that's been a *huge* benefit to open source. So the model can work, and work very well. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 08/04/2017 16:40, Niall Douglas via Boost wrote:
I'm also mindful of Anthony Williams' Just Threads! which is effectively a v4 complete rewrite of Boost.Thread. That's a commercial product held totally separate to Boost, and it has been woefully underused because people didn't know it existed. Some would argue - and I'm not sure I include myself here - that if Just Threads! were the all new singing and dancing Boost.Thread rewrite, and if people running into problems with Boost.Thread could pay the fee for the new rewrite until its development costs were paid off, that could bring new very high quality developed for profit libraries to Boost.
Anthony's Just Thread situation was part of our inspiration for submitting Boost.SIMD as we indeed saw it as something that follow a model close to ours and looks like it works. The main difference is indeed the order of inclusion.
On 08/04/2017 15:55, Niall Douglas via Boost wrote:
But consider this. Imagine I make a toy key-value store and hand it over to Boost. It works well enough for most people. I then invest twelve months full time work into a serious key-value store which has been exhaustively tested in many major storage designs for correctness, costing me at least $150,000 to develop.
I think it's highly unreasonable to expect that serious key-value store, even if 100% API compatible but just faster and better in every way to the toy store, to be released as open source until the cost of developing it is recouped from commercial licences.
After all, the toy edition is good enough. It works. It just will come with no guarantees that it won't eat your data, and it will probably be quite slow.
And that's exactly our point. The reason of why Boost.SIMD is proposed is to give back part of it to the community we're part of. Put bluntly, NumScale has other sources of revenues (products and services) so we're above the need of using Boost as a cheap advertisement platform. It has been discussed with Michael Caisse and other people from the steering committee and has been found to not be an issue. Also note that NumScale has volunteered to act as BLOM for Boost.SIMD, which means also indirectly investing ressources into this open source endeavour. As Michael put it elegantly when we started discussing this, the current shape of Boost.SIMD submitted is what it is. It goes through a review to know if this actual piece of software is interesting enough to be included. If the lack of some hardware support is a point against, then cast your vote accordingly. I it means that this software is not into boost at the end of the review, well so be it and we'll revert to support an open source version of bSIMD renamed and outside of boost. We wont die or miss anything, the Boost community may.
On 8 April 2017 at 13:21, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
Will those be eventually included in Boost.SIMD, if it's accepted into Boost?
Being no longer affiliated with NumScale, the company behind this library, I cannot say. The original plan was to keep support for unusual and/or recent architectures proprietary, while the open-source version would get backends once the underlying technology becomes mainstream enough. In practice I would not expect much; Boost.SIMD was initially developed by a French university but is now handled by a company whose leanings towards open-source might be less open. This is an important point, IMO, and it should be clarified before review.
If there are no plans to improve Boost.SIMD in order not to harm the commercial version then that makes Boost.SIMD significantly less attractive. Personally, I would vote for rejection in this case.
I personally have severe concerns about all aspects of intellectual property surrounding that library and the people behind it. For example, when I did a talk about Boost.SIMD at a conference using nothing but open-source material, my employer received a cease-and-desist letter and was asked to destroy all material related to Boost.SIMD as NumScale claimed it was their property. My employer complied to be on the safe side. I believe that during the review we should definitely take into account how the existence of the two versions of the software can be harmful to users.
I personally have severe concerns about all aspects of intellectual property surrounding that library and the people behind it. For example, when I did a talk about Boost.SIMD at a conference using nothing but open-source material, my employer received a cease-and-desist letter and was asked to destroy all material related to Boost.SIMD as NumScale claimed it was their property. My employer complied to be on the safe side.
I believe that during the review we should definitely take into account how the existence of the two versions of the software can be harmful to users.
Eh, sorry, are you saying that anybody who uses Boost.SIMD may receive a cease and desist legal order from the people behind its commercial edition? Because if so, I think the SFF of which Boost is a part would say that means that library cannot enter Boost due to being of uncertain legal providence. I mean, a while back with Hana, there was a storm in a teacup over the fact it was named after a product by a well known multinational. That was worrying over nothing (trademarks in different domains do not conflict), but somebody actively suing users of a potential Boost library is a real concern. Also, if SIMD enters Boost and then someone adds features to it like support for ARM, will they get sued for stealing IP from the commercial edition? Because even if they demonstrably could not have stolen the IP, it's the legal costs of proving you didn't do anything wrong which can be ruinous. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 8 April 2017 at 14:49, Niall Douglas via Boost <boost@lists.boost.org> wrote:
I personally have severe concerns about all aspects of intellectual property surrounding that library and the people behind it. For example, when I did a talk about Boost.SIMD at a conference using nothing but open-source material, my employer received a cease-and-desist letter and was asked to destroy all material related to Boost.SIMD as NumScale claimed it was their property. My employer complied to be on the safe side.
I believe that during the review we should definitely take into account how the existence of the two versions of the software can be harmful to users.
Eh, sorry, are you saying that anybody who uses Boost.SIMD may receive a cease and desist legal order from the people behind its commercial edition?
That's certainly what happened to me, though I have special circumstances as I used to be affiliated with them. Your mileage may vary.
On Apr 8, 2017, at 6:49 AM, Niall Douglas via Boost <boost@lists.boost.org> wrote:
I personally have severe concerns about all aspects of intellectual property surrounding that library and the people behind it. For example, when I did a talk about Boost.SIMD at a conference using nothing but open-source material, my employer received a cease-and-desist letter and was asked to destroy all material related to Boost.SIMD as NumScale claimed it was their property. My employer complied to be on the safe side.
I believe that during the review we should definitely take into account how the existence of the two versions of the software can be harmful to users.
Eh, sorry, are you saying that anybody who uses Boost.SIMD may receive a cease and desist legal order from the people behind its commercial edition? Because if so, I think the SFF of which Boost is a part would say that means that library cannot enter Boost due to being of uncertain legal providence.
I have used Boost.SIMD in some simulations, wrote a blog post about that [1] and presented it in talks at C++ conferences [2,3]. This is about as public as one can use an OS library. So I can ensure you that using Boost.SIMD is no different then any other library in this regard. Best, Mario [1] https://www.codeproject.com/Articles/841136/Boosting-ODE-simulations-with-Bo... [2] https://www.youtube.com/watch?v=KN8MFFvRl50 [3] https://www.youtube.com/watch?v=RGQ6uYjlYR0
On 08/04/2017 20:28, Mario Mulansky via Boost wrote:
I have used Boost.SIMD in some simulations, wrote a blog post about that [1] and presented it in talks at C++ conferences [2,3]. This is about as public as one can use an OS library. So I can ensure you that using Boost.SIMD is no different then any other library in this regard.
Best, Mario
Mario's involvement was also helpful for us as it demonstrated use cases we didn't think about and lead us to some later improvements that will be available in Boost.SIMD soon. We also tried to be as helpful as possible when he started using it and I hope he found our support helpful.
On 04/08/17 16:21, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 13:21, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On 04/08/17 14:06, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
Other platforms are supported in the proprietary version of the library. https://developer.numscale.com/bsimd/documentation/v1.17.3.0/
Will those be eventually included in Boost.SIMD, if it's accepted into Boost?
Being no longer affiliated with NumScale, the company behind this library, I cannot say. The original plan was to keep support for unusual and/or recent architectures proprietary, while the open-source version would get backends once the underlying technology becomes mainstream enough.
In practice I would not expect much; Boost.SIMD was initially developed by a French university but is now handled by a company whose leanings towards open-source might be less open.
That is sad to hear. In the case that the code is not released, are you or other authors allowed (legally), able and willing to implement those backends in the opensource Boost.SIMD? By "implement" I don't mean reproducing the closed-source code but implementing the backends as your library design requires. If not you yourself, would you be willing and able to accept patches that implement that functionality, if someone else takes on the task?
This is an important point, IMO, and it should be clarified before review.
If there are no plans to improve Boost.SIMD in order not to harm the commercial version then that makes Boost.SIMD significantly less attractive. Personally, I would vote for rejection in this case.
I personally have severe concerns about all aspects of intellectual property surrounding that library and the people behind it. For example, when I did a talk about Boost.SIMD at a conference using nothing but open-source material, my employer received a cease-and-desist letter and was asked to destroy all material related to Boost.SIMD as NumScale claimed it was their property. My employer complied to be on the safe side.
I believe that during the review we should definitely take into account how the existence of the two versions of the software can be harmful to users.
If the licensing situation is indeed unclear, it probably makes sense to put the review on hold and clarify this matter with NumScale (or whoever claims rights on the library). I think the last thing anyone needs is being pulled into court. Until the licensing issue is clear, I don't think the review, let alone acceptance, should happen. (Sorry, if that sounds disappointing or harsh, but I think that is ultimately for the better for you, Boost and Boost users.)
As an additional point w/r to future improvements, the AVX2 support that is included right now in Boost.SIMD was last year still a closed component. We decided that it would make a better experience for all user of Boost.SIMD to have access to it and decided to open source it. So the question of will we do it is actually auto-answered as we did it already. So again, those release of older CS component is a thing we already did. The plan on how/when the other parts will be is not known currently but it may happen at some points provided we found out a proper plan to do so.
We have no MIPS support mostly because lack of time and platform access, patch welcome. NEON support is indeed part of bSIMD, NumScale's proprietary software on which the proposed Boost.SIMD library is extracted from. There is, for now, no short term plan to release the ARM support as Open Source software. And let's be clear : to release the ARM support *NumScale developed*. If a pull request came in with some support for ARM and the quality was good enough in term of performances and coverage of function, I guess it'll go through a regular review process. On 08/04/2017 12:14, Bjorn Reese via Boost wrote:
Boost.SIMD only supports x86.
Are there plans for ARM NEON and/or MIPS SIMD?
What does Boost.SIMD currently do on unsupported platforms? Revert back to SISD?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
A thread which deals with ... lot's of stuff ... related to a particular library SIMD proposed for Boost. This stuff relates to legal issue related to to usage, provinence, and future maintainence and direction of the library. I think we would be better off focusing an one simple question: Does the proposed library include the Boost License. If it does, fine. If it doesn't it can't be a boost library and hence there is no need for a review. Robert Ramey
On 08/04/2017 19:08, Robert Ramey via Boost wrote:
A thread which deals with ... lot's of stuff ... related to a particular library SIMD proposed for Boost. This stuff relates to legal issue related to to usage, provinence, and future maintainence and direction of the library.
I think we would be better off focusing an one simple question:
Does the proposed library include the Boost License. If it does, fine. If it doesn't it can't be a boost library and hence there is no need for a review.
Robert Ramey
Thank Robert to bring the discussion on track.
On 04/08/2017 01:06 PM, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
What does Boost.SIMD currently do on unsupported platforms? Revert
back to SISD?
Yes, likewise if you're on x86 but requesting an operation that your hardware does not support, it will still work using the best possible implementation.
Is there any run-time overhead (e.g. induced by pack, load, save, etc.) in the SISD case?
On 10/04/2017 14:44, Bjorn Reese via Boost wrote:
On 04/08/2017 01:06 PM, Mathias Gaunard via Boost wrote:
On 8 April 2017 at 11:14, Bjorn Reese via Boost <boost@lists.boost.org> wrote:
What does Boost.SIMD currently do on unsupported platforms? Revert
back to SISD?
Yes, likewise if you're on x86 but requesting an operation that your hardware does not support, it will still work using the best possible implementation.
Is there any run-time overhead (e.g. induced by pack, load, save, etc.) in the SISD case?
This is a case we don't benchmark much but the strategy is to statically unroll the scalar calls over the pack element which are store din an std::array. So I suspect the overhead is not worth than having called the scalar function Nth times.
participants (13)
-
Andrey Semashev -
Bjorn Reese -
Bryce Adelstein Lelbach -
degski -
Joel FALCOU -
Mario Mulansky -
Mathias Gaunard -
Michael Caisse -
Niall Douglas -
Peter Dimov -
Robert Ramey -
Thijs (M.A.) van den Berg -
Vinnie Falco