Legal caveats when using these assets

Unity Courses Ask
,
#1

Hi, I’m going through these lectures but I’m doing it version-controlled. The repo is currently private, so no real worries there, but what if, some day, I decide to build upon this game, make something personal out of it and I want to share it with the world and make this repo public (so, not just sharing the finished game, but also the actual process, or for anyone who wants to fork and build upon it) … Repo public; means all history public; means art assets public :thinking:

Obviously, first of all, I’m assuming these asset packs are available only for enrolled, paying students, right?

And secondly, just in general (but depending on the 1st answer, it will probably apply here as well): what’s the recommended approach when working with such not-for-share assets?

My current train of thought: have a single AssetPacks folder, .gitignore that one, and then inside that AssetPacks folder I can again create a new repository which then remains private (or is only shared with whoever is allowed to have that content, e.g., within a team). Going more advanced (but then I’d have to learn some more advanced git that’s not available on gamedev.tv): I could probably even go with git submodules: if I check out an older version of the project, then the AssetPacks folder also reverts to its state at that point in time.

The main problem I see here: even though the repo is public, this makes the project unshareable, no? Even if the other person also has those assets … Without the .meta files, importer settings such as the pixels-per-unit from this lesson are not shared. So, if another person checks out my project, adds his download of the asset pack, then everything would still look disproportionate …

Alternatively, I could have any kind of structure, and finegrained .gitignore every single file that cannot be shared (the nice thing: the .gitignore file would at least document which assets other people would need for everything to work; but then having an entire assets “library” folder with many unused assets is less interesting), but keep the .meta files shared. I’m not sure if this works, though, the other person would have to manually copy every single asset over, which is tedious work, and I’m also not sure what happens if they open up the project without the assets in place, wouldn’t those .meta files simply disappear? (well, version control in fact makes this a non-issue)

But … Maybe I’m overthinking this?? :grinning_face_with_smiling_eyes:

#2

Rick and others in the team have said they’re fine for you to use their code/assets. I do remember that there are some external assets that were used that cannot be used for commercial purposes.

It doesn’t exactly answer your question directly but does in a round-about way. When I bring in an asset pack (for example, one that I cannot distribute) I put them all in a particular directory, like ImportedPackages and exclude that directory in your .gitignore directory, so anyone who wants to use those packages needs to download/pay for them.

#3

Okay, cool! So I guess I don’t have to be too worried in this particular case :slight_smile: Of course, it would have been useful if the asset packs just had some license info in there …

I’m not considering anything commercial, though, just thought it was curious if anyone could just go on my github and find the entire (in this case) “Delivery Driver Assets” package without having to at least enroll for the courses. So I’m still wondering: I can certainly understand that it is fine to just use the assets (in your finished, compiled game), but is it also fine that the source files themselves (the entire pack, or even just a select number of .png’s) are available online as well?

#4

Alright … Could it be that this is kinda the “industry standard” (as far as standards go when sharing a game project on github)? So then others just need to fetch the assets from somewhere (or even just create their own alternative assets to plug in there).

When they want to use the exact same assets as you use in your project: when you’re changing the default importer settings (pixels per unit as in this exercise, or texture resolutions, or importing a texture as grayscale, or …), that information is lost for those other people, right? (or even for yourself if you check out the project on another machine; of course you can just copy over the package folder with .meta-files)

#5

They already have their code/assets in their own github and/or Gitlab, so the assets are already on those sites.

It could be. I honestly don’t know. I saw it done this way once and I ran with it.

It depends. There’s a file, I think it’s packages.json file that has information about what packages are included in the project. If that info is included, I assumed it’d just sort it out from that.

#6

Thanks a lot! Yeah, didn’t realize that those assets are indeed already publicly available (not “just a google search away” but indeed freely available from the course repos).

I’ll also stick to ignoring a folder with imported asset packs, and just adding a readme-file documenting which assets/asset packs are needed, and indicating where I’m not using default import settings. For instance, here, I’d have a readme saying I’ve included the “delivery driver assets”, and that the road segments are imported at 75 pixels per unit.

Even though it’s okay to use these assets, I’ll still ignore them in my repo. Maybe I’ll learn stuff in the future when I encounter issues with this (plus, it has already been a nice thought exercise) :sweat_smile: Also, I still believe it’s unfortunate that there’s no license information with the pack itself (or maybe it’s really an oversight?), especially when reading info on “No License”. I’ve always found licensing and copyright a confusing subject though, but it’s still something I want to learn to do right …

#7

Basic rule of thumb… When you’re learning/studying, don’t worry about it too much. If you use things that are an obvious copyright breach, don’t post them too publically (like Youtube etc) and definitely don’t try to earn money from it.

Once you get to a point where you’re building your portfolio all the way to paying clients, I suggest making sure you only use licenced material or material you create yourself.

#8

“too publically”, that’s up for some interpretation :sweat_smile:

Yeah, still learning here but I’m not new to Unity, so in these introductory courses I’m just trying to (over)think one step outside of what’s actually handled in the lectures, whether it’s a technical step (“how do scene/asset/gameobject changes translate into .meta-files and .scene files”) or a project management/legal step as I’m overthinking right now :slight_smile:

As long as you’re not making any money out if it, I assume even a public repo is still fine as “public” is still relative (I’m not sure how many people will “accidentally stumble upon my github repo to find images that are actually not mine”). Of course, if you actually paid for stuff, that’s easier to know what to do :smiley:

#9

Look, I think you’d be fine… however, there’s a but. If (practically speaking) you’re looking at your repo as your portfolio (or part of your portfolio), you’re potentially asking for trouble.

If you’re putting it up there as a “Anyone can learn from it if they stumble upon it”, yeah, I’d say (that’s me personally) that’s more than fine.

#10

Thanks! I don’t have anything public yet, I’m just wondering “what if”. Thanks a lot for all of that context :slight_smile:

2 Likes
#11

Legally speaking, don’t use copyrighted material without a licence FULL STOP. In the world of learning/students/personal/passion projects, most don’t care… but you may come across some that do.

2 Likes
#13

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms