Closed n76 closed 1 year ago
anthonylavado
commented
4 years ago So we may actually have an issue, which is another reason that I wanted this split in to a different issue.
We may have to adopt a dual licensing model for the channel, where the code is available one way, but we also explicitly grant Roku a license to publish without the source code limitations (but only for the compiled channel resources).
neilsb
commented
1 year ago I think this is probably best discussed at a project level rather than a specific client. We'll take the lead from that the main project/clients are doing.
The issue specifically with fonts is the size of the font files and the maximum channel size Roku allow uploading, so until something changes, when we do support external fonts we'll not distribute them within the Roku application.
ropm also now exists (basically npm for brightscript`) and we are making use of that, so sharing of reusable code or modules can be done this way.
Describe the feature you'd like
I believe that the source files should contain headers compliant with the reuse.software scheme showing licensing on a file by file basis.
Additional context
While Roku code is pretty unique, borrowing open source elements (icons, fonts, etc.) almost guarantees that not all files in the repository will share the same license.
For example, Roku does not have built in support for Cyrillic alphabets. If you wish to support that in the translations then a custom font will need to be added to the channel repository. Since it seems that many open fonts are licensed through the open font license, Apache license or even GPL3 license rather than GPL2 and since you can't change the licensing terms on things you import there needs to be a way of showing on a file by file basis what the licensing terms are and who the owner is. Another example might be use of icons.
Maybe the Jellyfin project has enough talent to create all of the icons and/or fonts it needs so licensing for its own use it not an issue. But even in that case, other projects might want to make use of those icons, fonts or even Brightscript utility functions and will need to track that the files they borrow are GPL2 only and created by the Jellyfin project. If they are so labeled to begin with then it makes it nicer for the whole FOSS ecosystem.
Finally, while Jellyfin is open source, the project might wish to protect its branding. So the project might want to use an exclusive, non-open source, license for things like the Jellyfin logo and its derived use in other graphics (splash screens, etc.). Again, that requires some way to track licenses on a file by file basis.
The scheme promoted by reuse.software scheme seems to fit the need fairly well.