Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Public and private sharing, open source hardware, limitations to vendor access
I'm interested in open source hardware, and in particular the possibility of sharing designs using an open source license that requires downstream sharing of changes, because of the impact that this has on innovation. This comment details the potential shared interest in Onshape features that open hardware fans may have with proprietary designers who are concerned about the degree to which vendors may have access to their shared files.
I've discussed the legal mechanics in this blog post, but the short story is that there may be a route to open source licensing for physical designs in a cloud-based CAD package like Onshape. This is simply because of the mechanics of cloud-based CAD, and the fact that a copy of the CAD file is created in RAM every time the design is accessed (I think the same thing may be true of STL files. Check out this Git repository where you can examine the changes I made in an STL file using Meshmixer).
Here's where the open source folks may have strange bedfellows in proprietary designers who are concerned about what happens to their IP when they share their designs with manufacturing vendors, likely overseas, whom they may not trust enough to hand over the full set of keys. Open hardware folks have the same concerns when they share a design publicly using Onshape, and for some of the same reasons. Once a design is shared publicly, without restriction, it becomes public domain, and anyone can do whatever they choose with it. A user can make a private copy of a public onshape document, make changes, profit from them, and not share the changes. This is exactly the type of activity that proprietary designers want to avoid in their vendors.
If either group could attach a license to the design that they share with anyone else, and at the same time limit the pathways out of Onshape that the user might take--for example only letting a user create an STL file or G-code generated with a plug-in--then each group might be better able to preserve their rights. The goals that each of these groups in asserting those rights are very different--one group wanting to closely hold access, while the second wanting to preserve it indefinitely--but the mechanism is the same.
In each case, copyright law can form the basis of the license that the user can grant others, and what copyright law calls the "essential step" of creating a copy of the file in computer RAM each time the file is accessed in Onshape is the key to the effectiveness of those licenses.
I hope that as Onshape develops further that the option to attach licenses to designs created in Onshape, and the automatic attachment of appropriate permissions and limitations that serve to enforce and protect the downstream use of these designs gets baked into Onshape.
I've discussed the legal mechanics in this blog post, but the short story is that there may be a route to open source licensing for physical designs in a cloud-based CAD package like Onshape. This is simply because of the mechanics of cloud-based CAD, and the fact that a copy of the CAD file is created in RAM every time the design is accessed (I think the same thing may be true of STL files. Check out this Git repository where you can examine the changes I made in an STL file using Meshmixer).
Here's where the open source folks may have strange bedfellows in proprietary designers who are concerned about what happens to their IP when they share their designs with manufacturing vendors, likely overseas, whom they may not trust enough to hand over the full set of keys. Open hardware folks have the same concerns when they share a design publicly using Onshape, and for some of the same reasons. Once a design is shared publicly, without restriction, it becomes public domain, and anyone can do whatever they choose with it. A user can make a private copy of a public onshape document, make changes, profit from them, and not share the changes. This is exactly the type of activity that proprietary designers want to avoid in their vendors.
If either group could attach a license to the design that they share with anyone else, and at the same time limit the pathways out of Onshape that the user might take--for example only letting a user create an STL file or G-code generated with a plug-in--then each group might be better able to preserve their rights. The goals that each of these groups in asserting those rights are very different--one group wanting to closely hold access, while the second wanting to preserve it indefinitely--but the mechanism is the same.
In each case, copyright law can form the basis of the license that the user can grant others, and what copyright law calls the "essential step" of creating a copy of the file in computer RAM each time the file is accessed in Onshape is the key to the effectiveness of those licenses.
I hope that as Onshape develops further that the option to attach licenses to designs created in Onshape, and the automatic attachment of appropriate permissions and limitations that serve to enforce and protect the downstream use of these designs gets baked into Onshape.
1
Comments
The design team in America licensed standard components like an ARM core, SRAM, DDR controller, and ethernet interface. We did not have complete designs for all of these. If not, we had software models. I knew if I asserted read enable while providing an address, I would get data out on the next clock. The simulation would show me that much. I could not trace the address decode logic to see how this miracle occurred. The SRAM block was effectively a black box. We had to be careful to say exactly what parameters would be used to instantiate this black box. For example, did we want single ported memory, 1 read + 1 write but only to different addresses, or 1 read + 1 write with bypassing for simultaneous access to the same address?
Physical layout and fabrication was all done in China. Payment of royalties for the "IP" was verified somewhere along the way. The IP worked as advertised.
Two key differences: there are not as many fabs as there are machine shops, and it costs on the order of a million dollars to get a chip made. The first makes it harder to cheat, and the second lessens the incentive to cheat over a relatively small amount of money.
This is an area of focus for us, and we are looking at ways to make it easy for Onshape users to assign and reserve rights.
In the meantime, the 5 cent solution might be as simple as creating a new tab that contains the license terms. (And the text can be generated, for example, from here: https://creativecommons.org/choose/)
This is definitely an OS question.
But, I've got to chime in.
I don't see Onshape adding anything to the issue of public vs. private that isn't already out there. If I'm designing something that is patent pending I won't make it public. I won't post images or talk about it in public. None of this has anything to do with Onshape.
"Derived works using open source files", because I use a bolt in my design that I downloaded from McMaster, that makes my design open source? That's a sick concept, and once again, this has nothing to do with Onshape. We need less lawyers bringing these suits into court.
I worry more about that yo-yo who patented cloud storage and just won a suit against apple. Hopefully our justice system corrects these errors and doesn't render the cloud useless.
I don't get why you think Onshape has a dog in this fight.
I'm an engineer not a lawyer, can you please give me a simple example why this matters?
Are you looking to design something using public resources yet retain the rights of your design and IP?
After 25 years of engineering and signing 100's of NDAs, I never saw that one coming. That breaks rule #1 for patent filing saying it can't be in the public domain. How do you get public support and at the same time retain IP rights? I think this is what your post is about.
Onshape is going to be a great place for you to hang out, should be plenty of good resources for you here.
As a creator of IP, a designer who intends to file for a design patent needs to take dated notes (outside of OS), and submit them with the application. Ultimately it could be the difference between getting protection or not in the case when two companies are filing for conflicting patents without the existence of any prior art.
In the case of a utility patent, the claims encompass not only the physical appearance, but also the functionality. As a CAD tool, OS defines the former, but not the latter.
My two cents.
Linked[in]
I find this whole topic really interesting. I had to read Jon's blog post to really understand what he was getting at and I highly recommend anyone else skimming this thread to go read it here.
Disclaimer: I am not a lawyer.
I spend a lot of time on both open source contributions and proprietary hardware and I expect to contribute to open hardware in the future, so treat the following as introspection rather than bashing.
Open source licenses are fascinating to me because, unlike releasing a work to the public domain, the author is trying to assert their will on those consuming their work. "I'll give you a gift, but only if you let me put you in an arm lock." The different flavors of compulsion in open source licenses leads to churn between them as authors try to figure what's important to them individually. Churn between GPL style "join my vision of utopia" and BSD style "here ya go, BTW my ass is covered" seems to happen a lot. My own opinion is that the licenses with a social mission (like the GPL) contribute less to society than other FOSS licenses.
Regarding hardware, I don't think open source licenses are a good place to start. I think that any creator that wants to impose their will on anyone downstream, deriving from or mashing-up their "open hardware" work, should just use contract law. Contracts are negotiated agreements while source code licenses derive their strength from copyright law and may or may not be contracts depending on context. Contract law is well established, can accomplish the task, and in my opinion, fits the spirit of what a creator wants to accomplish better. The main issue being that there must be an agreement between parties to the contract, and that takes more effort than just throwing a license in the general direction of someone.
One nice thing about open source code is its accessibility; how easy it is to get a hold of, experiment with, and try out. I think this is also key for open hardware. The interaction between the parties a contract requires is potentially a roadblock in distributing the open hardware, but I think that technology can help here. Specifically using digital signatures to establish unquestionably who is party to the contract and what the terms of the contract are. I think that with the right use of technology for distributing terms and collecting signatures, hardware designs can be shared with little friction to large numbers of people, under contract terms that suit the original creator.
I think for myself, in most cases a public domain release of hardware is the only one that makes sense. If some other company picks up the design and figures out how to make millions off it, that is exactly the goal. The point of releasing the design is so that others can benefit from it. If it's really important to you that only a specific subset of people benefit, stop whining and go do the hard work it takes to make that happen.
Meanwhile thinking about licenses and contracts always brings me back to the same point. I'm always aware that law is a provincial or national phenomena in this international world of business and that justice, and the lawyers required to seek it, is expensive and uncertain. I prefer to take the attitude of a small fish in a big ocean... If I drop my guard or stop swimming there are beasts so big that they won't even notice swallowing me, but agility and speed are on my side so I focus on using this to my advantage.
Below are some interesting things I came across as I was writing this...
I think that there is something that have to be taking in account: When something is Open Hardware there is no Intellectual Property rights of the design, that is gone as soon as you declare it open. The only IP right remaining is that you are the author/s of the design.
The openness and collaborative environment of OnShape software I think will make it the perfect place where manny Open Hardware projects will blossom.