Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flux: Open-source text-to-image model with 12B parameters

blog.fal.ai

Post reply on HN
Print view View original

201–210 of 239 posts

Re: Flux: Open-source text-to-image model with 12B parameters

#201

Post by Hizonner »

jillesvangurp wrote: post #149
Hizonner wrote: post #117

Earlier quoted context omitted.

As far as I know, none have been released. And it doesn't even really make sense, because, as I said, the models aren't copyrightable to begin with and therefore aren't licensable either. However, plenty of open source software exists. The fact that open source models don't exist doesn't excuse attempts to falsely claim the prestige of the phrase "open source".

> models aren't copyrightable to begin with You are wrong about that. It's a file with numbers. Which makes it a database or dataset and very much protected by copyright. That's why licenses are needed. For the phone book, things like open street maps, and indeed AI models. > The fact that open source models don't exist The fact that many people (myself included) routinely download and use models distributed under OS…

> Which makes it a database or dataset and very much protected by copyright.

Not every collection of numbers is a database, and a database is not the same thing as a dataset.

Databases have limited copyright-like protection in some places. Under TRIPS, that extends to only databases that are "creative by virtue of the selection or arrangement of their contents" or something along those lines. In the US they talk specifically about curation.

ML models do not meet either requirement by any reasonable interpretation.

> The fact that many people (myself included) routinely download and use models distributed under OSI approved licenses (Apache V2, MIT, etc.) makes that statement verifiably wrong.

The "source code" of an ML model is most reasonably interpreted as including all of the training data, which are never, ever available.

Now you know better.

[On edit: By the way, the people creating these works had better hope they're outside copyright, because if not, each one of them is a derivative work of (at least some large and almost impossible to identify subset of) its training data, so they need licenses from all the copyright holders of that training material, which few of them have or can get.]

Re: Flux: Open-source text-to-image model with 12B parameters

#202

Post by kube-system »

filleokus wrote: post #185
astrange wrote: post #157

Earlier quoted context omitted.

It's certainly not true that models are not copyrightable; databases have copyright protection if creativity was involved in creating them. That said, I don't think outputs of the model are derivative works of it, any more than the model is a derivative of its training data, so it's not clear to me they can actually enforce what you do with them.

> It's certainly not true that models are not copyrightable; databases have copyright protection if creativity was involved in creating them. Are you talking about https://en.wikipedia.org/wiki/Database_right or plain old copyright? I'm no IP lawyer, but I've always thought that copyright put "requirements" on the artefact (i.e the threshold of originality), not the process. In my jurisdiction we have database rights…

These models are a product of much more creativity than simply a list of phone numbers in a phone book. I don't see how they wouldn't meet the modicum of creativity required for US copyright protection.

Re: Flux: Open-source text-to-image model with 12B parameters

#203

Post by kube-system »

Hizonner wrote: post #117
astromaniak wrote: post #116

Earlier quoted context omitted.

> it is not open source It would be nice here if you give some examples of what you call open source model. Please ;) Because the impression is that these things do not exist, it's just a dream which does not deserve such a nice term..

As far as I know, none have been released. And it doesn't even really make sense, because, as I said, the models aren't copyrightable to begin with and therefore aren't licensable either. However, plenty of open source software exists. The fact that open source models don't exist doesn't excuse attempts to falsely claim the prestige of the phrase "open source".

> the models aren't copyrightable to begin with

What criteria for copyright protection are they missing?

Re: Flux: Open-source text-to-image model with 12B parameters

#204

Post by Hizonner »

simonw wrote: post #192
dagaci wrote: post #179

Earlier quoted context omitted.

Open source must include source material so that another can reproduce that the model. I would expect that to be a minimum.

I agree, but that can't happen with the vast majority of these models because they're trained on unlicensed data so they can't slap an open source license on the training data and distribute it. I've decided to draw my personal line at Open Source Initiative compliance for the license they release the model itself under. I respect the opinion that it's not truly open source unless they release the training data as we…

> that can't happen with the vast majority of these models because they're trained on unlicensed data

Tough beans? There's lots of actual software that can't be open source because it embeds stuff with incompatible restrictions, but nobody tries to redefine "open source" because of that.

... and, on a vaguely similar-flavored note, you'd better hope that the models you're using end up found to be noninfringing or fair use or something with respect to those "unlicensed data", because otherwise you're in a world of hurt. It's actually a lot easier to argue that the models aren't copyrightable than it is to argue that they're not derivative of the input.

> I've decided to draw my personal line at Open Source Initiative compliance for the license they release the model itself under.

You're allowed to draw your personal line about what you'll use anywhere you want, but that doesn't mean that you should try to redefine "open source" or support anybody who does.

Re: Flux: Open-source text-to-image model with 12B parameters

#205

Post by kube-system »

Hizonner wrote: post #201
jillesvangurp wrote: post #149

Earlier quoted context omitted.

> models aren't copyrightable to begin with You are wrong about that. It's a file with numbers. Which makes it a database or dataset and very much protected by copyright. That's why licenses are needed. For the phone book, things like open street maps, and indeed AI models. > The fact that open source models don't exist The fact that many people (myself included) routinely download and use models distributed under OS…

> Which makes it a database or dataset and very much protected by copyright. Not every collection of numbers is a database, and a database is not the same thing as a dataset. Databases have limited copyright-like protection in some places. Under TRIPS, that extends to only databases that are "creative by virtue of the selection or arrangement of their contents" or something along those lines. In the US they talk spec…

If we stop unnecessarily anthropomorphizing software, I think it is plainly obvious these are derivative works. You take the training material, run it through a piece of software, and it produces an output based on that input. Just because the black box in the middle is big and fancy doesn't mean that somehow the output isn't a result of the input.

However, transformativeness is a factor in whether or not there is a fair-use exception for the derivative work. And these models are highly transformative, so this is a strong argument for their fair-use.

Re: Flux: Open-source text-to-image model with 12B parameters

#206

Post by whywhywhywhy »

shagie wrote: post #194
cpfohl wrote: post #178

Earlier quoted context omitted.

Ah. I try the following: > A Gary Larsen, "Far Side" comic of a racoon disguising itself by wearing a fedora and long trench coat. The raccoon's face is mostly hidden by the fedora. There are extra paws sticking out of the front of the trench coat from between the buttons, suggesting that the racoon is in fact a stack of several raccoons. Every human I've ever described this to has no problem picturing what I mean. I…

This gets interesting. One approach that I've used with image generation before is to find an image of the sort that I want, and have Dall-e describe it... and then modify the prompt that it provides to be one with the elements that I want. The first attempt at this based on https://reductress.com/post/my-boyfriends-are-always-two-kid... ... really misunderstood the image. This may also be part of the problem. The im…

Current generation image generators don’t understand text like instructions as you’re trying to do, describing an object then placing it then setting the scene.

It’s more like a giant telescope of many lenses (the latents from the prompts) and you’re adjusting the lenses to bring a possible reality of many into focus.

Re: Flux: Open-source text-to-image model with 12B parameters

#207

Post by Hizonner »

kube-system wrote: post #202
filleokus wrote: post #185

Earlier quoted context omitted.

> It's certainly not true that models are not copyrightable; databases have copyright protection if creativity was involved in creating them. Are you talking about https://en.wikipedia.org/wiki/Database_right or plain old copyright? I'm no IP lawyer, but I've always thought that copyright put "requirements" on the artefact (i.e the threshold of originality), not the process. In my jurisdiction we have database rights…

These models are a product of much more creativity than simply a list of phone numbers in a phone book. I don't see how they wouldn't meet the modicum of creativity required for US copyright protection.

The software that creates the model is the product of creativity. The model itself is the product of mechanically applying that software to datasets that are (a) assembled with minimal, if any creativity, and (b) definitely not assembled with any eye to the specific form of the resulting model. The whole point is to get the software to form the model without you having to worry about what the result is going to look like. So you can't turn around and claim that the model is a creative work because of the choice of training data.

The only thing that's really specified about the model itself is its architecture, which is (1) dictated by function, and (2) usually deeply stereotyped.

Re: Flux: Open-source text-to-image model with 12B parameters

#208

Post by kube-system »

Hizonner wrote: post #207
kube-system wrote: post #202

Earlier quoted context omitted.

These models are a product of much more creativity than simply a list of phone numbers in a phone book. I don't see how they wouldn't meet the modicum of creativity required for US copyright protection.

The software that creates the model is the product of creativity. The model itself is the product of mechanically applying that software to datasets that are (a) assembled with minimal, if any creativity, and (b) definitely not assembled with any eye to the specific form of the resulting model. The whole point is to get the software to form the model without you having to worry about what the result is going to look…

> mechanically applying that software to datasets that are (a) assembled with minimal, if any creativity, and (b) definitely not assembled with any eye to the specific form of the resulting model.

Fair enough, but those datasets are also primarily copyrighted material. If the software here merely transforms the input material (which I agree it does), then the output is a derivative work.

Re: Flux: Open-source text-to-image model with 12B parameters

#209

Post by Hizonner »

kube-system wrote: post #205
Hizonner wrote: post #201

Earlier quoted context omitted.

> Which makes it a database or dataset and very much protected by copyright. Not every collection of numbers is a database, and a database is not the same thing as a dataset. Databases have limited copyright-like protection in some places. Under TRIPS, that extends to only databases that are "creative by virtue of the selection or arrangement of their contents" or something along those lines. In the US they talk spec…

If we stop unnecessarily anthropomorphizing software, I think it is plainly obvious these are derivative works. You take the training material, run it through a piece of software, and it produces an output based on that input. Just because the black box in the middle is big and fancy doesn't mean that somehow the output isn't a result of the input. However, transformativeness is a factor in whether or not there is a…

Maybe, but...

"Fair use" is pretty much entirely a US concept, and similar concepts in other countries aren't isomorphic to it.

The model does have a radically different form from its inputs. So you could easily imagine that being "transformative enough" for US fair use. A lot of the other fair use elements look pretty easy to apply, too. Although there's still the question of whether all the intermediate copies you made to create the model were fair use...

In fact, I'll even concede that a court could find that a model wasn't a derivative work of its inputs to begin with, and not even have to get to the fair use question. The argument would be that the model doesn't actually reproduce any of the creative elements of any particular training input.

I do think a finding like that would be a much bigger stretch than a finding that the model was copyrightable. I could easily see a world where the model was found derivative but was not found copyrightable. And it's actually not clear to me at all that the model has to be copyrightable to infringe the copyright in something else, so that's another mess.

Somewhat related, even if the model itself isn't infringing, it's definitely possible to have most models create outputs that are very similar to (some specific examples in) their training data... in ways that obviously aren't transformative. Outputs that might compete with the original training data and otherwise fail to be fair use. So even if the model is in the clear, users might still have to watch out.

Re: Flux: Open-source text-to-image model with 12B parameters

#210

Post by Hizonner »

kube-system wrote: post #208
Hizonner wrote: post #207

Earlier quoted context omitted.

The software that creates the model is the product of creativity. The model itself is the product of mechanically applying that software to datasets that are (a) assembled with minimal, if any creativity, and (b) definitely not assembled with any eye to the specific form of the resulting model. The whole point is to get the software to form the model without you having to worry about what the result is going to look…

> mechanically applying that software to datasets that are (a) assembled with minimal, if any creativity, and (b) definitely not assembled with any eye to the specific form of the resulting model. Fair enough, but those datasets are also primarily copyrighted material. If the software here merely transforms the input material (which I agree it does), then the output is a derivative work.

But the pitch-shifted song is still recognizably a creative work. It has identifiable, humanly comprehensible forms of all the original creative elements that Swift originally put into it (plus I guess a de minimis amount of extra creativity from the choice to pitch shift it).

If I take a string of data from a true hardware RNG, XOR it with a Taylor Swift song, and throw away the original random stream, is the resulting fundamentally random bit string still a derivative work of the song? As with the ML model, you can't recognize the song in it. And as with at least some training examples in the inputs of most ML models, you can't recover the song from it either.

It feels like the test for whether X is derivative for copyright purposes should include some kind of attention to whether X is a creative work at all. Maybe not, but then what test do you use?

I do recognize the possibility that the models might not themselves be eligible for copyright as independent works, yet still infringe copyright in the training inputs. It seems messy, but not impossible.

... and as I said elsewhere, it's also messy that while you generally can't recover every training input from the model, you can usually recover something very close to some of the training inputs.

Post reply on HN