Doubts about Folder structure + licenses for Lua stuff

[Augusto Rodrigues]

Hey folks, 

Just wondering—do other projects usually follow this kind of folder structure to organize Lua script files (which contain application rules) and the licenses for LuaJIT, reflect.lua, Lua and other licenses?

my_project/

├── src/

│   ├── main.lua              # Main app code

│   ├── reflect.lua           # reflect.lua library

├── LICENSES/

│   ├── LICENSE_reflect       # MIT license for reflect.lua

│   ├── LICENSE_luajit        # MIT license for LuaJIT

│   ├── LICENSE_others_stuff        # others license

│   └── LICENSE_lua           # MIT license for Lua itself

│── README.md                 # Project docs

Its normal rename license files for each Lua stuff ?

Or is this more of a personal setup? I am curious to know if there's a common practice around this.

Cheers

[Sainan]

Personally, I put the licence in the 'most relevant' folder, so e.g.:

my_project/
LICENCE
vendor/
some_lib/
LICENCE

However, in the case of the MIT licence, it is perfectly valid to only copy the "Copright" lines as long as at least one copy of the full legal text is included in your work, reducing the need for multiple files.

-- Sainan

[Denis Dos Santos Silva]

you can create a single file.

 

echo license1.txt > licenses.txt

echo license2.txt >> licenses.txt 

...

echo license10.txt > licenses.txt

[Gerhard Sittig]

On Mon, 2025-05-26 at 14:16 -0300, Augusto Rodrigues wrote:
>
> ├── LICENSES/
> │ ├── LICENSE_reflect # MIT license for reflect.lua
> │ ├── LICENSE_luajit # MIT license for LuaJIT
> │ ├── LICENSE_others_stuff # others license
> │ └── LICENSE_lua # MIT license for Lua itself

For licensing you may consider https://reuse.software/ while the
LICENSES/ folder name suggests that your cited project started
going that route. Though I am to understand that you don't name
the licence files after projects, but after licenses. And have
SPDX markers in the source to tell which license they follow.

virtually yours
Gerhard Sittig

[blog...@gmail.com]

>Its normal rename license files for each Lua stuff ?

Yes, filename its just filename

>Or is this more of a personal setup? I am curious to know if there's a common practice around this.

The only requirement for you is to notify users about the license. And you can do it as you like, as is reasonable for the project. Many simply put all the license files in one file, some, like you, put them separately in one directory, some divide the project into subproject directories and attach a subproject license file there. This is just a different organization of the project structure.

суббота, 31 мая 2025 г. в 10:25:43 UTC+3, Gerhard Sittig:

[Augusto Rodrigues]

Thanks for the suggestions, guys

I liked the idea of separating the licenses into subdirectories in a directory called LICENCE. Can I then keep in each subdirectory just the license file without the free software component, which would be in another directory?

Or in this case would each license subdirectory have to keep the license files together with the component sources?

Regarding the "only requirement" mentioned in the emails from this list about free software licenses.

In practice, can these organizations that do not disclose the use of these components but respect the other terms of the free source license have any legal impact? Assume only MIT free source licenses.

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/f2a10c40-6677-46ea-936f-06dc3415093en%40googlegroups.com.

[Frank Dana (FeRD)]

On Saturday, May 31, 2025 at 3:25:43 AM UTC-4 Gerhard Sittig wrote:

For licensing you may consider https://reuse.software/

+1, cannot recommend highly enough.

 

Though I am to understand that you don't name
the licence files after projects, but after licenses. And have
SPDX markers in the source to tell which license they follow.

That's right, mostly because: 

1.  There's no such thing as "the license" (singular) for an open-source project of any real complexity. As soon as it grows beyond a dozen or so files, it's likely that it'll incorporate at least one that's covered by a different, but compatible, license. Which means that when you incorporate code from one of those more-than-trivially-complex projects into your project, it'll be potentially adding multiple new licenses to your project's total SPDX license expression (unless some of them were already brought in by existing source), which will end up being something like "GPL-3.0-or-later AND (Apache-2.0 OR BSD-3-clause) AND BSD-3-clause AND MIT AND CC-BY-SA-4.0".
2. Nobody wants to organize their source code by applicable license, that's just not a comfortable structure even if it can be made workable. Licenses are mapped to source code by /* SPDX-License-Identifier: $LICENSEID */ comments in the file, not by its location on disk.
3. The goal for at least the OSI-approved open-source licenses is that they be standard, meaning if bundledLibraryA and bundledLibraryB and some of your files in src/ are all licensed GPL-3.0-or-later, the license text for all three is the SAME. So you only need one copy of LICENSES/GPL-3.0-or-later.txt; there's no reason to have three separate LICENSES/LICENSE_bundledLibraryA, LICENSES/LICENSE_bundledLibraryB and LICENSES/LICENSE_thisProject all containing the exact same text.
   

(Some older license boilerplates still contain "fill-in-the-blank" areas for each project to customize, so that the license texts aren't the same, but that kind of thing is falling out of fashion in favor of reproducible fixed licenses that can be verified as identical to the original source text.)

[Augusto Rodrigues]

Hi folks,

I really wanted to thank you for the licensing suggestions you shared here on the list. And I will review the suggestions later. 

-- Thanks for the contribution

--

You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/199df45a-fa16-4d61-819d-1299fab7ac3an%40googlegroups.com.

[Denis Dos Santos Silva]

a real world example

https://legato.io/

https://docs.legato.io/latest/Legato_16_10_1_OpenSourceLicenses.pdf

https://superset.apache.org/

https://raw.githubusercontent.com/apache/superset/refs/heads/master/LICENSE.txt

kind regards,

Denis