AI is far more productive, and easier in modifying source pictures, than photography. Controlnet is not a mere tint, it can generate 20 artstyle variations of the source image in 30 seconds. No artist will have any income if this those AI outputs are copyrightable without cost.
I don't think past-decisions are that important here. There'll definitely be new laws around AI generated content, that set clear standards. Those standards have to consider the social impact of copyright and the livelihood of artists. The whole point of copyright is not some abstract golden moral standard, but something that keeps artists and writers employed.
That's why I think pay-for-copyright is the best balance in terms of liberty for AI art but preserving the incomes of traditional artists.
This is the same as saying that the generative art (which has been a thing for decades) provides infinite variation. This is only technically true: the "infinite" variations of the procedurally generated art are all constrained by the original creator's intent, which is exactly what gives such art value.
The generative art is not set in fixed pixels, but instead is represented in a fuzzy form (equations, algorithms etc) that slightly varies each time you look at it. The value of it is also constrained by the author's intent and work. Only humans can be subject to copyright, so it at least makes common (if not legal) sense.
ML models are the same as the generative art that previously existed - they only add the captured essence of the prior data to the mix of human artistic intent and hard algorithms.
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.
(Which, I may add, is very disappointing since <> was expressly designed as delimiters to safely contain a link in emails and other plain-text formats, and has always been well-supported as such by other systems.)
I have a hard time seeing how Intel v ULSI applies here. The decision in Intel v ULSI rests quite heavily on the idea that the nexus of the violation of the patent happens during the manufacturing process and not the design process. That is, the court looked at the contract to find that HP was selling the potentially-violating chips.
That fact is hard to extend to GitHub: GitHub is very arguably a mere distributor of software, not providing the "sale" that would exhaust patent rights. The sort of tortured logic you would have to get to to reach this fact is the kind of logic that tends to lose at court, and furthermore is unlikely to find many supporters in open source software legal teams (it would render most of the GPL null and void, for example).
GPL did not handle any patents until version 3. As for version 3, it has a patent grant clause.
Even distributing BSD licensed code by a licensee exhausts patents embodied in it.
(As an interesting case, this might mean patents related to code published as ISO examples voids MP3 patents on specific algorithms used in that code. The question then is if the standard body is a licensee.)
"Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with."
Interesting. I've never delved that far into misuse but that makes sense. Is that piece a US specific thing or common in others?
As you say it would not have too much practical effect since it's curable trivially. You'd get a few hours of unrestricted mongo use, maybe, but I bet the official order would post-date the blog post fixing it :)
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).
i mean to be fair that's the big problem with most licenses as "not written very well" covers almost all problems with contracts :)
Like the LGPL is confusing because it is not written well in some sense. But that goes to "confusing" instead of "unenforceable".
But yes, better written the problem with this license would just be "They are trying to claim things they know they can't claim" instead of "they are actually claiming things they know they can't claim".
The next question that would pop into my head would then be "At what point does attempting to claim rights to things you know you can't, as a way of scaring people into paying you, cross into unfair and deceptive trade practices"
Sorry, I just meant: "a more conscientious lawyer could have straightforwardly drafted that contract to avoid some of its major problems". Like, the subtext of the question is, if I was MongoDB, and stipulating that I didn't create unreasonable work conditions like "get it done in a day", should I be pissed at my lawyer?
Additional question: if you can fix that problem with the contract with a "to the extent possible" predicate, is that really not the default? Like, if a clause can be interpreted as requiring the impossible, even if a straightforward alternate interpretation doesn't, that clause is broken?
Yes, they could have.
So yes, you should be pissed at your lawyer if they didn't warn you.
In my experience, the lawyers mostly warned the clients and the clients did it anyway.
Part of being a lawyer is simultaneously taking the blame for stuff like that while having done very careful diligence so that your malpractice insurance rates don't go up from clients successfully suing you :)
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.
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.
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)
(Replying to the top-ranked comment so that as many people as possible see it)
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.'
"I don't mind renaming this project. Any other suggestions for good names? I personally like "Pythonesque (/usr/bin/pesque)" the best so far, thanks @dbohdan! :-)"
- The Author (who isn't me)
https://github.com/naftaliharris/python2.8/issues/47#issuecomment-266240525
However, even minor changes (such as changing the tint of the photo) have been found to be enough for copyrightability.