licenses/lice

Generate license files for your projects

lice's Issues

LICENSE-2.0

Release a new version

Hi,

The current version in pypi (0.4) is 3 years old. The issue is that is does not work with Python3, and some of the documented options (such as -l to select a language) are not present in this version.

Is it possible to release a new version? Thanks!

TypeError under Python 3

[36+]:> lice --vars lgpl
Traceback (most recent call last):
  File "c:\python33\scripts\lice-script.py", line 9, in <module>
    load_entry_point('lice==0.3', 'console_scripts', 'lice')()
  File "C:\Python33\lib\site-packages\lice\core.py", line 149, in main
    var_list = extract_vars(template)
  File "C:\Python33\lib\site-packages\lice\core.py", line 75, in extract_vars
    for match in re.finditer(r"\{\{ (?P<key>\w+) \}\}", template):
  File "C:\Python33\lib\re.py", line 210, in finditer
    return _compile(pattern, flags).finditer(string)
TypeError: can't use a string pattern on a bytes-like object

Print list of available styles

Is it worth to add support for printing (in shell) a list of availble languages styles ? As this light might grow, it will look a bit weird to display all of them them in the usage screen. In my opinion.

Suggesting:

$ lice --styles

Expected output:

c
cpp
fortran90
javascript
lua
python
unix
...

Thoughts ?

Experimental support of license-templates as template source.

https://github.com/ksd5/lice/tree/template-submodule

I haven't tested it, but I don't think it should have any problems.

What do you think of it?

two bugs

1. When python version is 3.x and no git username config, line 119 "getpass.getuser()" return a str that do not have "decode" method.
2. When arg lang and arg file without ext were specified, it use txt format.

Infer language only on the basis of file extension

Something have been bothering me since a few days, then I am opening the debate.
Actually, I have the feeling that the -l (for language) and -f (for output filename) can lead to potential confusions.
For instance, with the actual implementation, what happens with this ?

$ lice -l py -f test.c

Well, it might output something. But this rather means that there is some precedence rules involved, and the user should learn about them before using lice.

And what if I want to generate an .hpp file with a license header ?

$ lice -f foo.hpp

Yes, that one might work, but using the -l attribute would not. Because .hpp is a c++ source, but on the other side, c++ language is associated with different extensions (.cpp, .hpp, etc.).

And, if I try:

$ lice -l cpp foo

Do I get a foo.cpp file ? What If I want a foo.hpp file ?

The point is, there is some inconsistencies here. In my humble opinion.
Then, I was thinking on inferring the language only on the basis of filename extensions. That would mean we should completely give up the -l attribute. Then, on the basis of the extension of filename to output, the comment style would be inferred. In case there is no filename extension specified, then it would default to simple text (txt) style.

Thoughts ?

PS: Actually, I did not try these commands (I am not familiar with Python), but I am just making assumptions reading from the code, so I may be wrong on some points.

Use non-newlined license files

Don't waste time adding newlines to wrap license files to a specific width.

Error thrown on "subprocess.check_output('git config --get user.name'.split())"

Error received when calling lice without manually adding organization.

[nagase@localhost ConnectionMon]$ lice
Traceback (most recent call last):
File "/home/nagase/.local/bin/lice", line 9, in
load_entry_point('lice==0.2', 'console_scripts', 'lice')()
File "/home/nagase/.local/lib/python2.7/site-packages/lice/core.py", line 132, in main
"organization": args.organization or guess_organization(),
File "/home/nagase/.local/lib/python2.7/site-packages/lice/core.py", line 31, in guess_organization
stdout = subprocess.check_output('git config --get user.name'.split())
File "/usr/lib64/python2.7/subprocess.py", line 544, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['git', 'config', '--get', 'user.name']' returned non-zero exit status 1

Unfortunately, I do not know how to be a greater help but I felt like I should report the error. The source I have varies from what is currently on github but both show version 0.2

Continuing this Project

As it seems this project is not getting updated, I have forked and released lice2.

This version fixes the compatibility issue with Python 3.12, and adds some new features:

• It now uses Poetry for dependency management.
• Can read from a config file for default values.
• Converted from 'argparse' to 'Typer' for CLI handling.
• Fixes the issue where extra spaces and newlines were added to the generated license text. This was considered a bug by at least several users, However, if you want to generate a license with the old style, you can use the --legacy option or set the legacy key in the configuration file to true.
• The code has been modernized and cleaned up, all type-hinting has been added.
• It passes strict linting with the latest 'Ruff' and 'mypy'.
• Added a documentation site.
• GitHub actions set up for linting, Dependabot and Dependency Review.

I plan to keep maintaining it for the forseeable future and have a few ideas for new features.

Check it out on https://seapagan.github.io/lice2/ and let me know any bugs or suggestions. Star the new repo (https://github.com/seapagan/lice2) so more people can find it 😁

Licenses have extra spaces and newlines

Generated licenses add a newline at the beginning of the file and two newlines at the end. Also every line starts with a space character.

Example:

$ lice mit -o "Name" -p "Project" -f "LICENSE"

Outputs

 The MIT License (MIT)
 Copyright (c) 2020 Name
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so, subject to the following conditions:
 
 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.
 
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
 DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
 OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
 OR OTHER DEALINGS IN THE SOFTWARE.

Instead of:

The MIT License (MIT)
Copyright (c) 2020 Name

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

Feature request: Markdown licenses

It would be nice to be able to generate a .md file with appropriate formatting for ones desired license.

I looked through the code to see if this was something I could deliver myself, and it looks like Markdown would not be an effortless fit into the current LANGS and LANG_CMT scheme.

A bare-bones implementation might only had a ## prefix to the first line. A more full-featured one might also attempt to provide a link to the users GithHub by looking in .gitconfig.

Implementation guidelines for spreading lice ?

It might be too early to say, but anyway.
I was thinking of creating a new repository and push there a markdown document summarizing guidelines for implementing Lice in other languages.
It could serve for implementation purposes, giving rules and pointers to developers willing to port Lice in their favorite language.
And also, to users. As being language-agnostic, this document will undoubtedly help them understand how lice works.

feature_request(validation): validate license files

1. Summary

It would be nice, if license files will be valid.

2. Argumentation

1. I use Markdownlint for validating Markdown files.
2. I prefer tabs, not spaces. I use EClint, that check, that in all my files tabs indentation.

3. Steps to reproduce

lice mit --file LICENSE.md

markdownlint LICENSE.md

eclint check LICENSE.md

4. Expected behavior

No output in console.

5. Actual behavior

Markdownlint:

D:\Kristinita>markdownlint LICENSE.md
LICENSE.md: 4: MD009/no-trailing-spaces Trailing spaces [Expected: 0; Actual: 1]
LICENSE.md: 11: MD009/no-trailing-spaces Trailing spaces [Expected: 0; Actual: 1]
LICENSE.md: 14: MD009/no-trailing-spaces Trailing spaces [Expected: 0; Actual: 1]
LICENSE.md: 23: MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

ECLint:

D:\Kristinita>eclint check LICENSE.md
LICENSE.md
    02:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    03:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    05:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    06:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    07:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    08:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    09:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    10:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    12:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    13:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    15:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    16:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    17:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    18:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    19:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    20:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)
    21:01 ❌️ invalid indent style: space, expected: tab (EditorConfig indent_style https://goo.gl/8Qkrbr)

Extra spaces in beginning of each line:

I can't fix it, use eclint fix.

6. Not helped

1. --template option. I make template without leading spaces → lice generate leading spaces.

Thanks.

Support .lice configuration file

Add support for a .lice configuration file that can live in the project root. This file could contain the year, organization, or project values that would be used to generate the license file.

In-file Apache/GNU/MPL headers

It would be nice if there was a template that produced only the in-file text for a given licence. Being able to run :r!lice gpl3-header in vim would be great. Not sure if it should be handled by duplicating the text content or if it deserves a shortcut option, so I won't open a PR yet.

I do have one general question while I've got your attention… I'm curious about the choice to re-wrap the texts, it seems a little strange and I don't believe I've seen it in any packages I use. I'm just curious about the reasoning, but it doesn't bother me that much as I can use the path to a "clean" text with -t.

Thanks,

James

PS. I specifically call out the ApacheGNU/MPL licences as they definitely have defined in-file sections, but perhaps some of the others I'm unfamiliar with also have them.

Not supporting Python 3.4

Here is the traceback:
Traceback (most recent call last):
File "h:\Python\Python34\Scripts\lice-script.py", line 9, in
load_entry_point('lice==0.4', 'console_scripts', 'lice')()
File "H:\Python\Python34\lib\site-packages\lice__init__.py", line 6, in main
main()
File "H:\Python\Python34\lib\site-packages\lice\core.py", line 171, in main
content = generate_license(template.decode("UTF-8"), get_context(args))
AttributeError: 'str' object has no attribute 'decode'

That method is only in Python 2, and it does not support Python 3, but lice is in the category called Programming Language :: Python :: 3. That's confusing,

Don't render the boilerplate in the license template.

For example, the gpl-2.0 license, we don't have to render the boilerplate at the end of the license, all we need is just copy the content into a file named LICENSE.
Let me know if I was wrong.

Additional licenses e.g. Creative Commons, OSI-approved licenses.

I was on tldrlegal.com looking for a license for a piece of work and the one I settled on was the Creative Commons Attribution-NonCommercial v3 licence. lice doesn't support this license and there's also a few on the list of OSI-approved licenses that aren't supported.

I was wondering if there was any criteria by which licenses are put into lice. I'm guessing at this point, the focus has been on popular, open-source licences. I'd be happy to add the Creative Commons ones if they're are eligible.

existing file

@Yonaba
Though, i am willing to add something on the top of it. In case the file to be generated already exists, it will be opened, license will be appended as an header and then file will be saved.

At this moment lice have this future, in default mode open the file in read/binary mode append a license as a header and save/close it.
We can add a --force argument and add a answer before lice write the file which is showed only if the file already exist.
something like:

$ lice -f test.py
do you want write <license> license in test.py?[Y/n]

and with --force:

$ ls
test.py
$ lice -f test.py --force

WTFPL copyright notice and source header

I believe that the copyright notice on the WTFPL, which in the original reads "Copyright (C) 2004 Sam Hocevar [email protected]" should not be replaced by the copyright holder of the software. Lice currently replaces the year and name in that line. I'm not sure about this though. I think that is the copyright notice for the text of the license itself.

The FAQ on wtfpl.net explains, for this section of the license file:
"These are the rules for the license; they mean Sam Hocevar wrote the license, and you can modify it if you want, you just cannot call your version the WTFPL."

Also, if I'm reading the first question on that same FAQ correctly, the following can be used for source file headers, which lice currently doesn't include for the WTFPL.

Copyright © 2000 Your Name <your@address>
This work is free. You can redistribute it and/or modify it under the
terms of the Do What The Fuck You Want To Public License, Version 2,
as published by Sam Hocevar. See the COPYING file for more details.

Affero GPL

Please consider adding the AGPL (version 3) to the templates. See http://www.gnu.org/licenses/agpl-3.0.txt for more details.

Great idea BTW!

Upgrade Creative Commons License to version 4.0