Immediately change to permissive license

[gisborne]

Just watching the second interview on TWIT.

I'm not a lawyer, but I pay attention enough to make sensible decisions.

As I understand it, while Aquameta is under GPL3, any contributions are under GPL3. This means that if you have any external contributions, in order to switch to a permissive license (I do like the sound of the one they called out), you will need all the contributors to agree to the change of license. Obviously, the longer you wait to switch licenses, the worse this problem will be.

[erichanson]

Yes. As far as I know we haven't had any significant contributions by anybody who didn't work for me. I'll switch it in the next release. Just doing a bit of research on which one to use. They suggested BSD Plus Patent.

[gisborne]

I read something I can’t find right now; it was from someone like gnu or EFF, where they discussed the best copy-left and copy-right licenses, and decided that if you wanted something liberal, Apache 2.0 is the best, but it wasn’t much between that and MIT. I did like the sound of what the guy on TWIT referenced, though.

I am working on something closely related to Aquameta (I’m doing to REST endpoints what you are doing to code: I am building software out of (mostly) static, (mostly) purely functional REST endpoints. Everything is addressable and serializable — data. Functions implemented in the same namespace convert transparently to function calls. So anything can be stored and retrieved from anywhere that can store and retrieve a string. You can have, just to take one example, a table of functions.

Much of the design is around radical use of relations: letting you fill things in and get that thing, or leave required-but-enumerable options out and get a relation over similar things. And functions-as-data in the middle of this is fucking crazy.

There’s a lot more to it — important state is in a write-only store, supporting branching and history and such. Every endpoint will automatically come with a set of UIs for different purposes, which are associated with its types. Functions are available to do all the things. Everything has a UI, so for instance a non-ground function presents itself as a form. As much as possible of the logic is declarative. There will be triggers (my most open question atm).

I am intensely interested in Aquameta, but this will be casually, and from the outside, until you change the license. I believe we are developing different forms of the same vision.

On May 3, 2019, at 18:54 , Eric Hanson notifications@github.com wrote:

Yes. As far as I know we haven't had any significant contributions by anybody who didn't work for me. I'll switch it in the next release. Just doing a bit of research on which one to use. They suggested BSD Plus Patent https://opensource.org/licenses/BSDplusPatent.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aquametalabs/aquameta/issues/183#issuecomment-489284533, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG7X7TC74ASLZF446RQG3PTTUFVANCNFSM4HKXTPKA.

[erichanson]

Interesting.... I kind of get it. Are you doing this work as open source? Is there something I can take a look at?

[gisborne]

On May 5, 2019, at 12:38 , Eric Hanson notifications@github.com wrote:

Interesting.... I kind of get it. Are you doing this work as open source? Is there something I can take a look at?

I’m on about my fifth rewrite; I’m all on my own and this is a big darn elephant. Soon.

It’s being written in Dart, FWIW.

[geraldew]

A pre p.s. - I've tried to keep this short so apologies if I haven't done that well enough.

While I agree with Guyren Howe - that if you want to change the license from GPL to something else then you would need to do so before getting lots of outside contributions - I have to say that I'm not yet seeing a good enough reason for you to move from the GPL.

In the end, a license choice will be one of two things: irrelevant or significant - and it is only in retrospect that the importance of the issue, or the wisdom of either choice becomes especially clear. I know that doesn't help much, when the time to choose is always now.

Clearly, the single largest distinction is between "copyleft" and "permissive" licenses.

In my opinion, how crucial it is depends on whether the particular project needs to have enhancements merged back more than it needs a wider adoption by being friendly to those with an aversion to copyleft.

This was clearly true for the Linux kernel. Torvalds has been quite clear about this - the stock quote in this regard is:

What made the difference was the license. "FSF [Free Software Foundation] and I don't have a loving relationship, but I love GPL v2," said Torvalds. "I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint."

On the other hand, there have definitely been projects that in order to "work" and succeed have historically needed wide adoption and in order to get that, have needed to avoid copyleft. (I really should quote some examples here but don't have any to hand. There have certainly been episodes of FLOSS Weekly where such a decision has seemed quite valid.)

(And of course, there are lots of license variations and many paths a software project may need to follow. I'm picking two spectrum endpoints here because that's what this discussion is already using.)

The question therefore, is what kind of project Aquameta is really and which will suit it better.

This is where I would suggest answering that question first and letting the answer be the guide to a choice of license.

I do have a personal license preference because I don't like seeing organisations take a public code base and make secret enhancements to it that then compete with the original project. But when they do so because that a permissive license was set then clearly that is within the rights provided by such a license - then it is meaningless to quibble.

In a pragmatic sense there can be a difference between what I might advise in my private capacity than when I'm acting as an employee. Thus the private me would advise the copyleft option so that the employee me doesn't get the option to make closed enhancements and redistribute them.

Bearing in mind that the GPL only applies when software is distributed, so all users are free to make their own private changes in their internal operation.

The irony here is that to make the "right" choice about a license, you need to imagine all and any significant approaches that recipients are likely to take and work out which you're comfortable with. It's not so much about what you the creator think as what all the others may or will think.

It's a curious reality that for many projects the distinction never matters - because most users and developers do give back to a project regardless of whether the license compels them to. It is precisely because it usually doesn't matter that I don't see any problem with copyleft licenses - they merely protect against the few exceptions to good Open Source cooperation.

That's probably true for much of the project work done with the Apache license, but I can vouch from experience that it is frustrating using a product that is 95% Apache licensed with an additional 5% of proprietary black box variation of the Open Source version. As soon as the box is black then it is a matter of trusting the vendor not the code.

Yes, there are still organisations who won't touch copylefted software at all, but by 2019 I don't see those as much different to those still grappling with the basic concepts of software freedom (and there are still plenty of those too). The ones who will be good partners of an Open Source project will "get it" in their own time eventually.

p.s. just to be clear there are details I'm deliberately skipping over there - e.g. Torvalds gives reasons for keeping the Linux kernel at GPL2 not GPL3, also for copylefting server-end services, where software is used remotely rather than distributed there is the Affero GPL. And .. then there's patents, which is even trickier territory than copyright as laws for them vary so much around the world.

[gisborne]

I generally prefer a permissive license (it has served eg Postgres very well).

I think it’s particularly important here, though, because any software devloped “on top of” aquameta in any reasonably sense is going to require writing functions in Postgres. There is no principled way to separate “on top of” projects from extensions, forks or improvements that are the intended target of GPL, so I would have to GPL license any such code.

I would like to be able to take Aquameta and develop a business product around it, but I’m unlikely to do that if I have to GPL license my product. I think it is in Aquameta’s interests to allow me to develop such a product.

Perhaps I’m wrong about something here; I’m no lawyer. But even if I’m wrong, others will reason as I have and decide not to use Aquameta.

There is little to lose and much to gain by using a permissive license.

Thanks. On May 12, 2019, 07:07 -0700, geraldew notifications@github.com, wrote:

A pre p.s. - I've tried to keep this short so apologies if I haven't done that well enough. While I agree with Guyren Howe - that if you want to change the license from GPL to something else then you would need to do so before getting lots of outside contributions - I have to say that I'm not yet seeing a good enough reason for you to move from the GPL. In the end, a license choice will be one of two things: irrelevant or significant - and it is only in retrospect that the importance of the issue, or the wisdom of either choice becomes especially clear. I know that doesn't help much, when the time to choose is always now. Clearly, the single largest distinction is between "copyleft" and "permissive" licenses. In my opinion, how crucial it is depends on whether the particular project needs to have enhancements merged back more than it needs a wider adoption by being friendly to those with an aversion to copyleft. This was clearly true for the Linux kernel. Torvalds has been quite clear about this - the stock quote in this regard is: What made the difference was the license. "FSF [Free Software Foundation] and I don't have a loving relationship, but I love GPL v2," said Torvalds. "I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint." On the other hand, there have definitely been projects that in order to "work" and succeed have historically needed wide adoption and in order to get that, have needed to avoid copyleft. (I really should quote some examples here but don't have any to hand. There have certainly been episodes of FLOSS Weekly where such a decision has seemed quite valid.) (And of course, there are lots of license variations and many paths a software project may need to follow. I'm picking two spectrum endpoints here because that's what this discussion is already using.) The question therefore, is what kind of project Aquameta is really and which will suit it better. This is where I would suggest answering that question first and letting the answer be the guide to a choice of license. I do have a personal license preference because I don't like seeing organisations take a public code base and make secret enhancements to it that then compete with the original project. But when they do so because that a permissive license was set then clearly that is within the rights provided by such a license - then it is meaningless to quibble. In a pragmatic sense there can be a difference between what I might advise in my private capacity than when I'm acting as an employee. Thus the private me would advise the copyleft option so that the employee me doesn't get the option to make closed enhancements and redistribute them. Bearing in mind that the GPL only applies when software is distributed, so all users are free to make their own private changes in their internal operation. The irony here is that to make the "right" choice about a license, you need to imagine all and any significant approaches that recipients are likely to take and work out which you're comfortable with. It's not so much about what you the creator think as what all the others may or will think. It's a curious reality that for many projects the distinction never matters - because most users and developers do give back to a project regardless of whether the license compels them to. It is precisely because it usually doesn't matter that I don't see any problem with copyleft licenses - they merely protect against the few exceptions to good Open Source cooperation. That's probably true for much of the project work done with the Apache license, but I can vouch from experience that it is frustrating using a product that is 95% Apache licensed with an additional 5% of proprietary black box variation of the Open Source version. As soon as the box is black then it is a matter of trusting the vendor not the code. Yes, there are still organisations who won't touch copylefted software at all, but by 2019 I don't see those as much different to those still grappling with the basic concepts of software freedom (and there are still plenty of those too). The ones who will be good partners of an Open Source project will "get it" in their own time eventually. p.s. just to be clear there are details I'm deliberately skipping over there - e.g. Torvalds gives reasons for keeping the Linux kernel at GPL2 not GPL3, also for copylefting server-end services, where software is used remotely rather than distributed there is the Affero GPL. And .. then there's patents, which is even trickier territory than copyright as laws for them vary so much around the world. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[geraldew]

You've brought up the issue there of derivative works, which is relevant with Aquameta having a GPL license.

Granted, the boundary between merely using an Open Source product versus extending/deriving it can sometimes be tricky. Sometime it's clear, sometimes not. I'd have to research the PostgreSQL license to give a clearer opinion on anything directly related to it.

Licenses are pieces of language and "on top of" is not wording that seems clear to me - or at least not as such in Open Source licenses.

For the example you give, if we see say we three things in play: PostgreSQL as a piece, functions written in PostgreSQL as a piece, and Aquameta as a piece - which piece is "on top of" the other. Are the functions added to PostgreSQL and then merely used by Aquameta, just as it uses PostgreSQL without causing a license clash?

I'll readily admit that I don't know either PostgreSQL nor Aquameta well enough to answer this. License interaction confusion is often problematic and this may be a strong enough reason to have Aquameta align its license with that of PostgreSQL.

If we leave that aspect aside for the moment, I'm still having trouble seeing how the GPL would inhibit you from using Aquameta as part of solutions that you would supply to others.

It seems what you are saying when you want to make a "business product" is that you wish to not supply the source along with it. Of course, where licenses allow you to do it then that is within your right to choose.

However you're not giving us your reasons for wishing that.

So I'll try some guesses at your thinking. The purpose of the exercise being to clarify the likely approaches of possible Aquameta users.

Perhaps you just don't like the paperwork, the bureaucracy of passing on references to source code.

Perhaps you have a wish to make innovations that you will not share, either to your customers or to anyone else. That's a valid intention - it's called proprietary software - and is the default imposed by copyright law that Open Source license exist to provide an alternative to.

Perhaps you want to use the old old software development pattern as a way to ensure that your customers had no option but to come to you for fixes and alterations. If so, it was precisely that kind of lock-in that software freedom was invented to avoid.

I'm clearly guessing here. You're under no obligation to give your reasons, although I assume we're both here to help Aquameta in it license thinking.

By the way I'd note that if you're supplying customers with Linux in setups then you already have an obligation to pass on the accessibility of the source for that. It's been a while since I've heard of that significantly impeding commercial vendors from supplying solutions to their customers. I see PostgreSQL is supported on FreeBSD, so perhaps you use that which would make this point moot - for you at least.

Re the GPL, let me clarify that it only requires that you provide the source when you distribute the software - i.e. to your customer or client. You are not obligated to supply your changes back to the original project. Of course, there's nothing stopping your customers from then doing so, from the source you supplied them.

Quite apart from what the GPL requires, a major change has occurred among developers, with many/most now seeing their process primarily in terms of committing their changes back to the main project. There's some irony that widespread use of Open Source has led to new norms of behaviour that are not themselves required by the licenses. This has brought some new kinds of confusions while at the same time some of the old myths linger on.

[gisborne]

Let’s say I want to develop an account package to sell, using Aquameta.

If you are not a FSF purist, I should be able to do that. I don’t wish to change or make improvements to Aquameta; I want to develop a proprietary product that uses Aquameta for its database, UI etc services.

As I understand Aquameta, the way I would do this wold be to add functions to the Postgres database where Aquameta is running.

As I understand the GPL, any such functions are effectively part of Aquameta (there is no in-principle way to distinguish them, and I don’t think the GPL has any language that tries). So I would be forced to GPL-license my product.

Ergo, I can’t develop a proprietary product using Aquameta.

You may be a Free Software purist, a position I respect but don’t share. I think I should be able to develop proprietary applications.

Furthermore, I think it is in the interest of Aquameta to permit this. Many more folks would use Aquameta in that case, and such folks would grow the community and likely some of them would contribute to Aquameta, documentation etc.

On May 13, 2019, at 7:59 , geraldew notifications@github.com wrote:

You've brought up the issue there of derivative works, which is relevant with Aquameta having a GPL license.

Granted, the boundary between merely using an Open Source product versus extending/deriving it can sometimes be tricky. Sometime it's clear, sometimes not. I'd have to research the PostgreSQL license to give a clearer opinion on anything directly related to it.

Licenses are pieces of language and "on top of" is not wording that seems clear to me - or at least not as such in Open Source licenses.

For the example you give, if we see say we three things in play: PostgreSQL as a piece, functions written in PostgreSQL as a piece, and Aquameta as a piece - which piece is "on top of" the other. Are the functions added to PostgreSQL and then merely used by Aquameta, just as it uses PostgreSQL without causing a license clash?

I'll readily admit that I don't know either PostgreSQL nor Aquameta well enough to answer this. License interaction confusion is often problematic and this may be a strong enough reason to have Aquameta align its license with that of PostgreSQL.

If we leave that aspect aside for the moment, I'm still having trouble seeing how the GPL would inhibit you from using Aquameta as part of solutions that you would supply to others.

It seems what you are saying when you want to make a "business product" is that you wish to not supply the source along with it. Of course, where licenses allow you to do it then that is within your right to choose.

However you're not giving us your reasons for wishing that.

So I'll try some guesses at your thinking. The purpose of the exercise being to clarify the likely approaches of possible Aquameta users.

Perhaps you just don't like the paperwork, the bureaucracy of passing on references to source code.

Perhaps you have a wish to make innovations that you will not share, either to your customers or to anyone else. That's a valid intention - it's called proprietary software - and is the default imposed by copyright law that Open Source license exist to provide an alternative to.

Perhaps you want to use the old old software development pattern as a way to ensure that your customers had no option but to come to you for fixes and alterations. If so, it was precisely that kind of lock-in that software freedom was invented to avoid.

I'm clearly guessing here. You're under no obligation to give your reasons, although I assume we're both here to help Aquameta in it license thinking.

By the way I'd note that if you're supplying customers with Linux in setups then you already have an obligation to pass on the accessibility of the source for that. It's been a while since I've heard of that significantly impeding commercial vendors from supplying solutions to their customers. I see PostgreSQL is supported on FreeBSD, so perhaps you use that which would make this point moot - for you at least.

Re the GPL, let me clarify that it only requires that you provide the source when you distribute the software - i.e. to your customer or client. You are not obligated to supply your changes back to the original project. Of course, there's nothing stopping your customers from then doing so, from the source you supplied them.

Quite apart from what the GPL requires, a major change has occurred among developers, with many/most now seeing their process primarily in terms of committing their changes back to the main project. There's some irony that widespread use of Open Source has led to new norms of behaviour that are not themselves required by the licenses. This has brought some new kinds of confusions while at the same time some of the old myths linger on.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aquametalabs/aquameta/issues/183?email_source=notifications&email_token=AAAG7X2SF3OU3DFSQJQH7HTPVF66NA5CNFSM4HKXTPKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVISWPQ#issuecomment-491858750, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG7X25DB35EAU4WVHRRQ3PVF66NANCNFSM4HKXTPKA.

[gisborne]

Let’s say I want to develop an account package to sell, using Aquameta.

If you are not a FSF purist, I should be able to do that. I don’t wish to change or make improvements to Aquameta; I want to develop a proprietary product that uses Aquameta for its database, UI etc services.

As I understand Aquameta, the way I would do this wold be to add functions to the Postgres database where Aquameta is running.

As I understand the GPL, any such functions are effectively part of Aquameta (there is no in-principle way to distinguish them, and I don’t think the GPL has any language that tries). So I would be forced to GPL-license my product.

Ergo, I can’t develop a proprietary product using Aquameta.

You may be a Free Software purist, a position I respect but don’t share. I think I should be able to develop proprietary applications.

Furthermore, I think it is in the interest of Aquameta to permit this. Many more folks would use Aquameta in that case, and such folks would grow the community and likely some of them would contribute to Aquameta, documentation etc.

On May 13, 2019, at 7:59 , geraldew <notifications@github.com mailto:notifications@github.com> wrote:

You've brought up the issue there of derivative works, which is relevant with Aquameta having a GPL license.

Granted, the boundary between merely using an Open Source product versus extending/deriving it can sometimes be tricky. Sometime it's clear, sometimes not. I'd have to research the PostgreSQL license to give a clearer opinion on anything directly related to it.

Licenses are pieces of language and "on top of" is not wording that seems clear to me - or at least not as such in Open Source licenses.

For the example you give, if we see say we three things in play: PostgreSQL as a piece, functions written in PostgreSQL as a piece, and Aquameta as a piece - which piece is "on top of" the other. Are the functions added to PostgreSQL and then merely used by Aquameta, just as it uses PostgreSQL without causing a license clash?

I'll readily admit that I don't know either PostgreSQL nor Aquameta well enough to answer this. License interaction confusion is often problematic and this may be a strong enough reason to have Aquameta align its license with that of PostgreSQL.

If we leave that aspect aside for the moment, I'm still having trouble seeing how the GPL would inhibit you from using Aquameta as part of solutions that you would supply to others.

It seems what you are saying when you want to make a "business product" is that you wish to not supply the source along with it. Of course, where licenses allow you to do it then that is within your right to choose.

However you're not giving us your reasons for wishing that.

So I'll try some guesses at your thinking. The purpose of the exercise being to clarify the likely approaches of possible Aquameta users.

Perhaps you just don't like the paperwork, the bureaucracy of passing on references to source code.

Perhaps you have a wish to make innovations that you will not share, either to your customers or to anyone else. That's a valid intention - it's called proprietary software - and is the default imposed by copyright law that Open Source license exist to provide an alternative to.

Perhaps you want to use the old old software development pattern as a way to ensure that your customers had no option but to come to you for fixes and alterations. If so, it was precisely that kind of lock-in that software freedom was invented to avoid.

I'm clearly guessing here. You're under no obligation to give your reasons, although I assume we're both here to help Aquameta in it license thinking.

By the way I'd note that if you're supplying customers with Linux in setups then you already have an obligation to pass on the accessibility of the source for that. It's been a while since I've heard of that significantly impeding commercial vendors from supplying solutions to their customers. I see PostgreSQL is supported on FreeBSD, so perhaps you use that which would make this point moot - for you at least.

Re the GPL, let me clarify that it only requires that you provide the source when you distribute the software - i.e. to your customer or client. You are not obligated to supply your changes back to the original project. Of course, there's nothing stopping your customers from then doing so, from the source you supplied them.

Quite apart from what the GPL requires, a major change has occurred among developers, with many/most now seeing their process primarily in terms of committing their changes back to the main project. There's some irony that widespread use of Open Source has led to new norms of behaviour that are not themselves required by the licenses. This has brought some new kinds of confusions while at the same time some of the old myths linger on.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aquametalabs/aquameta/issues/183?email_source=notifications&email_token=AAAG7X2SF3OU3DFSQJQH7HTPVF66NA5CNFSM4HKXTPKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVISWPQ#issuecomment-491858750, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG7X25DB35EAU4WVHRRQ3PVF66NANCNFSM4HKXTPKA.

[erichanson]

I am still giving this some thought. Being as transparent as possible, here's a few of the angles rattling around in my head:

Avoiding fragmentation is one big motivator. Long term, I would like Aquameta to be a big distributed p2p network. If we had tons of conflicting versions of Aquameta out there, this might really create a mess. Much like Linus's reasoning around Linux.

Another reason for choosing the GPL initially (though I wish I would have gone with GPL2) is that I'm not entirely comfortable with someone forking the project and running with a commercial version. Financially, I am not doing well right now. I have hopes to make this my day job, and hire others to help me continue to develop and support the project, but until I do it feels a little inequitable doing the ground work for other people's commercial ventures, and not even getting their contributions to the project back. Remember, this isn't some collaboration of developers across the open source community. It isn't a grant-funded project or an academic research project. It's just me, self-funded, and I've put a ton of money into this project. Right now I don't have the resources to do a good job of managing a project of this scope, and there are many aspects of it that other people are much more talented at than I. I need help. I think given the project's arc to date, it is not a big ask to allow others to use the code for a commercial venture, as long as they give their contributions back to the project.

The intention here is that third-party bundles are already able to pick their own license as long as they're not doing "core" stuff -- which is admittedly a bit ambiguous. Given the oddity of Aquameta's architecture, it's not entirely clear to me whether or not the language of the GPL really accomplishes this.

The long-term business plan is to start a three-tier company of a) core developers, b) consultants and contract programmers, and c) a code school. Top candidates from the code school could be hired to work as platform users to do contract work and develop applications and products, and then core developers are there to support the "user-level" developers within the company. Then at the center of it all is the bundle hub and data marketplace, where third parties can develop and distribute or sell their own bundles under whatever license they want.

My hope is to get some traction around 0.2 release (which unfortunately I've had to back-burner for a couple of weeks due to other obligations, namely making enough money to survive) and once we have an amount of users and traction to get some funding, probably switch to another license.

Anyway, if you or anybody has a specific proposal about how you would like to use Aquameta, I would certainly entertain it and that might be the best way to move forward. I can license the code to whoever I want, however I want, and the default GPL license isn't the only scenario possible here.

[gisborne]

As soon as you start to get contributors, this is no longer true. For a while, you could have contributors go back to update their license terms. But after a while that will become an issue.

I feel the conflict between open source and earning income. I’m engaged in a not-dissimilar project myself.

Here is an idea I’m contemplating using with my project: come out early with a catalog of services, and charge for listings for any service that isn’t free and open source. Be the Google of the enormous new space you’re building. The code is entirely free and open source, but you pay a modest fee to participate in the service fabric around it.

On May 13, 2019, at 14:01 , Eric Hanson notifications@github.com wrote:

Anyway, if you or anybody has a specific proposal about how you would like to use Aquameta, I would certainly entertain it and that might be the best way to move forward. I can license the code to whoever I want, however I want, and the default GPL license isn't the only scenario possible here.

[ar-jan]

Potential contributors could be required to sign a CLA first, allowing Eric to always give/sell the code under another license to commercial parties, I think?

[gisborne]

An improvement, but it still doesn’t answer what happens when I want to build an application that extends or is based on Aquameta, rather than a new, better version of Aquameta.

I’m very happy to have the new, better changes be GPL, but I see no in-principle way to distinguish those from the application based on Aquameta, given the architecture which would require admixture of that code with the Aquameta code either way.

Thanks. On May 14, 2019, 01:21 -0700, Arjan notifications@github.com, wrote:

Potential contributors could be required to sign a CLA first, allowing Eric to always give/sell the code under another license to commercial parties, I think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ar-jan]

In this case you'd make a separate licensing agreement with the team/company behind Aquameta allowing you to develop an application/plugin under a different license than GPL. I don't have experience with this, but I believe it's been done. Perhaps selling such licenses could be a funding model for Aquameta as well.

[ar-jan]

Here's an example of a GPLv2 software project offering dual licensing for commercial use. In that case there are no external contributors for which they'd need a CLA. An example for how that could work is here.

[davidfetter]

Sorry to join this late. If you switch to a PostgreSQL-compatible license like MIT, it'll be possible to push parts of this into core. Might that help sway you?

[erichanson]

Sorry to join this late. If you switch to a PostgreSQL-compatible license like MIT, it'll be possible to push parts of this into core. Might that help sway you?

Um, most likely yes! What do you think would be suitable for core?

[davidfetter]

At least the views. I'm not 100% sure people will go for DML as DCL/DDL, but those views are much nicer than either the catalog or the information schema.

[erichanson]

Ok. Will release under permissive license in the next few days.

[davidfetter]

@erichanson , thanks!

[erichanson]

@davidfetter Ok the meta extension is now split out into it's own repository, and released under the BSD 2-clause license. I'll hit you up over on that repo with a couple of questions about how we need to adapt it (splitting off the update triggers etc.) for inclusion in core.

https://github.com/aquametalabs/meta

As for the rest of the project's license, I am increasingly wary of entirely non-reciprocal licenses. Big companies are becoming increasingly exploitive of open source projects, and I really think some semblance of consciousness towards market realities ultimately serves both the project and the community.

I recently discovered the BSL (Business Source License) from the folks at CockroachDB. @spencerkimball gives a nice breakdown of their reasoning for choosing the BSL (interview) and I'll probably go that direction for the next release (which I'm finally finding space and time to work on).

Again, if anybody wants to propose a commercial licensing arrangement for something specific, I'm all ears.

[gisborne]

FWIW, the very liberal license for Postgres has clearly served it very well.

Guyren G Howe On Oct 2, 2019, 11:06 -0700, Eric Hanson notifications@github.com, wrote:

@davidfetter Ok the meta extension is now split out into it's own repository, and released under the BSD 2-clause license. I'll hit you up over on that repo with a couple of questions about how we need to adapt it (splitting off the update triggers etc.) for inclusion in core. https://github.com/aquametalabs/meta As for the rest of the project's license, I am increasingly wary of entirely non-reciprocal licenses. Big companies are becoming increasingly exploitive of open source projects, and I really think some semblance of consciousness towards market realities ultimately serves both the project and the community. I recently discovered the BSL (Business Source License) from the folks at CockroachDB. @spencerkimball gives a nice breakdown of their reasoning for choosing the BSL (interview) and I'll probably go that direction for the next release (which I'm finally finding space and time to work on). Again, if anybody wants to propose a commercial licensing arrangement for something specific, I'm all ears. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[erichanson]

@gisborne Since the BSL has a time limit on its exclusions and eventually turns into an entirely permissive license, hopefully we are on the path to such greatness as PostgreSQL. :) But PostgreSQL even in its early days had backers like NSF and DARPA. As an open source developer for my entire career, finding a balance between the open source ideology and market reality is very very challenging. I know you're pressing this issue because you're one of the few who seem to get the project, and I sincerely value that. I'm muddling through the best I can. Thanks.

[geraldew]

While I already knew about the BSL, I took a fresh look at it after the FLOSS Weekly episode about CockroachDb. With the usual disclaimer of IANAL, I couldn't quite see how it is possible to embed a time point into the code, to thus enact the time-delayed reversion to being Open Source. Is such date/time valid as it's declared in the source - e.g. self-declaring its data of creation - or by the timestamps in the system holding the code - i.e. outside the code. Each concept seems to lead to trivial absurdities - e.g. can I put a future date in the code as the time point from which the delay effect will begin?

To be fair to Cockroach Labs, they've bothered write up their perspective in a blog post. https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/

I happen to disagree with them as I don't think their objections to the AGPL hold to scrutiny. There are certainly other businesses using the AGPL to good effect. Of course this begs the usual copyleft vs "permissive" perspective difference - and really that's my point here: people who object to copyleft find themselves hoist on their own petard by the very "permissiveness" they espouse.

I had thought that another recent episode of FLOSS Weekly covered a project making good commercial use of the AGPL. Right now I don't recall which, so I'll leave that unsubstantiated until I have time to rediscover that. (p.p.s. from a quick look, it might be https://www.bareos.org/en/ but will keep looking).

p.s. At least everyone is clear that the BSL is neither Open Source nor Free Software as its stated intent to limit usage violates their agreed ideas of software freedom. This obviously defers discussion to more abstract/fundamental ideas of what that could/should mean. While it's old ground, it's fair for new generations to revisit. However so far, I've not seen anyone trying to build a new conceptual edifice, there's only been tinkering with loopholes and catches.

[gisborne]

IANAL, but AFAIK the AGPL would be particularly awful for this project.

In Postgres, there is no in-principal way to distinguish the code of Aquameta itself from the code a developer has written on top of it — they’re all just functions loaded into Postgres.

This means for the GPL, it would be impossible to distribute a closed-source business application written on top of Aquameta. As I understand the AGPL, it would be impossible to develop anything at all on top of Aquameta, even a service intended to be used over the Internet, without it having to carry the same license.

Perhaps this is the intention, but I don’t think we want Aquameta to be only useful for open source software.

The only reasonable open source license for Aquameta is a permissive one.

On Oct 5, 2019, at 18:41 , geraldew notifications@github.com wrote:

While I already knew about the BSL, I took a fresh look at it after the FLOSS Weekly episode about CockroachDb. With the usual disclaimer of IANAL, I couldn't quite see how it is possible to embed a time point into the code, to thus enact the time-delayed reversion to being Open Source. Is such date/time valid as it's declared in the source - e.g. self-declaring its data of creation - or by the timestamps in the system holding the code - i.e. outside the code. Each concept seems to lead to trivial absurdities - e.g. can I put a future date in the code as the time point from which the delay effect will begin?

To be fair to Cockroach Labs, they've bothered write up their perspective in a blog post. https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/ I happen to disagree with them as I don't think their objections to the AGPL hold to scrutiny. There are certainly other businesses using the AGPL to good effect. Of course this begs the usual copyleft vs "permissive" perspective difference - and really that's my point here: people who object to copyleft find themselves hoist by the very "permissiveness" they espouse.

I had thought that another recent episode of FLOSS Weekly covered a project making good commercial use of the AGPL. Right now I don't recall which, so I'll leave that unsubstantiated until I have time to rediscover that.

p.s. At least everyone is clear that the BSL is neither Open Source nor Free Software as its stated intent to limit usage violates their agreed ideas of software freedom. This obviously defers discussion to more abstract/fundamental ideas of what that could/should mean. While it's old ground, it's fair for new generations to revisit. However so far, I've not seen anyone trying to build a new conceptual edifice, there's only been tinkering with loopholes and catches.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aquametalabs/aquameta/issues/183?email_source=notifications&email_token=AAAG7XZ67PFIM6DIZ37DUCTQNFF45A5CNFSM4HKXTPKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAN7QRQ#issuecomment-538703942, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG7XZ3INX33HRSFF5N2BDQNFF45ANCNFSM4HKXTPKA.

[gisborne]

I adore the idea of Aquameta’s developers being able to profit from their work. It is splendid work and it deserves full-time attention which means decent income from it.

Even so, I believe the only way Aquameta will have the impact it deserves to, is through a Permissive license. This would maximize Aquameta’s takeup.

What is needed now is for Aquameta to be maximally popular as it reaches maturity. If a hundred thousand developers are using Aquameta, not making money from each of them is a fine problem to be had, one that can be solved, probably in much the same way that Postgres itself does.

I don’t think businesses will pay for Aquameta until it seriously stable and tested. The broadest possible use will speed the time to get to that state (because it will attract developers like me who get it), and then folks will pay for Aquameta services the same way they pay (serious money!) for Red Hat.

[davidfetter]

Guygren, it's his hard work. He gets to decide what to do with it. You've expressed your opinion enough times, and it's time you stopped.