A photo that tries to capture an existing painting as closely as possible is not copyrightable.
However, even minor changes (such as changing the tint of the photo) have been found to be enough for copyrightability.
1,510 karma · joined August 7, 2009
However, even minor changes (such as changing the tint of the photo) have been found to be enough for copyrightability.
First, the source materials I relied on are available at <https://github.com/google/opencasebook/blob/master/patents.m.... If you are interested, please read them.
Second, about Bowman v. Monsanto. The logic of Bowman is a pretty serious challenge to what I presented above. It might invalidate certain parts of my argument. Specifically, the question is whether it is even theoretically possible to exhaust the exclusive right to "make" a patented item.
I haven't yet been able to go back and do further research. But what I would be looking for is a case where someone sold an item - like a software application - with a license that says, "make as many copies as you want for internal use." If the buyer then transferred the software, would the new buyer get the right to make copies? I'm not sure. But if so, that would be evidence that a sale could exhaust the right to make.
Third, I thought this was a fun rabbit hole - and, as I said in my talk, a "surprising" result. The surprising bit is important. It is entirely possible - and even likely - that a court could agree with all the precedents I cited, and "distinguish" them to come to a contrary, non-surprising result.
In short, I think exhaustion is more important than people may be considering, but don't take this analysis to the bank.
I don't necessarily disagree with the sort of thing they want to do, that definitely fits one kind of business model. But I wouldn't want to go to court the license as presented (and now entered into by some unknown number of people).
Practically, that is probably dealt with via a blog post and a retreat to the AGPL, but still.
In the ensuing lawsuit, Service raises misuse and argues that the scope is ambiguous. Leaving aside the misuse argument, a court could either a) find for Service, thus restricting the scope of the code to be delivered, or b) find for MongoDB, thus giving rise to an immediate defense of frustration/impracticability, which would undo the contract.
1) It is problematic to use copyright infringement as a hammer to force people to release/relicense code that is not related to the copyrighted code. (That's the "misuse" bit)
2) If you try to do this via contract, there are lots of practical difficulties associated with actually releasing the code - the biggest of which is that you probably don't own all the code you would be required to release. (That's the "impracticability" bit)
While I wish Naftali well in his efforts - I have a private Python-derived language myself! - this is not "Python 2.8." For trademark purposes, "Python" is only what is released or endorsed by the PSF.
We have already reached out to Naftali and asked him to change the name of his project and update this blog post accordingly.
Obviously, though, this is someone who cares a lot about Python, so let's be sure not to rain down on him with a lot of scorn; I admire that he was willing to sit down and 'scratch his own itch.'
Source: I am the General Counsel of the PSF.
We have it. Occam's Razor - the original version:
"entities must not be multiplied beyond necessity"
The key problem with the patent system is the problem of disclosure. We always say that the patent system is a bargain between the inventor and the public. The public gets new knowledge and the inventor gets a period of exclusivity for the using/making etc that knowledge.
Where the system falls down is in the "disclosure to the public" part of that bargain. Patent language has become so abstracted that most of the time it fails to inform someone of skill in the art how to actually make the promised item. This has some corollary effects:
- The patent system becomes less useful as a source for knowledge (as argued by the article) - Novelty and obviousness (and later, infringement) all become less certain. This results in poor quality patents coming out of the patent office and high costs to litigate for infringement.
In the end, though, the result is that the patent system is (for most of the computer arts where I spend my time) not very useful as a store of knowledge. If there is a choice, I will almost always seek out a paper (or source code) rather than an accompanying patent to get an understanding of new technology.
This is due to the incentives associated with each type of publication. The source code is designed to convey certain algorithms to the computer in an unambiguous way. Papers are designed to get read and cited - and they don't do that unless they communicate what is new and meaningful to an audience of peers.
In contrast, patents are designed to cover a range of possible solution spaces, with as much room for reinterpretation later as is possible without being insoluably ambiguous.
This problem is hard to undo because the push to abstract the descriptions in patents was done with the best of intentions. - Congress wanted to allow new things to be described without constricting the form of the language used. - Prosecuting lawyers (and their clients) wanted to get the maximum coverage for their new ideas. - Courts want to reward inventors and disallow trivial workarounds (nail->screw) not addressing the core inventive concept.
All of these points are valid ones - but in combination, the result is that patents have become too vague, particularly in anything computer-related.
As an aside, the mechanical arts (and some others, such as many bio/chem arts) don't suffer from this problem to nearly the same extent, and so you usually don't see the same problems.
It was fun to take something where hordes of associates were being used as slightly smarter computers and automate it - there were several times when people were amazed that I turned out a properly formatted in-depth diligence report about multi-hundred-patent portfolios within a couple of days.
In my spare time, I built a natural language processing + graph analysis tool to help look for patent prior art. I spoke about it at PyCon - see <http://pyvideo.org/video/425/pycon-2011--how-to-kill-a-paten....
Right now I use an internal Github instance to manage CCLAs at Rackspace, and its just a matter of time until I automate some more stuff here.
What made the coalition for reform though, was the non tech industry. Retail, the Chamber of Commerce, banks, grocers, restauranteurs, hoteliers, gaming, insurance, venture capital... Basically everyone else. The pro-reform group was called the big tent for a reason.
This was about a smallish number of companies wanting to extract profits from other companies, and using the brokenness of the patent system to do so.
No one would have objected of there was a sense that the allegations were fair or well-founded. The problem is that courts would by statute try to uphold claims that were ridiculous.
Patent suits are the spam of the court system - spam you have to pay to delete.
The pulled bill was the result of two different forces coming into play: Pro-IP monetization companies applying pressure and coalition splitting among the Democratic caucus.
The IP Monetization folks (Trolls, Universities, Bio, PHrMA, old line industry, and folks like Qualcomm) have been pushing really hard to weaken the legislation. There were substantial efforts to come to reasonable compromises, but those groups were never really happy.
What ultimately killed it, though, is that there were some important special interest groups (notably the trial lawyers) who opposed any kind of reform. If the bill would have been brought to the floor, it would have split the Democratic coalition and made a bunch of big-money donors mad.
When the opposition from the IP Monetization group mixed with the destabilizing political effect, the Senate Democratic leadership decided to kill it.
I stand corrected, then. I had thought that Google's policy allowed contributions, but not under the employee's own copyright. I thought there was an additional step to get that approved.
In DSC, the court ruled that Alcatel owned the employee's thoughts that had not yet been committed to writing. (See http://www.theregister.co.uk/2002/08/12/alcatel_owns_us_empl...).
In DDB, the court found that Schlumberger (the oilfield services company) owned a baseball simulator written by an employee. (See http://www.finnegan.com/Publications/federalcircuit/FCCDetai...)
In Medsphere, the CTO of the company was sued for releasing the source code to their application as open source on Sourceforge. (See http://www.informationweek.com/medsphere-settles-lawsuit-wit...)
It may be only "corporate lawyers" who agree with the policies, but those lawyers tend to be very persuasive in front of judges.
What we did today was make a statement that encouraging participation in various communities and allowing Rackers to develop their skills whenever and however they want is both better for everyone and more consistent with our values. As obvious as this may be to you, we needed to do this in the proper way so that we could satisfy our duties to our shareholders.
I challenge you to find a public company with a similar policy. I have been around a long time, and I've never found one.
We decided to be different and do better.
The scope of employment has historically been interpreted very broadly, usually in terms of any present or possible future business opportunity. You will see how that leads to a broad right of assignment.
You may say, that is ridiculous! I can't believe such a thing! Well, I agree that it is ridiculous, but it is still generally true (modulo some exceptions applicable in a couple of states due to specific employment laws).
At Rackspace, we believe in doing the right thing. We already were doing the right thing, but only when asked. We changed our policy to instead do the right thing by default.
If you work at a company bigger than 10-15 employees, check your employment agreement. Rackspace's stance on this is highly unusual (I think even unique) for a company its size.
Because employee code was technically the property of Rackspace, we had a policy that they needed to ask for permission before releasing it to the public under an open source license. But when we looked at our actual history, we saw that we were granting 100% of the requests.
This new policy grants pre-approval to all Rackers to contribute to open source projects under their own name, holding their own copyright. We even allow contributions that occur on Rackspace time using Rackspace resources, as long as their manager agrees that it is a good use of their at-work time.
VanL (I wrote the policy)
If your manager agrees that hacking on $PROJECT is a good idea, go for it.
VanL (I wrote the policy)