Giter Club home page Giter Club logo

Comments (11)

ryanmcdermott avatar ryanmcdermott commented on May 2, 2024 4

Thanks for your concerns and contributions Laurent!

I am not a lawyer, so I won't address how keeping a LICENSE out of each source file affects the freedom of the use thereof. In Clean Code, they actually suggest that Legal comments are good. I chose to go against that advice because many, many JavaScript libraries/projects just simply keep a LICENSE file in the top of the source tree. I don't know what the legal precedent is on it, and don't want to touch on that, therefore it's probably safer to get rid of this piece of advice.

All that said, I think I should remove this subsection, unless anyone has strong opinions to the contrary.

from clean-code-javascript.

Kasijjuf avatar Kasijjuf commented on May 2, 2024 3

Allow me to direct your attention to the Official GNU Licenses FAQ on GNU.org:

Why should I put a license notice in each source file? (#NoticeInSourceFile)

You should put a notice at the start of each source file, stating what license it carries, in order to avoid risk of the code's getting disconnected from its license. If your repository's README says that source file is under the GNU GPL, what happens if someone copies that file to another program? That other context may not show what the file's license is. It may appear to have some other license, or no license at all (which would make the code nonfree).

Adding a copyright notice and a license notice at the start of each source file is easy and makes such confusion unlikely.

This has nothing to do with the specifics of the GNU GPL. It is true for any free license.

Is it enough just to put a copy of the GNU GPL in my repository? (#LicenseCopyOnly)

Just putting a copy of the GNU GPL in a file in your repository does not explicitly state that the code in the same repository may be used under the GNU GPL. Without such a statement, it's not entirely clear that the permissions in the license really apply to any particular source file. An explicit statement saying that eliminates all doubt.

A file containing just a license, without a statement that certain other files are covered by that license, resembles a file containing just a subroutine which is never called from anywhere else. The resemblance is not perfect: lawyers and courts might apply common sense and conclude that you must have put the copy of the GNU GPL there because you wanted to license the code that way. Or they might not. Why leave an uncertainty?

This statement should be in each source file. A clear statement in the program's README file is legally sufficient as long as that accompanies the code, but it is easy for them to get separated. Why take a risk of uncertainty about your code's license?

This has nothing to do with the specifics of the GNU GPL. It is true for any free license.

from clean-code-javascript.

lcseguin avatar lcseguin commented on May 2, 2024 2

Hello @ryanmcdermott

Being clear about the applicable terms of your code is very important, especially if you publish it.
It is not a matter of free or non-free license, it's about the simple question "what can i do with this code?". As a developer, if i'm not absolutely certain that i can reuse/improve a code written by someone else, i don't use it (to protect myself and users of my code against any copyright claim).

I agree with you that putting 50 lines of copyright/licence notice on the top of the file is not a good idea and everything must be in a LICENSE file.

That why i suggest to improve your legal section with an advice to simply add some minimal information on the top each file, like :

/*
  @licstart 
     Copyright (©) 2017 My[Company]Name
     Available under the terms of the GNU/LGPL-3.0
     See LICENSE file for more informations.
  @licend 
*/

from clean-code-javascript.

Calinou avatar Calinou commented on May 2, 2024 1

Indeed, in fact I was quite shocked when I saw this recommendation as the last one of the guide. It's a very common practice to add a license boilerplate at the top of each source file, and any smart IDE will hide it for you if you want. The file size argument is also a bit moot in 2017.

from clean-code-javascript.

cookiengineer avatar cookiengineer commented on May 2, 2024 1

If we don't our software, which is not open source, will be open sourced automatically. Even though we have our copyrights in every file.

That is plain wrong. No license means the code is owned by its copyright holder; which was the author of the code as it's treated as "speech" or literature in front of the law.

from clean-code-javascript.

lcseguin avatar lcseguin commented on May 2, 2024 1

@Tarabass It is more complicated as that :-) If the original code is released under the terms of a copyleft license, you can't remove to others the freedom that you have benefit from the original work. For weak copyleft license (as LGPL) it concern only the original code, for strong copyleft (as GPL) it concern all the aggregate where the code is (that's why you can't include GPL code in a software that is non-free or released under the terms of a license incompatible with the GPL).

But all of that discussion, is far away of "add a legal mention on your code" ;-)

from clean-code-javascript.

nicolasmaia avatar nicolasmaia commented on May 2, 2024

Agreed per Calinou

from clean-code-javascript.

cookiengineer avatar cookiengineer commented on May 2, 2024

3 When someone snoop your code on your web-based stuff in production, the LICENSE file is often absent or not reachable.
So, as author, you must be absolutely clear about your licenses intentions, especially if you want protects freedom of users of your code users.

@lcseguin The problem I have with your argument is that you kind of are implying that everything by default is open source and can be reused. That's not the case, when a file has no LICENSE in it, you cannot reuse it as per copyright. Let alone problems with the typical transpiler stuff in the real world; which will crash all copyleft license behaviours anyways. Not a single transpiler that I personally know of sorts properly by license to compile stuff down together ...

But I agree with the point that partial licensing might be an issue and needs a proper resolution. Instead of copy/pasting the same license, a one line header with MPL-2.0, MIT, GPL3 or whatever shorthand and the copyright owners would do the trick because I think that's exactly what https://spdx.org/licenses/ is existing for.

from clean-code-javascript.

Tarabass avatar Tarabass commented on May 2, 2024

At the company where I work we check every file (.cs, .js, .sql, etc.) for copyrights. This will break the build. I got my IDE's configured so they will add copyrights automatically on creating new files. It is very important to have your copyrights in every file.

We also have a license file, but we use that copyright information about software/libraries we use in our software. If we don't our software, which is not open source, will be open sourced automatically. Even though we have our copyrights in every file.

The funny part is that we add copyrights to our source code, but after uglifying/minifying our js all comments and copyrights are removed. So our production code that will be shipped has no copyright section (yet).

from clean-code-javascript.

Tarabass avatar Tarabass commented on May 2, 2024

I think, and I don't know much about this subject, that we keep the copyrights indeed. I didn't mean to say we weren't. I think that if we don't mention the authors etc. in our license file, our software can get the same license as GNU. Or something like that.

from clean-code-javascript.

ryanmcdermott avatar ryanmcdermott commented on May 2, 2024

Since we are getting to thorny legal territory, and since Clean Code disagrees with what's stated in this document, I've removed this legal comments subsection. Thanks so much for raising these points!

ec8fd24

from clean-code-javascript.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.