This is Stallman-speak. The freedom to choose what one can do with their derivative work is more "fair/moral" than being coerced into sharing. Has the GPL ever even been successfully tried in court anyway? If the point of open source is “freedom”; there no free-er license than the BSD license. Developers write code; there's little incentive for open source when ones behavior is dictated IMO. WIth the GPL, you're trading liberty for the possibility or concern of preventing commercial exploitation.. not my cup of tea.

All else is just politics.
No, it's to preserve freedoms from Stallamn himself. Permissive means, let Stallamn have it. No matter how you want to argue for it, it does this. BSD gets eaten up by GPL. One cannot say they want freedoms, when it allows that to be given away. This a false equivalency, bc some of his terms are needed to preserve freedoms from him, while he goes into viralness. I'm only arguing for something that's a little more than Apache, and preserving rights for use, and to allow people to keep their own code under any license they choose, by linking.

GPL forces one to give up contributions. I'm arguing for allowing people to keep their contributions, which is opposed to GPL. I'm arguing for using a library or dependency with anything, and making it so their programs outside of that zone can't be forced up. They know the limits to the licenses extent, as it's clear unlike GPL which can get into anything.

My argument is against the GPL. GPL forces all to give up their works. I'm arguing for a license which you can keep your works under any license, so long as it's outside a directory. GPL's viralness is to eat it up like a virus, and forcing permissive code into it without restriction.

GPL= you used any of our code, It's mine.

Weak copy left= keep your code under your license. As long as it's outside of our authored code or directory.

MPL and CDDL have to be incompatible or jump through hoops for GPL.

ISC even switched from ISCL to MPL2, because they got tired of people using their works and not giving contributions back. MPL was the right balance for them, so users got to keep their own programs without being forced to give up their own works to them. They had to give back improvements to their own authored code, but that's good. It didn't force up other code not at all stewarded under ISC. That's a good balance of freedom.

It doesn't make sense to say something way better than GPL is bad, while arguing for something which allows GPL or worse to eat it up.

As long as there's a big enough organization to steward permissive code for big projects, it will work ok. There aren't many big projects. For smaller code bases and libraries for all use, permissive licenses work too. The license I'm for, preserves code without needing such a big organization, and it allows better preservation of that code as well, meant for circumstances. For wide use libraries, permissive may be best.
 
One cannot say they want freedoms, when it allows that to be given away.

Granting someone their own sovereignty is not giving a away freedom. This is the basis of the BSD license. The Apache license is ok, but there's a reason why the OpenBSD folks dislike it; and I don't blame them. This "giving away" freedom is only a concern when a business could potentially close off their work; but ignore the fact that a lot of individual or small team of developers are doing the same. I don't get it.

All I'm saying is that when you incorporate any form of "conditions" or "exceptions" into what constitutes open source licensing; you're defeating it's purpose. So if fork is closed off; so what. The original source is still open. Leave politics out of it.

Ok, I'm off my soap box now.
 
Typically, GPL programs tend to be graphical desktop programs.
Well, traditionally the the two biggest GPL'ed programs (before the Linux kernel) were gcc and emacs. I just looked, and both are today licensed under GPLv3 (or later). And to be clear: There are many emacs implementations; the thing everyone calls "emacs" today is one particular flavor, namely GNU-emacs, written and maintained mostly by RMS (in the last few decades with lots of help from others).

This leads to the following old joke from the 1980s (when I was doing commercial computing in COBOL and RPG-II), about the Unix style: A business owner hires a programmer to implement "accounts receivable" for him. The programmer says that this is a project, which will take more than 2 years to finish. After the 2 years are up, the business contacts the programmer to see where we are on the schedule, and he has spent the first year implementing a new editor, and is right now writing the "great american compiler"; once that is done, he'll start accounts receivable. Any resemblance with the GNU and Hurd projects is purely coincidental.

And for people not from this culture: Look up what "great american novel" means: The thing every writer wants to create, few actually try, and nobody succeeds.
 
This leads to the following old joke from the 1980s (when I was doing commercial computing in COBOL and RPG-II), about the Unix style: A business owner hires a programmer to implement "accounts receivable" for him. The programmer says that this is a project, which will take more than 2 years to finish. After the 2 years are up, the business contacts the programmer to see where we are on the schedule, and he has spent the first year implementing a new editor, and is right now writing the "great american compiler"; once that is done, he'll start accounts receivable.
Yeah, and this unique implementation of 'Accounts Receivable' is the stuff that people will try to protect with licenses, and make money on. Why exactly?

I had no idea the joke was THAT old - I still see it being perfectly applicable today...

It seems like everybody wants to be the next Torvalds/Percival/Hubbard/RMS/Gates, and have the ultimate defense against trolls who dare to defy every user's sovereignty on every friggin' device. 👿
 
I'm a bit surprised that nobody mentioned the GNU Affero license in here... It seems to be 'Cloud' version of GPLv3... and discussed a bit in the following thread: Thread freebsd-disagrees-with-the-fsf.71933. kpedersen offers an interesting take there.
Gotta correct myself: It looks like sidetone did mention it earlier - in post #25 of this thread. There was also some debate about applicability of the license in another thread on these Forums: Thread when-is-db5-not-going-to-included.86106. I have to admit, I did not connect the dots between the terms AGPL and Affero until now.

Just looking for the term affero using the Forums' search feature yielded surprisingly few hits. Using agpl, OTOH, yielded a LOT of hits, most of which had very little discussion of the actual license.

An example of what software in Ports is licensed with that: devel/RStudio.

The Wikipedia article I linked to mentions that the Affero license was actually banned by both Debian and Fedora projects:
It was banned by both Debian and the Fedora Project, who state that the license's intent is to discriminate against cloud computing providers offering services based on the software without purchasing its commercial license.

FreeBSD did specifically take a stance against metin2, another example of software that is targeted by the Affero license. In case of metin2, it was a matter of banning a specific package, rather than a license. And, metin2 is definitely NOT Affero-licensed - it merely has a design that makes the Affero license an appropriate and attractive option.
 
did mention it earlier - in post #25 of this thread
If we are keeping score, I mentioned it even earlier in this thread :p

It is an interesting license, I think the Debian project has gotten confused here somewhere along the line. Possibly the decision committee meeting was too busy and noisy just before lunch. It really isn't discrimination against cloud providers because they are *very* welcome to use AGPL code if they comply and open up their source, just like everyone else.

An admittedly obnoxious example is, yes, jails and the rest of the legal system discriminate against murderers but they could also... y'know, not murder people, just like everyone else.
 
If we are keeping score, I mentioned it even earlier in this thread :p

It is an interesting license, I think the Debian project has gotten confused here somewhere along the line. Possibly the decision committee meeting was too busy and noisy just before lunch. It really isn't discrimination against cloud providers because they are *very* welcome to use AGPL code if they comply and open up their source, just like everyone else.

An admittedly obnoxious example is, yes, jails and the rest of the legal system discriminate against murderers but they could also... y'know, not murder people, just like everyone else.
I just checked: your post is #48... 😅
 
AGPL is a more restrictive GPL. Which GPL is already viral. I consider it in the GPL ecosphere, even if it's more restrictive than what some of them would like as well.

I would want a license which has a clause that prevents restrictions for dynamic linking. This would be regardless if that removes it from being considered Open Source approved, but it should be, because GPL adds restrictions of its own. That would be good enough. Imagine if a program could be used as a library, allowing that freedom of use there to persist.

I was thinking of an Apache compatible license, calling it Athabaskan (for the language group), which is directory-wide, and within this, Apache licensed files must be labeled as such. It would allow all versions of Apache licensed code, all labeled by their files. Additions must go into the directory outside of those files, and the license applies to that. This would be one such license, which replaces GPL for Apache code to be absorbed into, while also retaining Apache's license as required. Keeping the Apache licensed code as their own files within this other license would make it simpler to distinguish Apache licensed code from the rest within this license. Then, the author must list the directories which apply to this license, or how far it reaches, however, this license cannot restrict using it as a library to to use another library.

There's not an alternative license at this time, which preserves uses for dynamic and static linking indefinitely throughout iterations.

Then, I would make another license which also restricts prevention of dynamic linking, thus preventing it from being absorbed into GPL, which doesn't absorb Apache code. It would have a slightly better patent clause. Then, these opensource non-viral licenses could be used side by side. Eventually GPL needs to be replaced, or they need to update each major version, to allow specific dynamic linking so that GPL can use any LGPL version. GPL will be forced to change to allow dynamic linking between libraries, if enough software comes under a competitive ecosystem of better licenses. With this license incompatibility within its sphere, I realized that it's as if GPL has the similar effect of patent trolling itself.

As long as viralness of a license especially GPL forces its way into libraries, there will need to be compatibility layers between these licenses and less viral licenses, whether through interpreters or API layers.

Also, hardware drivers will need a license better than GPL, which the license doesn't extend past the specific hardware pieces it's used for. These should be prevented from being incorporated into any GPL. In the meantime, there needs to be an interpreter or API layer to run GPL licensed drivers with other code, even which which allows it, to prevent the viralness from extending to other parts of other drivers and into the base system.
 
As far as I know, that's not FreeBSD (the project or the OS) taking a stance, it only applies to this discussion forum.

And the reason for this is clearly explained: Most people running Metin is committing a crime, and the people who own/run/control (or some combination thereof) this forum don't want to be involved in that crime. It's not that Metin itself is banned, it is asking questions about how to run it: those people who have legitimate (licensed) copies of Metin will know how to do it, and most everyone asking about it is running an illegal (unlicensed) copy.
 
The Wikipedia article I linked to mentions that the Affero license was actually banned by both Debian and Fedora projects:
I think that's incorrect. Debian/RedHat etc. have banned the SSPL, the server-side license.

In a nutshell (and probably slightly over-simplified), here is what the licenses say:
  • GPL: If you modify this software, AND ship a product that is based on the modified software to anyone, in particular to a customer, you have to give that person the source code of your modification. The "product" can be as simple as a compiled version of the modified software.
  • Contrariwise, if you modify GPL software, and only used the modified version yourself (not shipping a compiled version or a product), you do NOT have to release your modifications.
  • AGPL: If you modify the software, do not ship a product or compiled version, but allow others to get use out of it over the network (in particular as an ASP or cloud provider), then you also have to give the users the source to your modifications. The intent of the AGPL was to close the "ASP loophole", where someone modifies a piece of GPL code (such as emacs or gcc), and never ships the modified or compiled version, but allows customers to use it as a service.
  • SSPL: If you modify this software, and allow someone to use it over the network (cloud, ASP, and so on), then you need to give that person the source code for any bit of software that will be required to run the modified software the same way you have.
I can take an extremist view of the SSPL: If you have written a manual that explain how to bolt servers into a rack and how to connect power and network cables to them, that manual is a piece of software. If you then run ANY SSPL'ed software in your company, you have to release that manual to the public (= all users of your service). It fundamentally means ANY AND ALL software that you develop and use becomes automatically public. Matter-of-fact, if the manual is not a hardware install manual, but the instructions to finance about "how to negotiate with companies that provide power and cooling to our data centers", and the resulting contracts, those are also under the scope of the SSPL if applied liberally. Because in order to run the software in the same fashion as a big cloud provider runs it, users have to be able to perform the same power/water/... negotiations.

Obviously, this means that Google, Microsoft, Amazon, Baidu, Oracle, IBM, and all other cloud providers would cease to exist, because they can have absolutely no secrets about their production setup. Trade secrets and copyrights and patents would all cease to exist for these companies. Obviously, this is either insane, or the greatest revolutionary act tine the luddites tried to destroy all weaving looms. Whether this is a good or a bad thing depends on one's viewpoint.
 
The Wikipedia article I linked to mentions that the Affero license was actually banned by both Debian and Fedora projects:
I think that's incorrect. Debian/RedHat etc. have banned the SSPL, the server-side license.
Very well could be that I misunderstood something while reading. And that's what this thread is for: Pointing out what's a fact, what's a misunderstanding of a given license's terms.
 
It is important for companies producing software and making money from it, companies using this software and making money from it, and it is also important for the judge who also makes money from it. To sum up, in the final settlement the taxpayer will pay anyway.
 
Obviously, this means that Google, Microsoft, Amazon, Baidu, Oracle, IBM, and all other cloud providers would cease to exist, because they can have absolutely no secrets about their production setup. Trade secrets and copyrights and patents would all cease to exist for these companies. Obviously, this is either insane, or the greatest revolutionary act tine the luddites tried to destroy all weaving looms. Whether this is a good or a bad thing depends on one's viewpoint.
It's at minimum dual licensed. One license is their proprietary ownership, and the other is the GPL or AGPL rights for others.

It's like how when an MIT licensed, BSD licensed or Public Domain piece of code calls under GPL, The MIT or BSD licensed code stays under that license, and those original parts are unaffected by the GPL. The GPL applies to their snapshot with their additions. If the changes are insignificant and minimal, it's not enough to distinguish from the permissively licensed software, and you could use that.

When lots of companies author GPL/AGPL code, used together with other GPL/AGPL code, they keep their privileged rights over their authored code, so there's that balance of control by different software used together. Now my question is about, if contributions to a specific piece of software are given up to their proprietary ownership as well, aside from that it's obviously given up to the GPL/AGPL.

With APL2.0, each piece of code can belong to an author line by line or by file. If someone contributes to those lines, that goes to that main author's proprietary code, as well as to under the APL2.0. If those lines are marked as outside of APL2.0, they can stay outside of APL2.0 and their proprietary code.
 
It's at minimum dual licensed. One license is their proprietary ownership, and the other is the GPL or AGPL rights for others.
I've always thought "dual licensed" was a mess. Someone can choose to contribute code under only one of the licenses which quickly devolves to a single licensed fork.
 
I've always thought "dual licensed" was a mess. Someone can choose to contribute code under only one of the licenses which quickly devolves to a single licensed fork.
As long as any licensed fork is available including through archive, those other variants are saved under those licenses. GPL preserves its code better, because any iteration and fork has that license, and parts can be recreated to use that license if any part becomes lost. BSD code becomes lost if it's lost, and the GPL fork remains. BSD code recreated would have to go around that GPL licensed code.

I think of each fork as a snapshot with the licensed additions around it. So a BSD piece of code would be a snapshot. Then, an exact copy turned into GPL would be a snapshot. The additions around all of those licenses would be snapshots, all with those applicable licenses. It's like a breadboard and wires which are public domain. GPL can't claim the breadboard and wires exclusively.

I like that Apache licenses keep their terms better than other permissive licenses, regardless of whether GPL absorbs it or when it's used in proprietary ecosystems. The code which is not under Apache licenses must be marked. When a software says APL2.0, all within it is expected to be APL2.0, as otherwise it would be incorrectly marked. Similarly with BSD licensed code, except anyone could throw additions into it meant to not be included in the permissive license without marking it.

It would be far simpler to make a license like APL2.0, which made all additions within the files have to be included in the license, and any additions chosen not to be included in this license must be kept outside of the file, regardless if this removes this license from the category of permissive status. The permissive treatment in principle by use of this wouldn't be lost. Let's say a GPL like license could absorb that code, you could simply pull that code by entirety of the file back out of the viral license at any time, and use it under the original file-based license, because it was preserved by that license in entirety by each file from the beginning. Same for APL2.0 being absorbed by GPL3, except it's per marked line, instead of by simply the whole file.
 
Published yesterday:

Bruce Perens proposes draft Post-Open Zero Cost License • The Register

— Thomas Claburn​

There's no such thing as a free lunch.

The very idea of Open Source came about because RMS was pissed that an MIT colleague would not share source code for a printer driver. The way I'm reading this, 'Post-Open' part means that we're probably past the point where having source code publicly available makes that much difference - it does take a well-trained expert to even be able to read the source code, much less understand it and contribute a meaningful patch that is likely to be accepted.

Open or closed, it doesn't matter on some accounts. It's debatable. Even though Linux and BSD's make their sources available to the public, there's not that many people willing or even able to read through the code and understand it well enough to even know what it takes (try to open up a text editor, make a change, and recompile the whole kernel with that change). Case in point, we still see the 'pkg vs ports' debates on these Forums all the time. Not that many people even know what 'compiling' is (and don't want to touch it), even though 'compiling' is a central idea of Open Source vs. closed source. (Well, most people reading this thread would know, though).

Yeah, it's a just draft by Bruce Perens at this point, but I personally don't see THAT license coming to fruition if the premise is 'zero cost'.

Somebody, somewhere, does pay. FreeBSD may be free to download, as in there's no fee being charged to people downloading and using the OS. But there's still costs for hosting that download, costs for writing the OS in the first place, and costs for even knowing WTF it's all about. And the hardware that FreeBSD runs on is definitely NOT free. Somebody, somewhere, paid to produce it and sell it.

Also, the draft points to a 'zero-contract' page that is supposed to explain the concept. FWIW, paid-contract (which is supposed to be a contrast) is a non-existent page, too.

One can argue that only your thoughts are really 'free' - but then how come thinking is hard work that takes up time and quite a few calories? 😏
 
Back
Top