Other BSD license and programming language does it matter

Perhaps the only thing I would avoid is proprietary / non-free tools like (Unity, Flash) or those backed by big companies (.NET, Java) because once the company goes kaput, the tools always die too. Even if they are "free", they are often too large for communities to adopt or the licenses too restrictive for another company to take forward.
I am not a fan of Java, although I do think that it should have its advantages, because all what Sun Microsystems supported was first class. Java is omnipresent, the demand is big since 20 years. Do
you really believe there is that risk?!

I am working on a new license based on BSD 3 Clause and BSD 2 Clause,
When one inspects a suftware, it is nice to read BSD, MIT, GNU, etc for not having to carefully read
all details. There are a lot of equivalent licences, many take into account laws in the U.S.A., but
each country has different laws. Do you really need there is a need for more "wordings" of the same
thing?

From all licences, I like MIT (wording) most: it is clearly an exchange, not a (unilateral) disclaimer.
 
You use BSD license, people can take it, add to it and place it under GPL. This DOES NOT affect your license, you will always own your code.
BUT
You can't take back those changes/enhancements made under GPL. It's a one-way street.
That's exactly the scenario that the CDDL tried to solve - The code is free and projects that use/import CDDL code can even be re-licensed, but CDDL-Parts still have to be under CDDL. That's what still prevents Oracle from taking OpenZFS code and including it in their proprietary ZFS. It also explicitly allows the co-existence of other licenses within the same project, which the GPL explicitly forbids (hence it's a viral license).
So if you want to make sure your code will always be freely available but can be used in other projects as long as your code stays free, the CDDL might also be a good fit. The CDDL even allows its modification as long as you rename it - so you could even remove/add clauses. IIRC there even was something like a "simplified CDDL" around that was more tailored towards small/private projects (i.e. removed all the business- and patent-related stuff).

This is quite interesting. Do you have a link to any specific license using that? Seeing the effects of GPL LibreOffice unrelentlessly sucking dry OpenOffice (and then splurging all their donations on trying to build a subscription cloud version), it would be quite cool to know ways to counteract this with the BSD license.
The story with OpenOffice is not the GPLs fault - OpenOffice (as a project led by Sun) was absorbed by Oracle, salvaged for what they needed and left out in the desert to die, just like any other software or project Oracle acquired from/with Sun Microsystems. Most developers left the OOo project during the invasion from Oracle and joined the LibreOffice fork. OpenOffice was already dead from the moment Oracle acquired it - it mostly is only still existent because of the GPL which prevented Oracle from fully merging it into one of their proprietary products and just closing the project.
 
The story with OpenOffice is not the GPLs fault - OpenOffice (as a project led by Sun) was absorbed by Oracle, salvaged for what they needed and left out in the desert to die, just like any other software or project Oracle acquired from/with Sun Microsystems. Most developers left the OOo project during the invasion from Oracle and joined the LibreOffice fork. OpenOffice was already dead from the moment Oracle acquired it - it mostly is only still existent because of the GPL which prevented Oracle from fully merging it into one of their proprietary products and just closing the project.
Are you sure? OpenOffice isn't GPL as far as I can see so if Oracle wanted to close it, they could. The fact that it isn't GPL is also what allows LibreOffice to benefit from the more permissive license, close the code up a little more (to the GPL) and not return anything back.

I am not a fan of Java, although I do think that it should have its advantages, because all what Sun Microsystems supported was first class. Java is omnipresent, the demand is big since 20 years. Do
you really believe there is that risk?!
Compared to .NET I think the risk is slightly smaller but just imagine we are now in the year 2099 and Oracle has stopped any involvement with Java for the last 10-15 years. If you suggest Java to i.e your line manager, I can't imagine them being thrilled. There is no support, Java is too large for you to maintain yourselves. I think java will fizzle out slowly rather than being destroyed purposefully. Of course you can still fit a few projects in between now and then ;)
 
Are you sure? OpenOffice isn't GPL as far as I can see so if Oracle wanted to close it, they could. The fact that it isn't GPL is also what allows LibreOffice to benefit from the more permissive license, close the code up a little more (to the GPL) and not return anything back.
According to wikipedia OpenOffice.org was released under SISSL and LGPL, from Version 2 onwards under GPLv3. LibreOffice of course had to keep the GPL on the forked codebase and all newer contributions are licensed under LGPLv3 and MPL 2.0.
 
Compared to .NET I think the risk is slightly smaller but just imagine we are now in the year 2099 and Oracle has stopped any involvement with Java for the last 10-15 years. If you suggest Java to i.e your line manager, I can't imagine them being thrilled. There is no support, Java is too large for you to maintain yourselves. I think java will fizzle out slowly rather than being destroyed purposefully. Of course you can still fit a few projects in between now and then ;)
Java is open source, and as been for some time now. My current employer had already switched to Openjdk, so I didn't even have to advocate for a change.

Sun was the source of so much technical innovation. Unfortunately, the business side of the house was not stellar. Java is a perfect example. It was free so they couldn't sell it, but it was not open source, which limited its adoption. Fortunately they did the right thing before the Oracle acquisition and we all got to benefit from the hundreds of millions of dollars Sun probably spent on the JDK.

But yes, Java is already fizzling out, not because it's a bad platform, but just because it's showing its age. Threaded programming proved to be too complicated for most programmers, yet every Java object has its own mutex. Many crappy libraries have been layered on top of the Java threading primitives, and yet asynchronous programming is still winning the day. The monolithic JVM with its kitchen sink of obsolete technologies is creating some drag too.
 
But yes, Java is already fizzling out, not because it's a bad platform, but just because it's showing its age. Threaded programming proved to be too complicated for most programmers, yet every Java object has its own mutex. Many crappy libraries have been layered on top of the Java threading primitives, and yet asynchronous programming is still winning the day. The monolithic JVM with its kitchen sink of obsolete technologies is creating some drag too.
Yep pretty much. Especially the monolithic JVM part. I think that alone is going to make it very difficult to keep pulling along into newer and newer environments. Especially if things like Linux move around (i.e I don't think Javax.swing will be ported to Wayland for a while) and Windows moves into entirely locked-down UWP stuff. Porting JVM to C++/cx will be pretty horrid!

Java could well be a great example of just being open-source is not quite enough to keep lifespan going. Software needs to be simple and agile too.

(That said, I am fairly confident we won't need to worry. Perhaps our grand kids will have to migrate away from Java for us ;)
 
I was thinking of something like an Apache license, but with a clause that it can't be absorbed by more restrictive open-source licenses, but can be linked to them. GPL will likely reject this license, while it may be LGPL compatible. If this were to work, it would be ironic, because it would pivot LGPL dually under it.

Open source licenses have to be addressed separately from proprietary use which the above theory could work. Apache already in theory protects code from copyrighting, and I believe from patent trolling by companies wishing to close source or restrict.

If possible, a simplified license that covers relevent bases.


About Open Office's license as mentioned. Apache bought Open Office, and made it under the Apache license. The way it can get contributions, in spite of them being taken and not being given back by LibreOffice, is either another company finds a (financial) reason to get behind OpenOffice and contribute to it additionally under the Apache license. OpenOffice can get away from it by getting a license adjustment which makes it incompatible or unfavorable to GPL. CDDL was a good one that GPL didn't like.

all newer [Libre Office] contributions are licensed under LGPLv3 and MPL 2.0.
That's good. It would be nice if they can be convinced to release new code to be compatible so OpenOffice can absorb it, but perhaps this may be unlikely. Old LibreOffice parts obviously can't be changed.
 
I am looking at the differences between GPL and BSD - does it matter if the program language is GPL if you wanted to release a project as BSD license?
IMO (having been writing code and designing hardware for 50 years), it boils down to whether you want to OWN the thing (IP) or have other people USE it.

I strongly dislike the GPL and other restrictive (!) licenses because they limit what others can do with your code. Why would someone want to invest resources ($$$) to improve it -- if they had to let others benefit from that effort? My attitude is to use nothing that is encumbered and, in turn, not to encumber the code I release. If you can improve on my work, great!!!

If I have chosen to let others use my code, then I likely want them to use it and not tie their hands with constraints on how they go about using it. If I don't want them to use it, then I can simply not release the source and cover the binaries with restrictive licensing terms (and, even obfuscate it if I really want to thwart folks from trying to copy it).
 
I am looking at the differences between GPL and BSD - does it matter if the program language is GPL if you wanted to release a project as BSD license?
It is important not the GPL license of programming language (compiler) but its libraries. Usually, libraries have to be unrestricted i.e. no GPL there but you have to read the specific license of your compiler. See LLVM project - I think there is no GPL.
 
Java is open source, and as been for some time now. My current employer had already switched to Openjdk, so I didn't even have to advocate for a change.

Sun was the source of so much technical innovation. Unfortunately, the business side of the house was not stellar. Java is a perfect example. It was free so they couldn't sell it, but it was not open source, which limited its adoption. Fortunately they did the right thing before the Oracle acquisition and we all got to benefit from the hundreds of millions of dollars Sun probably spent on the JDK.

But yes, Java is already fizzling out, not because it's a bad platform, but just because it's showing its age. Threaded programming proved to be too complicated for most programmers, yet every Java object has its own mutex. Many crappy libraries have been layered on top of the Java threading primitives, and yet asynchronous programming is still winning the day. The monolithic JVM with its kitchen sink of obsolete technologies is creating some drag too.
I program in Scala which is a nice language on the JDK
 
BSD license it is for me!!! thank you all for a great discussion and helping me.
Just FYI: A little while ago, I made a thread about licensing: Thread licensing-rant-debate-thread.90051. It explores the different licenses, and encourages discussion about which license is appropriate under which circumstances and why.

It started out as a rant about some people trying to decide on a license first, before even having any code, working or not. I realize that you do have some code that's probably worth protecting with a license.

Most software licenses out there are little more than comments in source files, honor codes that are frankly a bit toothless when it comes to actual enforcement. The aim of my thread was to do a somewhat in-depth round-table discussion that educates the reader about the licenses out there and how they work.

HTH
 
Most software licenses out there are little more than comments in source files, honor codes that are frankly a bit toothless when it comes to actual enforcement.
Note that there are other IP protections that also are enforceable, even if you don't realize they apply to something you are using. Ask CompuServe about Unisys (who??).
 
I'd say a language can't come with a license. By language, I mean any "encoding concept" used to describe and communicate things... (Picture in my mind: imagine a newborn having to agree to license terms before being allowed to learn to speak ...)

Looking at programming languages, which are formal languages, there can (IMHO: should) be a formal specification. That's a piece of work subject to copyright, so there could be a license for its usage. It's implausible such a license could ever restrict what you're allowed to create yourself using the knowledge you obtained from reading this specification document. After all, it would be very hard to prove you didn't obtain that knowledge without even touching the spec, e.g. by just reading other things written in that language.

And then, of course, there are implementations (read: interpreters or compilers and corresponding runtimes/libraries) of programming languages. Their license could matter. Looking at the most well-known "restrictive free" license, the GPL, there's a clear definition of "derived work", which is exactly what this license restricts. According to that definition, "derived work" is (simplified!) anything that needs any parts of the original work "linked" (or directly bundled/embedded) at runtime. So, this won't affect a compiler. It also won't affect an interpreter, as long as this interpreter isn't itself "derived work" and some linked GPL code is made available to the interpreted code in some way. It certainly affects runtime components/libraries. Say your C program would explicitly link some libc.so implementation that's GPL (not LGPL), that would make your program derived work according to GPL. It would even be possible to create a more restrictive "free" license that would also declare something "derived work" as soon as the binary code was created by a compiler using that hypothetical license, but I don't know of any real-life example. In practice, open-source implementations of programming languages typically don't want to restrict what can be programmed using them. For example, GNUs toolchain uses the LGPL (which excepts "dynamic linking" from the rules for derived work) for fundamental runtime libraries, and there are even explicit exceptions for the bits of runtime that must be linked statically to any program compiled with a compiler of the GCC suite.
 
I'd say a language can't come with a license.
Intel copyrighted the opcodes in their assembly language. So, while you can still generate a binary image to execute on said processors, yo uwould have to create a NEW (but equivalent) LANGUAGE to do so.
 
Intel copyrighted the opcodes in their assembly language. So, while you can still generate a binary image to execute on said processors, yo uwould have to create a NEW (but equivalent) LANGUAGE to do so.
Or maybe you have to use Intel's assembler (translator)?
 
Post link to information for this copyright and what are the limitations? Sounds suspicious or like "we don't want ARM to use similar names" which is far away from "You (programmer) cannot write any program in assembler - it is only for Intel internal use".
 
"You (programmer) cannot write any program in assembler - it is only for internal use".
As I said, above,
while you can still generate a binary image to execute on said processors, yo uwould have to create a NEW (but equivalent) LANGUAGE to do so.

From the 8080/8085 Assembly Language Programming Manual:

Screenshot at 2022-10-15 11-47-54.png

Note that we ended up with Pentium (instead of "586") for similar reasons.
 
I'd say a language can't come with a license.
Ummm... Java is licensed by Oracle. Yes, the whole language. Yes, Oracle's attempts at license enforcement are met with resistance - I've been on practically the front row on the sidelines of that. Even big companies are looking at moving away from Java because of that licensing mess.
 
Imagine having to use The C Corporation's compiler!
Dunno, Borland C/C++ was around for awhile as an official tool of the workplace.

Note that we ended up with Pentium (instead of "586") for similar reasons.
who cares? as a consumer, I want my processor to work, and be reasonably powerful, and run FreeBSD... and Intel 10th Gen Core - it proved to be surprisingly slow for FreeBSD, according to some reports that I have seen on these Forums. Well, I guess this just means I'll buy something else to run FreeBSD, I suppose... duh.
 
who cares? as a consumer, I want my processor to work, and be reasonably powerful, and run FreeBSD...
Intel obviously wanted to protect it's "brand".

You can't buy a "Jeep like vehicle" without mentioning the word "Jeep" (the most valued automotive "brand")

Work in an IBM facility and casually mention you are going to make a Xerox of some document and you will likely be corrected: "No, you are going to make a PHOTOCOPY of a document" (because IBM made photocopiers and obviously didn't want them called "Xerox Machines").

Kleenex, Band-Aid, etc. You can buy a box of "face tissues" but they may not be "Kleenexs". Or, an "adhesive bandage" that is not a "Band-Aid". Jell-o?? Oh, you mean gelatin??
 
You can't buy a "Jeep like vehicle" without mentioning the word "Jeep" (the most valued automotive "brand")
Yeah, you can, just do your homework on the vehicle capacity and where it's available. No, the very name 'Jeep' won't be used in official brochures, but that doesn't mean that you can't have a very capable vehicle that rivals a Jeep. If you watch the news, Toyota is the preferred brand of UN peacekeeping forces in conflict zones where roads get bombed left and right. And yet, no, 'Toyota' is not exactly a brand name that one normally associates with a conflict zone...
 
Back
Top