>To be among the first to use an open source, RISC-V CPU in a regular computer? A portable one, no less?! To be a pioneer of a more open hardware future? That sounds like an absolute privilege.
Is this an actual open source processor? I can't find any info on it either way. A lot of the conversation around RISC-V seems to conflate the open source nature of the ISA with the the actual implementation. Even the reference implementations are BSD licensed so people are allowed to distribute proprietary derivatives to say nothing of completely proprietary implementations.
If all or most of the implementations are propriety, I feel like it is a mostly lateral move from ARM as, although it is not open source, the ARM ISA is readily available [1], and the same kinds of rarified CPU engineering and academic circles that will have influence in the RISC-V Foundation, already influence ARM.
They just open-source a light version of the C906, the OpenC906.
For instance OpenC906 does not contain the vector extension.
But even the OpenC906 is only partially open-source.
They only disclosed verilog code generated by an internal tool, so the real design source code is not open.
Worse, they don't open source testbenchs which makes any modification or verification very tedious.
All software will use V once it is available. Any operation done in a loop over fixed size elements can have V applied to it. It is much more powerful than SIMD.
I must admit, I've yet to find a performance relevant loop that I can't do in simd that doesn't also have dependencies on previous iterations such that no magic instruction set is going to help unless it's capable of time travel.
LLVM's Polly[0] can often do magic there, by renumbering[1] the iteration space.
Where variable vector length instructions help is decoupling the chunk size from the machine code, because they take care of the remainder that doesn't fit in whole vectors/chunks in an agnostic fashion.
It's so you can get at least most of the gains from wider vector units without needing to change the code.
Right, but portable code != portable performance. See also: OpenCL.
There's also the observation "keep simd vectors small but many" (e.g. Apple's arm chips) over "super long vectors" (intel avx512) is superior as it is much more flexible whilst delivering similar performance for tasks that are amenable to larger vectors. Having an architecture pushing towards the latter seems a retrograde step to me.
BSD license absolutely is "free software" in the FSF sense. The four freedoms are guaranteed by it, and it is even listed explicitly in their list of free software licenses.
Four my reading of the four freedoms, none of these apply to BSD code.
> FREEDOM 0: This says that the user has the right to use the software as well as according to his/her needs.
Code containing BSD licensed components doesn't guarantee this to the user, since they are typically further constrained by EULAs and the like.
> FREEDOM 1: This says that the user can study the working of the software and make changes to meet his/her requirements to have the desired results. Here to make changes to a program, having its source code is a precondition.
Code containing BSD licensed components don't require giving the user the source.
> FREEDOM 2: This says that the user has the right to redistribute the copies of the software to help out others that may require the same.
Code containing BSD licensed components commonly restricts users from redistrbuting.
> FREEDOM 3: This is an extended version of Freedom 2 which says that the user can also provide others with copies of the software in which they’ve made modifications by doing this the developer allows the community an opportunity to benefit from his/her changes. Also, having its source code is a precondition here as well.
Once again, code containing BSD components frequently doesn't grant the user access to the source.
Source code which is presented under the BSD license satisfies the Four Freedoms.
Compiled binaries derived in whole or in part from BSD-licensed source do not on their own satisfy the Four Freedoms.
You need the source. But if you have the source, that's sufficient.
> Code containing BSD licensed components doesn't guarantee this to the user, since they are typically further constrained by EULAs and the like.
Source code which is available under a BSD license is available under BSD, full stop. If the software is constrained by a EULA, then it's not actually BSD-licensed.
If you are the copyright holder, you might also issue the software under another license. But there's not much point to dual licensing when one of the licenses is BSD — a downstream user only has to satisfy the minimal requirements of the BSD license to keep their license to use the software, and they need not satisfy more onerous requirements to get a second license to use the same software.
> Code containing BSD licensed components don't require giving the user the source.
If you have the source, you have the source. The requirement is already satisfied.
The BSD license doesn't guarantee you access to modifications, or to other code used alongside the BSD-licensed code. But that's not what's at issue — that's a copyleft requirement, not a Free Software requirement.
> Once again, code containing BSD components frequently doesn't grant the user access to the source.
It is true that the provider of a proprietary binary which incorporates BSD code is not required to provide you the source code that they used. But again, that's not what's at issue.
These arguments advocate for strong copyleft licenses, which are a subset of Free Software.
> Source code which is available under a BSD license is available under BSD, full stop. If the software is constrained by a EULA, then it's not actually BSD-licensed.
It says "software", not source code. You can have software that is BSD licensed and not have source available. The BSD license says that redistributions of source code are permitted, but not that source is made available to you.
> Copyright (c) <year>, <copyright holder> All rights reserved.
> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
> Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
> Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
> All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the <copyright holder>.
> Neither the name of the <copyright holder> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
> THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Nowhere grants you source code access. It only says that you are allowed to redistribute the source should you gain access to it. So I can write a BSD licensed program, simply give no one source and only binaries, and that's allowed.
Additionally, incorporating BSD licensed code into a proprietary work does not grant you the ability to relicense the BSD code. It's partially BSD licensed, and you as the distributed of the combined BSD proprietary work aren't compelled to give source.
> If you are the copyright holder, you might also issue the software under another license. But there's not much point to dual licensing when one of the licenses is BSD — a downstream user only has to satisfy the minimal requirements of the BSD license to keep their license to use the software, and they need not satisfy more onerous requirements to get a second license to use the same software.
No, you don't get to relicense the combined work. The BSD components remain BSD licensed.
Nope. The BSD license does not guarantee source to users. It's very free in that it places minimal restrictions what can be done with, but it doesn't guarantee the four freedoms to people who (for instance) receive binaries of modified works.
I'm not saying it's bad because of this, I don't want to start a flame war here.
It's hardly just my opinion, there's a lot of opinion out there on the web that agrees with me. It's very hard to see how this definition on the OSI site -
"Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably downloading via the Internet without charge"
Fits licenses like BSD/MIT license which do not require source access to be provided.
And the FSF say this -
"To decide whether a specific software license qualifies as a free software license, we judge it based on these criteria to determine whether it fits their spirit as well as the precise words"
So they give themselves pretty loose rules for inclusion there. I would say that the BSD license, with its very few restrictions, is definitely open source and its spirit is all about freedom. But I really don't see that it supports the four freedoms, specifically freedom 2 (from the FSF site here: https://www.gnu.org/philosophy/free-sw.html) -
"The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this."
I'm sorry, what's extreme about my view? I didn't say they weren't worthwhile, nor that they weren't open source, nor that they aren't free.
Do you disagree with my evaluation above? If so how?
I'm genuinely curious because I've been unable to mentally reconcile the OSI listing BSD licenses for years now. It scarcely matters one way or the other, it's not like the OSI is the ultimate moral arbiter of all that is good and right in the world. It just seems oddly inconsistent.
I agree with FSF and OSI respective definitions of free software and open source.
I also agree with their interpretation of BSD licenses and recognition as free software and open source respectively.
The OSI (and FSF) aren't the "ultimate moral arbiters of all that is good and right in the world". They do, however, represent me, and you'll find, a majority of people who care about free and open source software.
You're, of course, free to advocate whatever you want. I would suggest directing your efforts at convincing OSI/GNU/FSF to adopt your interpretation, where BSD runs counter to the four freedoms and reclassify BSD licenses as a start.
Should that fail, you can consider starting some sort of alternative such organization. If your views are indeed shared with many, there's a good chance it can gain traction. But only if that's the case.
As this is straying far into offtopic for the associated story, my end will not post further replies on this thread. I kindly request the same from yours.
> I agree with FSF and OSI respective definitions of free software and open source.
> I also agree with their interpretation of BSD licenses and recognition as free software and open source respectively.
These seem to be in conflict here, as pointed out above, and your responses to my honest questions about this are not enlightening, in fact quite the contrary - you seem to be getting annoyed and are accusing me of having some sort of agenda.
> You're, of course, free to advocate whatever you want.
I'm not advocating anything. I'm certainly not advocating reclassification of any licenses. I'm not sure why this conversation is putting your back up so much.
> my end will not post further replies on this thread.
That's probably for the best, it seems to be upsetting you.
It's not about the license really. It's just that I see no real reason why we should consider all the propriety implementations of RISC-V any materially more open source than any random ARM processor. Either way we know the ISA but little of the internals and can't practically audit or change them.
The implementation that's being talked about, C906, is actually open source.
Obviously, everybody gets a free license to RISC-V, and most implementations are proprietary. This doesn't mean there aren't any open implementations; C906 is one of many.
It's open source in that you can use the original code/design as you please in your implementation. I don't think anyone is stating that it's open source in terms of copyleft/gpl
Is this an actual open source processor? I can't find any info on it either way. A lot of the conversation around RISC-V seems to conflate the open source nature of the ISA with the the actual implementation. Even the reference implementations are BSD licensed so people are allowed to distribute proprietary derivatives to say nothing of completely proprietary implementations.
If all or most of the implementations are propriety, I feel like it is a mostly lateral move from ARM as, although it is not open source, the ARM ISA is readily available [1], and the same kinds of rarified CPU engineering and academic circles that will have influence in the RISC-V Foundation, already influence ARM.
[1] https://developer.arm.com/architectures/cpu-architecture/a-p...