Coder Social home page Coder Social logo

Comments (6)

monora avatar monora commented on July 21, 2024

Good hint. Thank you. I will try to fix this together with #43.

@martinvahi Would the correct use in case of this library be like this?

# SPDX-License-Identifier: Ruby

See: https://spdx.org/licenses/Ruby

I am a bit confused about this paragraph on the above page.

Standard License Header
There is no standard license header for the license

from rgl.

martinvahi avatar martinvahi commented on July 21, 2024

@martinvahi Would the correct use in case of this library be like this?

# SPDX-License-Identifier: Ruby

I do not know. Up to You, but as little as I know anything about the spdx.org license identifier usage, what You proposed sure seems to be in the correct format. I'm not an expert on the SPDX usage.

What I'm after is some graph (theory) library for my own Ruby Library project, which is under the BSD license. The idea with my own open source projects is that I want to use them at my client projects, which can be closed source projects, but it is OK to demand that the source of open source components, which are open anyway, be published. So, I can use LGPL based sub-components, but pure GPL is too restrictive for my usage. Basically, anything that allows closed source usage without being infectious to the code that uses the open source components is usable by me. The reason I use BSD license in stead of the MIT license is that I want to have a bit of advertisement in return and the BSD license demands advertisement, but for less relevant stuff I tend to use the MIT license and for total irrelevant hacks or small stuff I use "public domain", which is the same as the 0BSD

https://spdx.org/licenses/0BSD

So, very selfishly I write here that if You license Your project under the Ruby license, the
https://spdx.org/licenses/Ruby
then I am happy that I can start to consider re-using Your project code in my project. If it ends up meeting my technical preferences, then I'll probably modify the source. The main issue that I'll probably first address is the problem that often times (I had that problem with my own old code) it is not possible to include multiple versions of a library/dependency in the very same project, because the class names, module names, etc. of different versions of the same project collide. For example, by using a notation like

X -> D1, D2, D3
//meaning: X depends on D1 and D2 and D3

the collision between different versions of the same project can occur at a scenario like

// E1 and E2 and E3 are different versions of the same component/library
A -> B, C, E1
B ->  F
F -> E2
C -> G
G -> H
H -> I, J, E3
// meaning, the collision can come if some dependency 
// of a dependency suddenly starts to use some version of E

For example, may be the H did not even have the dependency E3 at first, but as the developers of H worked on their project, they included the E3 as their dependency, but why should the developers of A be capable of keeping track of all of the nuances of H dependencies, if they trust that the developers of H do not introduce malware? Developers of A just include the newer version of H to their project, run the A tests and if the tests pass, publish A. Ideally the tests of A should fail, if E1 and E3 differ "too much", but the test set is never perfect. As bad as it sounds, even with a very thorough test set the end users will still be in the role of testers to some extent, so it's better, if different versions of the same component, in this case, E1, E2, E3, won't interfere with each other.

Writing about testing, simply verifying that the different versions of the library, for example, the E1, E2, E3, have exactly the same set of classes, which have exactly the same set of methods and method signatures, won't help, because what those methods do, can still differ. Let's say, in the Ruby world, the output of the "to_s" method of a data structure might change and it won't be detectable by just looking at the class names and method signatures. The change won't be detectable by tests either, if the tests miss the corner case, where the change occurs.

So, partly that's why I do not believe in the possibility of backwards compatibility, no matter, what the advertisement. I have made that mistake myself too by using the idea that a dependency can be met by "X version Y or newer". Nowadays, 2020_12, my belief is that dependencies can be met ONLY, PRECISELY, by "X version Y" and NO NEWER VERSION of X should be used, unless explicitly tested and specified during some sufficiently thorough development work. The solution for avoiding the collisions is to use some version specific string in the names of classes, module names, namespace names, etc. so that when forking the project for creating a newer version of it the version string can be changed with multi-file-search-and-replace. That way library client projects can use multiple versions of the library simultaneously. That gives the possibility to refactor older versions of the library out of the project at their own pace, without breaking anything by introducing a new version of the library to the project while the old version or some small sub-parts of it are still in use. The version specific substrings in the class and module and namespace names makes it easy to find the places, where the old version is still being used, avoiding the situation, where the old version is still in use while the assumption is that the old version has been refactored out.

That's a little bit of the background, why I don't want to take other people's work without modifying them myself. :-)

(I am NOT saying that my own projects have been upgraded to meet those requirements. It's just that I have noticed some of my mistakes in the past.)

Thank You for reading my comment.

from rgl.

monora avatar monora commented on July 21, 2024

Since I am not a licensing expert, I am not sure what is the best way to help you using the library without breaking with previous versions. I would also use a BSD-License if this does not break things. Or can I use both? I am happy if as many people possible use the software.

from rgl.

martinvahi avatar martinvahi commented on July 21, 2024

Since I am not a licensing expert, I am not sure what is the best way to help you using the library without breaking with previous versions. I would also use a BSD-License if this does not break things. Or can I use both? I am happy if as many people possible use the software.

That is very kind of You, thank You. The way I understand, a person can license one's own work under multiple licenses. One way to do this is to let people choose the license they like best from some set of licenses. According to

https://spdx.dev/ids/#how

the SPDX has some special syntax for expressing the choice of licenses. In Your case the SPDX license identifier line might be:

SPDX-License-Identifier: BSD-3-Clause-Clear OR Ruby

As the BSD licensed software can be used as part of GPL licensed software, that should suffice, but to make it even clearer and eliminate the advertisement requirement in the case of BSD license, You might use

SPDX-License-Identifier: BSD-3-Clause-Clear OR Ruby OR GPL-2.0+ OR LGPL-2.1-or-later

If You want compatibility with absolutely all possible licenses, then You may use the public domain, which is the same as the

https://spdx.org/licenses/0BSD.html

SPDX-License-Identifier: 0BSD

Generally speaking, the overall differences between different software licenses from copyright point of view are:

  • is the work usable in closed source software;
  • if the work is usable in closed source software, then is there a requirement to disclose modifications to the software; (Example: LGPL allows closed source use, but requires that the open source software modifications are open source.)
  • various forms of attribution, including marking of modifications;
  • various forms of relief of responsibility to the developers of the software;
  • is the license or sub-parts of it infectious to the works that are used in conjunction with the licensed work.

I'm probably forgetting something, but that's the very rough overview.

from rgl.

monora avatar monora commented on July 21, 2024

I now have made the licensing more explicit by merge #56 and #57. But I sticked with the ruby license. I guess this should also be usable for you. Please leave a comment if you think I should also include 0BSD.

from rgl.

martinvahi avatar martinvahi commented on July 21, 2024

Excellent. Thank You.
Now I just need to get using that beauty :-)

from rgl.

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.