This post originally appeared on the Shapeways blog.

With the relaunch of the Shapeways Designer For Hire program, we are seeing more and more designers and clients coming together to create amazing 3D printed objects. While that is unquestionably a good thing, more people coming together also means more opportunities for misunderstandings. (Buzzkill sentences like that are a reason that lawyers aren’t always invited to parties.) Lauren covered some of big areas of misunderstanding with her 8 Questions Your Client Doesn’t Know to Ask You. This post is going to only address one area: who owns the files and the copyrights at the end of a design job?

Thinking about this in advance can help head off a number of disputes, and getting an agreement in writing can be even better. You may see “getting it in writing” and immediately think to yourself “but contracts are boring.” You are right. Contracts are boring. But like other boring things that manage to stick around like seat belts and automated data backup, they can also be really useful in a pinch.

Getting this sort of thing in writing serves at least two purposes. First, and probably most importantly, it forces the designer and the client to get on the same page before time and money are spent. If they don’t agree, it is much better to know that before a job starts than to wait until the end. Second, once both sides have agreed in writing, it makes it easier to resolve disputes that do come up at the end of a job.

Who Gets the Files?

The first question to address is who gets the files at the end of the job.  Many designers assume that they will keep the files for a model, while clients assume that they will get the files at the end of the job. This obviously creates the opportunity for misunderstanding.  Hashing this out at the beginning of a job can avoid lots of heartache at the end.

When you are discussing files, make sure that you are specific. There is a big difference between getting an .stl file for a model and getting something with a bit more data like an .obj file.

Also, there is a distinction between having possession of the files and being able to use the file going forward. Regardless of who has the files, how they are used is probably governed by copyright. Which, naturally, raises the question of…

Who Gets the Copyright?

Especially if the model is nonfunctional and decorative, it is probably protected by copyright. In most cases, the designer will own the copyright in that model when it is created (assuming the copyright exists).

The copyright gives the copyright holder the ability to control things like how many prints are made from the file, or if the file can be modified in the future. Talking about what – if anything – happens after the commissioned print is made can help shed light on how important doing these types of things are to the client.

If the client wants more than a set number of printed models at the end of the job, they will probably need both the 3D model file and some sort of license to the copyright that protects the model.  There is a lot of flexibility to what the terms of that license can be. It can restrict the client to making exact copies via a designated printing service (like, say, Shapeways), require the client to report to the designer every time a print is made, or allow the client to modify the file freely. If the client really wants full control of the model, they could even require that the designer transfer the copyright to the client.

What is the Answer?

Every designer-client relationship is different, so there is no single answer that will apply to every situation. If you have a specific question, it could be useful to consult a lawyer before moving forward with the agreement.  AIGA’s model contract can also serve as a great jumping off point for discussions between a designer and client. As a bonus for designers, once they decide which parts of that contract they want to use it can just become their default client agreement.

Ultimately, the most important thing is to discuss these questions at the start of the relationship. If the client and designer are on the same page, it will be a quick discussion. If they disagree, it gives them the opportunity to work it out at the start of the relationship. Sometimes that disagreement can be resolved by the designer charging an extra fee for additional rights or access to files. Usually the designer and client can come to agreement, although sometimes they cannot. In either case, it is always better to discover that at the start of a job than at the end.

This post originally appeared on the Shapeways blog.

Monday, the U.S. Supreme Court announced that it would be considering Star Althletica v. Varsity Brands, destined to be known as “the cheerleader uniform case.”   On its face, the case is focused on the somewhat metaphysical question of when a tennis skirt and tank top cross the line into being a cheerleader uniform.

However, as we’ve written about before, the real question in the case is how copyright should apply to works that mix creative and functional elements.  Copyright protects creative works but not functional works, so drawing that line can be incredibly important.  Unfortunately, currently there are at least 10 different (somewhat conflicting) tests that try and guide the analysis.

Earlier this year Sydney Lakin and Bill Koch at Stanford Law School’s Juelsgaard IP and Innovation Clinic helped us, along with Formlabs and Matter and Form, ask the Supreme Court to step in and pick one definitive test.

Why do we care so much?  Many 3D printed objects combine both functional and design elements.  Understanding if – and how – copyright applies to them is the first step in understanding licensing, use, and many other aspects of those objects.

We don’t know when the case will be heard yet (although we are sure it won’t be until after the summer).  We’ll be sure to keep you up to date on the developments as they come out.  In the meantime, if you have any questions feel free to leave them in the comments or tweet them to @MWeinberg2D.

Occasionally I find myself in the highly fortunate position to be asked to contribute to a scholarly journal without having any professional incentive to do so.  This is exciting because I’m as flattered as anyone when someone else is interested enough in my writing to want to republish it.  It also gives me a chance to come into contact with the kinds of contracts that academic publishers offer their contributors.  To put it mildly, these contracts are insane.  In exchange for an unpaid contribution, the contracts expect the authors to give the publishers all sorts of exclusive rights and to indemnify the authors against any sort of infringement lawsuit.

Fortunately for me, and unlike so many people who are confronted with these types of contracts, I have no professional incentive to publish in academic journals.  That makes me free to push back against the contract terms.  The worst thing that happens is that the publisher decides I’m more trouble than I’m worth - it isn’t going to knock me off tenure track or anything.

As what I hope is a service to others who are confronted with these contracts without the ability to walk away, I wanted to publish the version of the contract that the publisher (Kluwer in this case) agreed to pretty easily.  I obviously can’t guarantee that they would make the same concessions again (although it really didn’t take much to get to this point). At a minimum, it might give you the ability to push back when you hear that these terms “cannot be changed.”

All of the struck terms were in the original but are not in the signed contract.  I XXXX’d out the terms of the work because it isn’t really my place to announce the work in advance.  

The undersigned (hereafter called the Author) and Kluwer Law International, XXXXXXX, The Netherlands, (hereinafter called the Publisher)

whereas the Publisher wishes to publish the Work entitled “XXXX ” under the editorship of YYYYYYYYY (hereinafter called the Editor)

whereas the Author has declared his willingness to write the contribution provisionally entitled       (hereinafter called the Contribution) declare that they have agreed as follows: 

1.   The Author agrees to write the above mentioned contribution as agreed with the Editor and/or the Publisher.

2.   The Author hereby grants to the Publisher the exclusive right to publish, sell, give access to and license the use of the Contribution named above in all countries and all languages, in whole or in part, including any translation, abridgement, substantial part, modification or revision thereof, in book form, in a database on its own or with other works and in any form, including, without limitation, mechanical, aural, electronic and visual reproduction and publication, electronic storage and retrieval systems, including delivery of or giving access to the Work by electronic networks, and all other forms of electronic or electro-magnetic publication now known or hereinafter invented, throughout the world, for the full period of the respective intellectual property rights (including copyright) and all renewals and extensions thereof.  The Author hereby authorises and mandates the Publisher to register (at the Publisher’s cost) this licence in any applicable register for intellectual property rights and to take any action and instigate proceedings against infringement of copyright or other intellectual property rights in the Contribution and to use the Author’s name as a party after informing the Author. The Author is hereby licensed by the Publisher to the rights reserved as specified at the end of this agreement.

3.   The Author warrants and represents that to the best of his knowledge the Contribution does not infringe upon any copyright or other right(s), and that it does not contain infringing, libellous, obscene or other unlawful matter, that he is the sole and exclusive owner of the rights herein conveyed to the Publisher, and that he has obtained the necessary permission from the copyright owner or his legal representative whenever a passage from copyrighted material is quoted or a table or illustration from such material is used. The Author will indemnify the Publisher for, and hold the Publisher harmless from, any loss, expense or damage occasioned by any claim or suit by a third party for copyright infringement or arising out of any breach of the foregoing warranties as a result of publication of the Contribution. The Contribution shall be delivered to the Publisher free of copyright charges.

4.   The Author warrants and represents that the Contribution to the Work has not been previously published elsewhere, or that if it has been published in whole or in part, any permission necessary to publish it in the Work has been obtained and provided to the Publisher together with a statement of the original copyright notice.

5.   The Author agrees to be named as author of his Contribution. The Author declares and warrants that any person named as co-author of the Contribution is aware of that fact and has agreed to being so named. The Author signs this agreement also on behalf of and in the name of each co-author, who hereby agree with this agreement in full, in particular Clause 3 and 8. The Author warrants and represents that he is empowered by any co-author to represent this co-author in signing this agreement in their name.

6.   The Author shall receive for the rights granted in Art. 2 a free copy of the (updated) Work plus an electronic file of his (updated) contribution. The Author warrants and represents that any personal use of the contribution by the Author will be limited to the use permitted by the rights reserved to the Author as specified at the end of this agreement. The Publisher shall clearly state the name of the Author in the Work.

7.   The present agreement also applies to future updates to the Contribution by the Author. The Author agrees that the Publisher may request to have a third party take over the writing and updating of the Contribution.  The Author will comply with said request and will cooperate with the new contributor for transfer of his responsibilities with respect to the Contribution. The Author agrees that if the revision has not substantially been prepared by the Author, the Publisher is not required to mention the name of the Author in or in relation to the Work. With respect to such revision the Author waives his moral rights to the extent allowed by law. 

8.   The present agreement can be terminated by the Publisher without prior notice if the Author fails to deliver the Contribution according to the agreed deadline. Termination shall not affect the rights and obligations accrued prior to termination. Any provisions of this agreement which by their nature extend beyond termination shall survive such termination.

9.   This agreement is governed by Dutch law. Any dispute that may arise shall be brought before the applicable court in Amsterdam in The Netherlands.

/s/ 

RIGHTS RESERVED TO THE AUTHOR

 

The Publisher confirms that the following rights are reserved to the Author:

 

•    The right to make copies and distribute copies (including via e-mail) of the Contribution for own personal use, including for own classroom teaching use and to research colleagues, for personal use by such colleagues, and the right to present the Contribution at meetings or conferences and to distribute copies of the Contribution to the delegates attending the meeting.

•    The right to post the full Contribution on the Author’s personal or institutional web site or server, at any time, provided the site has protected/restricted access and acknowledgement is given to the original source of publication; the right to post the full Contribution on any web site provided 3 months have passed since the Contribution was originally published.

•    For the Author’s employer, if the Contribution is a ‘work for hire’, made within the scope of the Author’s employment, the right to use all or part of the Contribution for other intra-company use (e.g. training), including by posting the Contribution on secure, internal corporate intranets.

•    The right to use the Contribution for his/her further career by including the Contribution in other publications such as a personal dissertation and/ or a collection of own articles provided acknowledgement is given to the original source of publication.

 

 

The Author’s rights to reproduce and distribute the Contribution are subject to ensuring that the publication by the Publisher is properly credited^[1] and that no commercial use of the publication is involved^[2].

The rights reserved to the Author (as stated above) are automatically granted upon acceptance of the contribution for publication and upon signature of this agreement by the Author. Any other rights or personal use not expressly stated in this document are not excluded but may be subject to time limitations or payment of fees. In such cases, the Author has to contact Kluwer Law International to obtain formal permission^[3].

[1] “Reprinted from (name of publication), (volume no.), (issue number), (date of publication), (page range), with permission of Kluwer Law International.”

[2] Commercial Purposes includes the use or posting of articles for commercial gain including the posting by companies or their employee-authored works for use by customers; commercial exploitation such as directly associating advertising with such postings; the charging of fees for document delivery or access; or the systematic distribution to other people (other than known colleagues), whether for a fee or for free.

[3] For information on permission guidelines and requests please visit our website: www.kluwerlaw.com.

After waddling my way through some python learning courses, I finally stumbled into an excellent “next step” programming challenge.  It had the ideal combination of a connection to my real life, super straightforward goals, and a handful of moving parts that I was pretty sure I could figure out (but that I would, in fact, have to figure out).  The project was to download an image of the front page of every People’s Daily back to 1993.  This post is going to walk through the process of how to build the python script in a way that I wish someone had done when I was trying to figure this out.  That means instead of code snippets inside of a longer unified program (or just snippets) it will have a series of discrete programs that build upon themselves.  For me, that makes it easier to figure out how each part works.

The “why” I did this is not particularly important, but the “how” is.  The excellent news is that these images are all stored on a server in a standard way.  For example, the image for the cover on April 26, 2016 lives here:

http://58.68.146.102/pic/101p/2000/04/2000040101.jpg

after the /101p/ the pattern is simple: year/month/YearMonthDayPage.jpg

That means I didn’t have to mess with creating a BeautifulSoup object or any real web scraper.  All I needed to do was to create a script that would download the file, move on to the next day, and download that file.  

While that is simple from a programming standpoint, it still requires actual steps that you actually need to code.  The rest of this post walks through each step with a script you can download and break however you want.  All of the code, which is hosted at this github repository is licensed under a CC0 license (more on why I decided to do that at the end).

Step 1: Download & save a picture

The first thing I decided I needed to figure out was how to have python download a picture and save it.   While I started with the template from the excellent Automate the Easy Stuff chapter on web scraping (specifically the exercise that shows you how to download XKCD strips), I quickly realized that it was overkill.  I didn’t need to download and parse a page to find the URL - I already had it.  After a few dead ends using requests, I ended up using the urllib library. The syntax was fairly easy: call it and then pass it the URL you are downloading from and the name you want to save it as.  Here is a fully functioning script using urllib:

import urllib

urllib.urlretrieve(‘http://58.68.146.102/pic/101p/2000/04/2000040101.jpg’, 'test.jpg’)

The first line imports the urllib library.  The second line calls the urlretrieve function from urllib, tells it to download the file at http://58.68.146.102/pic/101p/2000/04/2000040101.jpg and save it to a file called test.jpg.  Note that this will save the file in the same directory as the python script.  You can call the output file whatever you want.

Step 2: Count and Correct Numbers

Next, I needed to remind myself/confirm that I understood how to add 1 to a variable a certain number of times.  That’s a fairly straightforward concept.

I also needed to figure out how to make sure the numbers the represented the date in the program would work when applied to the URL.  The target URL always uses two-digit dates. That means that April is not represented as “4″ but rather as “04″.  In order to be able to find the right file I had to figure out how to turn any integer into a string with two characters no matter what.

Here’s the script that does both of those things:

day = 5

for i in range(0, 15):
     print day
     day_fixed = str(day).zfill(2)
     print day_fixed
     day += 1
     print “I’ve added 1”

The first line sets day to a starting integer.  Note that this is an actual number, not a string.

The rest of the script is a loop that will run a set number of times.  To pick the number of times it will run, change the second argument passed to range (currently that is the 15) to whatever number you want.

All of the “print” commands are just for debugging.  The real action is in the two other lines.

day_fixed is where I hold the version of the day that is turned into a two character string (this becomes important later).  “str(day)” turns the integer day into a string.  .zfill(2) forces that string to be two characters, and will add a 0 to the front if need be.

day += 1 just takes day and adds 1 to it.  That way the days advance every time the loop runs.

Step 3: Iterate

The next step was to combine the ability to advance the dates with the ability to download the file.  I knew  that I would eventually have to make all of the date variables advance (day, month, and year), but I decided to make sure I could do just one before tackling all of them.  Because of that, the script uses strings for the year, month, and page parts of the URL.  That lets it focus on changing just the day:

import urllib

core = “http://58.68.146.102/pic/101p/”

#these all have to be numbers not strings - need to change them

year = “2000”
month = “04”
day = 2
page = “02”

for i in range(0,6):
     day += 1
     #turns day into a string
     day_fixed = str(day).zfill(2)

     urllib.urlretrieve(core+year+“/”+month+”/“+year+month+day_fixed+page+”.jpg", year+“-”+month+“-”+day_fixed+“-”+page+“.jpg”)

Again, the first line imports the urllib that is used to actually download the image file.

The “core” variable is the part of the URL that says constant.  I didn’t have to make it a variable, but since the target URL is a bit complicated turning it into a variable make it a little bit easer to work.

After the note to myself that I’ll need to change the strings to numbers, there is the list of variables that represent the date.  Then there is  a loop that is identical to the last script without the print lines for troubleshooting (it works….).

The last line is the command to download the file.  It is a single line, although it might wrap in your browser.  The first part just calls the urllib.urlretrieve() function.  This function will download whatever URL is in the ().

Inside the () is the URL broken up into pieces.  These need to be broken up because while the relative position of each variable is the same - the path will always end with the month followed by the day followed by the page - the actual value of the variables will change as the script works its way through the process.  That’s kind of the point.  For elements that do not have a variable, I just used strings surrounded by ““.

Each time the loop runs the day is advanced 1, the two character version of the day is created, and then the file at a URL that includes that new day is downloaded and assigned a file name that is also based on the date. 

While the first argument passed to the urllib function has to be what it is, you could change the second function to whatever you want.  I decided to name each file year-month-day-page.jpg.

Step 4: Multiple Variables

Thenext step is to expand the script so it iterates through all of the variables (date, month, and year) not  just date.  Of course, it has to do this in a systematic way so that every combination that corresponds to a date is actually downloaded.  In order to do that, I nested loops within loops.  I wasn’t sure it would work, so I started with just two variables (day and month) to see what would happen:

import urllib

core = “http://58.68.146.102/pic/101p/”

#these all have to be numbers not strings - need to change them

year = “2000”
month = 4
day = 2
page = “01”

for i in range(0,6):
     day += 1
     #turns day into a string
     day_fixed = str(day).zfill(2)

     for i in range(0,4):
         month += 1
         month_fixed = str(month).zfill(2)

         urllib.urlretrieve(core+year+“/”+month_fixed+“/”+year+month_fixed+day_fixed+page+“.jpg”, year+“-”+month_fixed+“-”+day_fixed+“-”+page+“.jpg”)

     month = 4

This is just the previous script with an additional for loop related to the month.  There are two important things that need to be done in order for this to work correctly.  First, the urllib function must be inside the deepest loop.  The most nested loop runs all the way through before jumping up a level, so if urllib is bumped out a few levels you will miss a lot of the files.

Second, you need to reset the variable when its loop is done.  The month loop starts at 4 (because that’s what I set it at in the start of the script) and works its way through 4 times until month is 8 (I limited the number of iterations for testing).  Once it hits 8, the loop exits, the day variable is moved one day forward, and the month loop starts over again.

However, if that is all you do, the month loop will start where it left off last time - at 8 instead of at 4.  This can create a problem if you want it to run, say 31 times for every month.  By the second month you will be trying to download files for the 42nd day of February.

In order to avoid that, I reset the month variable to the original variable outside of the month loop.  Now every time it runs it starts from the same place.

Step 5: Bringing it All Together

Now that I have figured out how all of the pieces worked, I was ready for the final version:

import urllib

core = “http://58.68.146.102/pic/101p/”

#start all of these one below where you want to start because step 1 is +=1

#DON’T FORGET IF YOU CHANGE A VALUE HERE TO ALSO CHANGE IT AT THE END OF THE FOR
year = 2002
month = 0
day = 0
page = “01”

for i in range(0,31):
     day += 1
     #turns day into a string
     day_fixed = str(day).zfill(2)

     for i in range(0,12):
         month += 1
         month_fixed = str(month).zfill(2)

         for i in range(0,6):

             year += 1
             year_fixed = str(year)

             #this needs to go at the bottom of the nest
             urllib.urlretrieve(core+year_fixed+“/”+month_fixed+“/”+year_fixed+month_fixed+day_fixed+page+“.jpg”, year_fixed+“-”+month_fixed+“-”+day_fixed+“-”+page+“.jpg”)

             year = 2002

         #this resets the month to the starting point so it stays in the right range
         month = 0

This uses year, month, and day as variables.  Note that it doesn’t work through the pages.  That variable is necessary for the download URL, but for this first version I didn’t need every page of the paper.  As the all caps comment suggests, you need to set all of the variables one less than the starting variable since the first thing that happens is that 1 is added to them.  You can also manipulate how many years of covers you get by changing the second argument in the year range() function (currently it is set at 6).

Improvements

This script works, which is exciting.  However, there are a few things I might improve going forward:

• Be smart about dates.  Right now it downloads 31 days of covers for every month.  Obviously that means that some of the files are junk because there is no Feb 31st.  The way to fix this would be to add an if statement to the day loop that changes the number of iterations based on the value of month.  Since I didn’t really mind having a few garbage files I didn’t worry too much about this.
• Reorder the nesting.  Right now the script will download the January 1 cover for each year, then move on to the January 2 cover for each year, and so on.  This is fine, but if the download is interrupted for some reason it makes it a bit harder to  understand where to restart and it makes it a bit harder to get a sense of how far into the process you are by looking at what has been downloaded.  By reordering the nesting, I could make it download the covers in chronological order.
• Handle interruptions.  The first two fixes are fairly easy, but this one would require actual additional research. I was testing on this on a few wonky wifi connections, and sometimes I would lose the connection in the middle.  This would cause the script to crash and stop.  It would be great to learn how urllib.urlretrieve handles these sorts of problems, and make the script robust enough to recover.  It can take a few minutes for the script to run, and it was a shame when I cam back only to see that it had crashed three minutes in.

The License

Why a CC0 license?  First, these scripts are so simple that one could probably argue that they are devoid of copyrightable content (except for the comments).  But second, and more importantly, to the extent they are useful to anyone they will be useful for hacking around with trying to learn python.  Even an MIT license would require people to keep a license intact, which seemed too burdensome for this purpose.  CC0 clarifies - to the extent that anyone is worrying about it - that you can do whatever you want with these scripts without worrying about copyright.

That’s the show. Hopefully this is helpful to someone else trying to teach themselves how to do this.

This post originally appeared on the Shapeways blog.

Spring is in the air, and that means that it is time for a few policy updates here at Shapeways.  This blog post serves as a summary of those changes.  As a reminder, if you want to go deeper you can always check out the archived versions of specific policies in order to compare them to the current one.

The biggest update is to the Shop Terms and Conditions.  These terms were last updated in 2012 and, as you can imagine, Shapeways has evolved significantly since then.  In addition to the Shop Terms update, this update includes much smaller fixes to the general Terms and Conditions, the API Terms and Conditions, and the Content Policy.  We are also bringing our content policy precheck program out of beta.  I’ll detail all of the changes below.

Shop Terms and Conditions

These are the terms that govern shop owners on Shapeways.  This update overhauls the format so that it makes a bit more sense, and updates some of the policies.  It also takes steps to simplify the terms.  Since you need to have a regular Shapeways account in order to open a shop, it tries to incorporate terms from the standard Shapeways Terms and Conditions by reference instead of repeating them again in the Shop terms.

For example, instead of having a big section on content rules, the new terms incorporate the existing Content Policy.  That should reduce confusion by just having one content policy that governs the entire site and make the terms a bit more concise and easier to read.

While the payment terms remain largely the same (we pay your markup if it is over $30 on the 15th of each month) there are a few additions designed to clarify policies and address issues that have emerged over the years.

One of the most important changes is to highlight the importance of providing us with correct PayPayl information for an account that can receive transfers from the United States or the Netherlands.  Failure to do this can cause all sorts of problems, so we wanted to make sure that there was ample warning in the terms that you need to do that in order to receive  your markup.

Another change is adding rules about how we handle markups on orders that later get returned or rejected.  Sometimes a model is returned because we did not print it correctly.  In those cases we will continue to reprint the models at our expense and send shop owners their markup.  However, sometimes a model is returned or rejected because of an error on the part of the designer.  We are currently exploring the best way to handle those situations.  It is likely that in at least some of those cases we will not pay the designer a markup if the return or rejection stems from errors that they made.

The changes to the terms give us the ability to begin testing rules governing what happens when a product is returned due to designer error.  The process of exploring options will take some time, and we will strive to do it in an open, inclusive way.  Expect to hear more about the process soon.  Until we roll out a more formal tests, designers will at most receive warnings that their model was returned due to what we believe to be their error.  To put it another way, we will not begin withholding markups for returned or rejected models until we have new rules in place.

Most of the rest of the changes are relatively small.  We added a reminder that some tax authorities require us and/or our payment processors to report data on accounts with gross payments over $20,000 and 200 transactions.  We also did a better job of linking the indemnity and product liability sections of the shop owner terms with the general site terms.  At the end we made it explicit that we may change the terms from time to time.

Finally, we linked the confidentiality terms in the shop owner terms to those in our privacy statement.  Hopefully that will give all users of the site a  more uniform set of expectations in terms of privacy on the site.

Terms and Conditions

As I noted at the start of this post, in addition to an overhaul of the shop terms and conditions we also made some updates to other policies on the site.  In addition to fixing some typos in our general terms, the update has two substantive additions.  These are actually clarifications of existing policies that we wanted to make even more clear in the terms.  Remember that these apply to all users, not just shop owners.

The first is what happens when a model violates the content policy. The terms now make it clear that if a model violates our content policy we will refuse to print it and issue you a refund.  If we catch the violation after we print the model, we will not ship you the model and may not issue you a full refund.

We are pairing this with removing the content policy precheck program from beta.  You can email  content-precheck@shapeways.com if you are worried that a model might run into trouble with our content policy.  Even if your model is incomplete – or even just an idea – we will do our best to give you guidance about how our content policy applies to you.

The second update to the general terms a clarification as to what happens when you remove a model from Shapeways.  The terms now make it clear that we may continue to use the model as part of our internal education and testing process. This is largely because we use user models to develop testing benchmarks that need to be consistent over time.  However, you can still always email customer service when you remove a model and request that it also be removed from internal testing.

API Terms and Conditions

The updates to the API Terms and Conditions are relatively modest.  In addition to some minor typos, the terms now make it clear that developers using the API are responsible for all fraud and chargebacks related to their use.  Since the API developer is in the best position to design their application in a way that avoids these sorts of fraudulent charges, it seemed only fair that they are responsible when someone uses the application fraudulently.

Content Policy

Last on the list of updates is the Content Policy.  The biggest change, which I already  mentioned above, is that we are bringing the content policy precheck out of beta.  Besides cleaning up some typos (by the way, feel free to let me know when you see typos in our policies….), the only other change is to make our preferred way of receiving copyright takedown notices more prominent.  Sending emails to content@shapeways.com is the best way to get a takedown request processed efficiently, and now that email address is more obvious on the page.

Thus concludes the spring recitation of the Shapeways policy updates.  As always, if you have any comments, questions or concerns, feel free to put them in the comments below, email them to me at mweinberg@shapeways.com, or tweet at me @MWeinberg2D.