An API to the Copyright Office?
I got the following email that I thought I would just post directly here to my blog (with my response).
With respect to the c-registry.us site (the link you sent), on slide #4, the "reseller" program they refer to is not the same as the "copyright registrar" proposal I put forward. More on all this in a second. But first, it should be made very clear that "c-registry.us" has absolutely no affiliation with the copyright office. I am constantly getting questions from people about this company and whether they are some sort of commercial "retailer" that has some special relationship with the CO. The danger is that when they say something like what you referred to above, people believe it to be an official statement from the CO.
Officially, you should just call Maria Pallante at the CO. She's extremely accessible and very pleasant to talk to. Alternatively, you could call David Christopher, who sits next to her. He is more up-to-date on the technology stuff. You'll get all your questions answered instantly. Whenever there are rumors floating around, call them to get the scoop.
Now, to the "reseller program": whether this is what c-registry.us is referring to, I'm not sure, but I what I do know is that the CO is creating an API (application programmer's interface) that would enable third-parties to write their own UI (website, applications, etc.) that would allow users to submit new copyright applications to the copyright office for processing. It would NOT provide access to content already there, nor would it expedite the process, nor would it allow third-parties to process those applications or act as resellers or retailers for the copyright office. The API offers nothing more than what is already provided by eCO.
All that said, it does beg the question: Why? The answers may appear obvious, but no one has formally stated "who" gets to use this API, under what terms and conditions, or any other business-related objective. For now, we just know it's in development. (Limiting access of this new API would done through access keys, which is assigned to authorized users. This is identical to APIs used by Yahoo, Flickr, Google, Facebook, etc... There's nothing magic here. Various levels of security are available to keep stuff safe and locked up.)
There are several things to keep in mind about this API:
1) It is very early in the process. They have contracted with a vendor to design the API specifications, and that part is still very new. I asked to review the material, but I was told that it's too early to see anything. I was not given any time frame for when this might be done, or even a time schedule for deliverables. They aren't keeping it "secret" -- clearly, they told me what they were doing -- but they aren't exactly open about it either... which leads to:
2) The API draft specifications or early-developer process is not open to public review. (I have not been informed of a beta program, and I am on the list of people to be notified if/when such a thing is started.) In my opinion, this is a big red flag--the CO should do this entire process in the open, exactly the way the IETF (internet engineering task force) does with all new protocols and other specifications. The CO should have a public forum and developer application list to allow everyone to contribute useful and important feedback on proper design and implementation from the very outset, not *after* specifications and preliminary applications are built. Furthermore, it would be best for the CO to expressly avoid having their OWN implementation, and instead, just publish the specifications and allow third parties to implement their own prototypes, which the CO would then certify if they met certain criteria. (One of which would be for the code to have open-source status.)
3) It should be known that, just because there's a back-end API, it does not solve the problem of back-logged registration applications. In fact, it would flood the registration backlog even worse because more people would be filing applications. That's NOT to suggest this is a bad thing! IMHO, the worse the backlog gets, the quicker the CO will be forced to solve the problem. And the only solution to that is to outsource the processing of applications to third parties. In other words, "copyright registrars" as I've been proposing would do much the same administrative tasks that the CO currently does in-house. They would be trained and certified by the CO, thereby performing exactly the same duties and responsibilities, but can be farmed out to an infinite number of companies. This would alleviate the back-log, improve efficiency, reduce costs (which bring down filing fees) and increase participation in the copyright registration program. Everyone wins.
The API that the CO is doing has nothing to do with my proposal, nor would it affect anything that already exists in the copyright process today. And of course, it has nothing to do with the c-registry.us website.
It does still beg the question: what direction does this suggest that the CO is moving? The API would eventually be necessary for a "copyright registrar" to exist, but that idea has not yet been accepted.
What the API will NOT do is streamline the application process... It doesn't really matter how backlogged the CO may happen to be in order to have your works protected--all you need to do is apply to get the date of registration established. Granted, having the certificate does help considerably in the legal process, and it does avoid potential risk that a given judge might rule inconsistently with precedents. For such conservative applicants who really need to protect their valuable works (such as timely news and/or celebrity material, for example), expedited registrations might be worthwhile. But, for the vast majority of people, the eCO is sufficient to get protection immediately.
In summary, I think the API is a step in the right direction. It isn't perfect for the reasons noted above, but these things tend to work themselves out.
dan
Have you heard anything further about the USCO possibly switching to a "reseller" system for copyright registrations? I've been hearing a rumor lately that they are about to start beta testing a program.
It was mentioned in this presentation for one:
http://www.c-registry.us/CEPIC/MILE_Orphan_Works_Solution_060309.htm
I can't find any formal announcement on the USCO site nor have I been able to find any other stories on this. I don't subscribe to every single mailing list though. Have you heard anything?
With respect to the c-registry.us site (the link you sent), on slide #4, the "reseller" program they refer to is not the same as the "copyright registrar" proposal I put forward. More on all this in a second. But first, it should be made very clear that "c-registry.us" has absolutely no affiliation with the copyright office. I am constantly getting questions from people about this company and whether they are some sort of commercial "retailer" that has some special relationship with the CO. The danger is that when they say something like what you referred to above, people believe it to be an official statement from the CO.
Officially, you should just call Maria Pallante at the CO. She's extremely accessible and very pleasant to talk to. Alternatively, you could call David Christopher, who sits next to her. He is more up-to-date on the technology stuff. You'll get all your questions answered instantly. Whenever there are rumors floating around, call them to get the scoop.
Now, to the "reseller program": whether this is what c-registry.us is referring to, I'm not sure, but I what I do know is that the CO is creating an API (application programmer's interface) that would enable third-parties to write their own UI (website, applications, etc.) that would allow users to submit new copyright applications to the copyright office for processing. It would NOT provide access to content already there, nor would it expedite the process, nor would it allow third-parties to process those applications or act as resellers or retailers for the copyright office. The API offers nothing more than what is already provided by eCO.
All that said, it does beg the question: Why? The answers may appear obvious, but no one has formally stated "who" gets to use this API, under what terms and conditions, or any other business-related objective. For now, we just know it's in development. (Limiting access of this new API would done through access keys, which is assigned to authorized users. This is identical to APIs used by Yahoo, Flickr, Google, Facebook, etc... There's nothing magic here. Various levels of security are available to keep stuff safe and locked up.)
There are several things to keep in mind about this API:
1) It is very early in the process. They have contracted with a vendor to design the API specifications, and that part is still very new. I asked to review the material, but I was told that it's too early to see anything. I was not given any time frame for when this might be done, or even a time schedule for deliverables. They aren't keeping it "secret" -- clearly, they told me what they were doing -- but they aren't exactly open about it either... which leads to:
2) The API draft specifications or early-developer process is not open to public review. (I have not been informed of a beta program, and I am on the list of people to be notified if/when such a thing is started.) In my opinion, this is a big red flag--the CO should do this entire process in the open, exactly the way the IETF (internet engineering task force) does with all new protocols and other specifications. The CO should have a public forum and developer application list to allow everyone to contribute useful and important feedback on proper design and implementation from the very outset, not *after* specifications and preliminary applications are built. Furthermore, it would be best for the CO to expressly avoid having their OWN implementation, and instead, just publish the specifications and allow third parties to implement their own prototypes, which the CO would then certify if they met certain criteria. (One of which would be for the code to have open-source status.)
3) It should be known that, just because there's a back-end API, it does not solve the problem of back-logged registration applications. In fact, it would flood the registration backlog even worse because more people would be filing applications. That's NOT to suggest this is a bad thing! IMHO, the worse the backlog gets, the quicker the CO will be forced to solve the problem. And the only solution to that is to outsource the processing of applications to third parties. In other words, "copyright registrars" as I've been proposing would do much the same administrative tasks that the CO currently does in-house. They would be trained and certified by the CO, thereby performing exactly the same duties and responsibilities, but can be farmed out to an infinite number of companies. This would alleviate the back-log, improve efficiency, reduce costs (which bring down filing fees) and increase participation in the copyright registration program. Everyone wins.
The API that the CO is doing has nothing to do with my proposal, nor would it affect anything that already exists in the copyright process today. And of course, it has nothing to do with the c-registry.us website.
It does still beg the question: what direction does this suggest that the CO is moving? The API would eventually be necessary for a "copyright registrar" to exist, but that idea has not yet been accepted.
What the API will NOT do is streamline the application process... It doesn't really matter how backlogged the CO may happen to be in order to have your works protected--all you need to do is apply to get the date of registration established. Granted, having the certificate does help considerably in the legal process, and it does avoid potential risk that a given judge might rule inconsistently with precedents. For such conservative applicants who really need to protect their valuable works (such as timely news and/or celebrity material, for example), expedited registrations might be worthwhile. But, for the vast majority of people, the eCO is sufficient to get protection immediately.
In summary, I think the API is a step in the right direction. It isn't perfect for the reasons noted above, but these things tend to work themselves out.
dan
Labels: copyright, dan heller, legal, registration
posted by argv | 1:13 PM
