VanL
Joined 17 years ago
Karma
1,510
Submissions
121
Member since
Aug 7
Member at Dykema. Intellectual Property and Open Source Lawyer. General Counsel and Vice chair, Python Software Foundation.
View on Hacker NewsRecent submissions
Comment · 3 years ago
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.
Comment · 5 years ago
Hi! I'm the author of this chapter of the casebook. I didn't expect it to show up here, but I'm happy to answer questions.
Comment · 7 years ago
Hi, I'm the author of this talk. A couple quick notes:
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.
Comment · 8 years ago
Probably US only, didn't look internationally.
Comment · 8 years ago
Yes, but it is deeper. My overall take is that SSPL overreaches based upon the tools that it is using, making it infirm for multiple reasons.
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).
Comment · 8 years ago
Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with.
Practically, that is probably dealt with via a blog post and a retreat to the AGPL, but still.
Comment · 8 years ago
This would significantly ameliorate the problem.
Comment · 8 years ago
Not quite. There are administrative problems with the AGPL, which are inherited here. But it is the scope of this license that pulls in these new defenses.
Comment · 8 years ago
Here is the analysis: Let's think about the context where this would come up: A party ("Service") takes the SSPL'd MongoDB and implements a service. Service releases some code based on a good faith interpretation of the scope of the release necessary. There is a dispute between MongoDB and Service as to the scope of the necessary code release.
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.
Comment · 8 years ago
Quick summary:
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)