UC Berkeley's Lawyers Blocking RISC-V in GCC | Hacker News Reader

UC Berkeley's Lawyers Blocking RISC-V in GCC

groups.google.com

120 pointsmynameislegion73 comments

This is annoying because it's one of several things that stops Fedora/RISC-V from going into Fedora proper, but I'm sure it'll be sorted out.

Edit: To save anyone asking, here are the other things we're waiting on:

* Upstreaming of glibc, kernel and binutils changes.

* Availability of rackable server hardware - required so we can deploy builders in the Fedora datacenter. This is obviously the biggest blocker, and likely several years away. In the interim I'm running my own build server which is currently doing a mass rebuild, but once that is finished will pick packages from the Fedora primary architecture builders and rebuild them for riscv64 (https://fedorapeople.org/groups/risc-v/)

* Upstreaming of qemu changes (happening at the moment). Not a requirement, but nice to have.

Is having physical RISC-V hardware required, or would using an fpga-based risc-v cpu or a risc-v emulator be acceptable?

The qemu support for RISC-V is being upstreamed right now and there is also the Spike RISC-V simulator that you can use. There are various soft CPUs that can be run in FPGAs too.

Thanks for giving some specific examples of risc-v emulators. I was curious if using an fpga or emulator based solution (assuming it could fit in a rack enclosure) would be acceptable for the Fedora team, or if they wanted actual bare-metal risc-v hardware.

QEMU on modern x86 is going to give _much_ better performance than an FPGA.

Only linux-user is going to be accepted upstream until the privileged spec is finalized.

I'm looking for a performant way to run RISC-V code in the next year or so. Any idea how sophisticated the QEMU emualtor is? For instance, is it JITing to X86, or interpreting? Is there low hanging fruit there on the CPU performance side?

On a related note, is throwing money at the FPGA vendors going to change the tradeoff, or is QEMU already winning against top-end hardware?

QEMU always JITs to the host, regardless of target.

QEMU JITs the code and is very performant, much faster than any FPGAs. The two lowest hanging fruit now are:

- Multithreaded TCG would let us use multiple host cores (eg allowing parallel builds). MT-TCG is a very new feature even in QEMU.

- Adding virtio 1.0 support would allow us to use much more efficient block devices.

qemu-user exists already and avoids both these issues, however we cannot use it for final builds because of concerns over incorrect building when the kernel isn't a RISC-V kernel. For preliminary test-building it is fine, and very fast on Intel Xeon host hardware.

The FPGA based RISC-V hardware that I already have is much slower, has much less RAM and is in other ways more limited than QEMU. OTOH what's missing from QEMU is virtio support.

However none of this is relevant for Fedora builders, which must be 19" rackable server hardware. This is a non-negotiable condition from the Fedora project itself, and also quite understandable because they don't want to be managing flaky dev boards. (For those interested, we solved this for armv7 initially using Calxeda hardware, and later using aarch64 hardware running in 32 bit mode).

Is there a reason you cant use cross-builds? or qemu once it has virtio?

Cross builds aren't really a supported way to build RPMs. No other architecture supported by Fedora uses cross-compilation, so it would just be an endless stream of problems and forks.

The current autobuilder is using QEMU (without virtio, but it'd be a lot easier and faster with) running on a 16 core Xeon. https://github.com/rwmjones/fedora-riscv-autobuild

But for the Fedora official builders, it's 19" rackable RISC-V real server hardware, and that's the non-negotiable condition we've been given, which I support and understand.

It'll be a few years, but it doesn't stop people using Fedora on RISC-V right now, they just have to grab the packages from a slightly different URL: https://fedorapeople.org/groups/risc-v/

I think it might go a bit the other way around. The Government of India/IIT Madras is building their SHAKTI family RISC-V SoCs. One or two of these SoCs will be server-type hardware, and I suspect they'll want to run RHEL or similar on them once they're taped out. Of course it'll be a while before they're actually deploying them en masse.

Given that it takes a while for things to get from Fedora to RHEL, starting now seems wise.

Upstreaming kernel changes is not going to happen until the privileged spec is frozen, and I expect that Linux developers will want RISC-V to switch from their personal configuration format to device trees. I already have a special bag of popcorn reserved for the occasion. :)

I think the argument about config-string has been won. The last post mentioning them from the team working on the privileged spec draft seemed to indicate a tactical retreat on the issue.

I actually thought the whole SBI thing might cause more popcorn when it comes to kernel upstreaming, though it has been pointed out to me that it's not conceptually that different to Xen hypercalls.

Do you have a pointer?

There are other things in the 1.9 privileged spec that are messy, but I hope that the next version has relatively large changes. That said, the development and discussion style is not very open, and that's a pity (and the justification for not releasing the source of the spec is lame at best).

https://listmaster.pepperfish.net/pipermail/lowrisc-dev-list...

This was cross-posted on RISC-V sw-dev, but Google Groups is failing to load for me right now.

Nice. I don't think the SBI is going to be a problem, it's similar to PowerPC RTAS for example.

Do they want feedback? On a very quick reading, it seems like it would be really nice if synchronous exceptions recorded the faulting opcode. x86 doesn't do this (except sort-of when using VM extensions), and it's annoying).

There is an ISA-dev mailing list where this is discussed (unfortunately a Google Group but you can subscribe using an email address):

https://groups.google.com/a/groups.riscv.org/forum/#!forum/i...

Subscribe links here: https://riscv.org/mailing-lists/

I'm not involved in the upstream project or ISA dev, but I would definitely welcome having heavyweight kernel developers like yourself contribute, because ultimately it will ensure that the hardware is practical. We're probably 1-2 years away from having lots of RISC-V devkits running Linux, and it'd be nice if they ran Linux really well.

I discussed this issue with a GCC developer at the LLVM Cauldron in Hebden Bridge a few weeks ago. He pointed out that although it's understandable the UC Berkeley regents balk at the idea of exclusive copyright assignment, the terms of the assignment do allow you to receive non-exclusive rights back with a 90 day notice period. Why it's structured in that way I'm not sure. I would hope there's a legal reason relating to the FSF's ability to fight copyright infringement, rather than a simple desire to discourage dual licensing.

> Copyright assignment is done so that FSF has the standing to sue for GPL violations.

Were they are a licensee authorized to make and redistribute a derivative work, they would have standing to sue for violations of the copyright on the derivative. Copyright assignment is not necessary for the FSF to have standing to sue for violations of the copyright on GCC when it incorporates the UCB-owned code.

Copyright assignment does, however, prevent UCB from having standing to sue for violations -- and I think making the FSF's standing exclusive is exactly the point.

> Copyright assignment is not necessary for the FSF to have standing to sue for violations of the copyright on GCC when it incorporates the UCB-owned code.

No, but copyright assignment is necessary for the FSF to have standing to sue on UCB-owned code (not just on derivatives), without any approval or collaboration from UCB and bypassing any discussion (whether in court or outside) on "how much" of the code the FSF owns. Making FSF's standing exclusive is not the point; making FSF autonomous is.

True; but it's not only that, I think. It simply eliminates the general problem of a GNU project being a patchwork of individual copyrights from individual contributors.

Even if those individual contributors say they are putting their piece under the GPL, in fact they might not have the right to do so. Part of the process is getting some affidavit from employers that they don't claim rights over the contributor's work on the project.

They are worried about a situation like: someone suddenly coming forward and and claims that some significant piece that was added to some GNU project five years ago (and has grown in scope since then) is actually their proprietary IP.

I went to Berkeley and I still drop by to sit in on lectures.

The IP department has always been terrible to deal with. They really are the opposite of Stanford with regards to IP. A pain to deal with, everything up front. Very hostile to startups. This probably puts SiFive in limbo.

They (the IP dept) lost a first rate EE prof (Howe) over nonsense like this. Their glory days of the BSD lawsuit are long over.

I wonder if there's statistics somewhere listing schools vs how many tech spinoffs they've created, and where the various tech schools rank on that.

Shouldn't the title be "FSF blocking RISC-V in GGC unless UC Berkeley hands over copyright"?

Right. UC Berkeley is following the letter and the spirit of the GPL here.

Actually, it is, GPL doesn't in anyway imply mandatory handover of copyrights to a 3rd party.

Yup, the problem is that Berkeley's dev work is funded by public money, which means they can't vacate their "ownership", because it's the public's.

The FSF has received copyright assignments or disclaimers in the past from a lot of universities. It shouldn't be an issue.

Isn't that code derived from GPLed code? In that case it must have a GPL license, so what are the lawyers really hung up on with copyright assignment? It's not like they can change the license due to owning the copyright, and they can't prevent anyone else using the code they've already released under that license. I guess I can see the frustration - at this point the actual ownership is kind of a minor point.

Yes the code is under GPL. The FSF wants copyright assigned to it, because that allows them to sue people that infringe the GPL [1]. This assignment is the precondition for the code to get included into GCC, but which the lawyers at Berkley don't seem to be so fond of.

Owning the copyright also allows you to dual license the code under different licenses. That's not really the issue here with the FSF, but it's one of the many good reasons not to assign copyright to other entities.

[1]: https://www.gnu.org/licenses/why-assign.html

Thanks for pointing this out. I remember reading somewhere that a GPL license means that the creator still holds copyright (even though the work can be used by anyone). Having to assign copyright to the FSF gave me a WTF. This clears it up.

> The FSF wants copyright assigned to it, because that allows them to sue people that infringe the GPL

But that's not at all true: they can sue people that violate the copyright on the derivative work incorporating the UCB-owned code (or code derived from it in the future) if they are properly licensed to create a distribute derivative works, which have their own copyright.

Assignment just means UCB loses the right to sue over violations of the copyright, and the FSF's right to sue becomes exclusive -- which also gives FSF stronger negotiating power in settling lawsuits, since otherwise settling with the FSF would potentially leave others with legal claims.

Imagine all the good we developers and artists could do, if there weren't so many goddamn lawyers in the way.

How much work are we talking about here? Is it possible to do a clean-room implementation with reasonable effort?

Might a fix be to lobby the California state legislature to assign copyright through statute?

Dear Regents of the University of California:

Could you guys someday learn to get out of your own way?

Well, I think most organizations would be uncomfortable handing over their IP rights to third parties. Didn't the FSF make an exception to this rule for another developer?

Also, why can't they use Clang/LLVM? That uses the BSD license as far as I know.

There is risc-v support for llvm too, but they want it to be upstream in gcc too, as lots of things use or need gcc.

UC does not really have IP rights under the CA Constitution. At least, not any right that prevents a person from speaking freely.

UC cannot enforce copyright, NDAs, or other restrictions of speech. I think there is a very good argument that UC is unable to enforce (or even hold) a patent.

> Article 1, Section 2 (a). Sentence 2 http://www.leginfo.ca.gov/.const/.article_1

Then why is there such a big battle over CRISPR patents?

I'm not familiar with the case, but UC has acted outside the Constitution in the past.

Can they not exploit IP by transferring rights to another entity? If they cannot transfer rights to another entity then it's going to be tricky for them to do it for the fsf.

How can they transfer rights they do not have?

Do you have any other links supporting this claim, such as court decisions.

Check out Article 9, Section 9: http://www.leginfo.ca.gov/.const/.article_9

I'm not sure of any court decisions. Someone would need to be restricted by the University and challenge it to produce a case. I don't know if that has happened yet.

Are you sure that link says what you think it does?

""" (f) The Regents of the University of California shall be vested with the legal title and the management and disposition of the property of the university and of property held for its benefit and shall have the power to take and hold, either by purchase or by donation, or gift, testamentary or otherwise, or in any other manner, without restriction, all real and personal property for the benefit of the university or incidentally to its conduct; provided, however, that sales of university real property shall be subject to such competitive bidding procedures as may be provided by statute. Said corporation shall also have all the powers necessary or convenient for the effective administration of its trust, including the power to sue and to be sued, to use a seal, and to delegate to its committees or to the faculty of the university, or to others, such authority or functions as it may deem wise. """

Yes.

What is the purpose of that wall of text you pasted?

Intellectual Property is not real property but it's still property.

Restricting speech is restricting speech and UC is not allowed to do it.

The citation you provided does not constitute evidence for any of your claims. Copyright is not related to freedom of speech or of press.

Copyright is a restriction on both speech and press. And, it would be occurring by a Trust established by the CA Constitution if UC ever enforced such a restriction.

Which is prohibited.

> Copyright is a restriction on both speech and press.

Were that so, it would be prohibited by the First Amendment.

The California state protection of speech from government interference has similar scope, and does not prohibit copyrights, nor does it prohibit the state or subordinate public entities of or within the state from either enforcing state copyright law (which exists) or exercising copyrights that they own.

The California Constitution is extremely clear. No one may restrict the freeness of anyone's speech and especially not any law.

If UC uses its lawful property ownership powers (or any other) to restrict someone's speech, it has acted contrary to the CA Constitution.

I'll just leave this here.

>CALIFORNIA CONSTITUTION

>ARTICLE 1 DECLARATION OF RIGHTS

>SEC. 2. (a) Every person may freely speak, write and publish his or her sentiments on all subjects, being responsible for the abuse of this right. A law may not restrain or abridge liberty of speech or press.

> UC does not really have IP rights under the CA Constitution.

Yes, it does. IP is a subset of personal property (more specifically, a subset of intangible personal property) and the Regents of the University of California have the "power to take and hold, either by purchase or by donation, or gift, testamentary or otherwise, or in any other manner, without restriction, all real and personal property for the benefit of the university or incidentally to its conduct". Art. IX, Sec. 9(f). [0]

[0] http://www.leginfo.ca.gov/.const/.article_9

UC cannot restrict speech, so the fact that something is its property is merely the formality of the public's ownership.

A university is not "most organizations".

How do you think US universities make their money these days? A lot of it comes from IP.

Which is really annoying if they are funded, even partially, by the government.

Just because a VC funds your company, should it own everything you make? And the government encourages the practice. Both because it reduces funding requirements, and because it creates an incentive for professors and students to take the IP and commercialize it.

https://en.wikipedia.org/wiki/Bayh–Dole_Act

Where is the difference between transferring copyright to the FSF and selling IP (including transferring copright) to some commercial vendor?

Not exactly the university's fault if state keeps cutting funding.

As much as I agree with the sentiment, the state keeps cutting funding to UC, and big projects in many departments (especially CS/EECS) are funded by industry.

So, where do we stop? Should we seize all of Stanford's IP too?

I'd love it if UC got 100% of its funding from the state, and 100% of the produced IP was owned by its inventors (students, profs, etc), but California's voters strongly disagree.

The LLVM risc-v backend is currently getting reimplemented by Alex Bradbury: http://lists.llvm.org/pipermail/llvm-dev/2016-August/103748....

Thanks for the note. I've got a lightning talk at the upcoming November LLVM Dev meeting where I'll give an update (and should be refreshing my patches and updating on the llvm mailing list the next few days). Sadly the proposal Colin Schmidt and I put together for a RISC-V Birds of a Feather session was rejected, but I imagine there'll still be an informal discussion between a group of interested people on the "corridor track".

> the proposal Colin Schmidt and I put together for a RISC-V Birds of a Feather session was rejected

Wow, that's lame.

[See https://www.gnu.org/philosophy/essays-and-articles.html#noip concerning "IP", and https://www.gnu.org/licenses/why-assign.html (by a lawyer) concerning copyright assignment. Note the obligations on the FSF in the assignment contract.]

Organizations that design(ed) CPUs with copyright papers on file with the FSF for GCC include AMD, ARM, IBM, Intel, MIPS, and Sun; others include Apple, Microsoft, and Samsung.

The licence involved is orthogonal to copyright assignment.

Port to clang. Lawyer friendly and practical license

Reply on news.ycombinator.com