Open Source world's Bruce Perens emits draft Post-Open Zero Cost License Bruce Perens believes he can do three impossible things, having already accomplished two of them. "I have done two impossible things, though of course I wasn't the only one behind them," he tells The Register. "The first was getting the world to buy into open source, and the second was convincing the ITU (a UN organization) …
I like the idea of the Post Open license. Provided it's supported by the teeth to make it stick that would be a real achievement. But I'm really sad he persuaded the ITU to drop the Morse test. I'd hardly consider that an achievement. Morse may not be used extensively these days but it's the most basic way to signal understandably in the absence of current high tech comms. A spotlight, torch, siren or whistle will do. So I'd encourage everyone who's out and about in the wilds or on the sea to gain basic familiarity with it, as many of us did when schoolboys. I failed my Morse test on speed 40-odd years back, but I could probably still spell out a request for help in emergency. Unfortunately, because of it being dropped, it's quite possible nobody would recognise or understand the message.
The Morse requirement was stopping 75% of the people I knew from getting their licenses, even though they had every other qualification and more.
Some of them just didn't have the time, some couldn't do Morse because of physical limitations, and some from non-physical. One friend had amusia, and just couldn't process it. I couldn't pass because of a spinal cord injury, which stopped me using a key.
We were all blocked from participating and contributing because of an arbitrary hurdle.
When the requirement was dropped, I got my license first, and then told all of those friends.
Some jumped at it.
Some had already lost interest.
Some were already too embittered because of the exclusion.
Of the friends that jumped at it, most of them are now donating their time to our local emergency comms group.
And one of them repurposed a foot switch for me to do Morse with my elbow.
"We were all blocked from participating and contributing because of an arbitrary hurdle"
This...so much this...there are a lot of arbitrary hurdles in HAM radio still...it's a lot easier to get a license...but the restrictions on each tier don't really make a whole lot of sense. They recently upped the power limits for each license, which is nice...but the various restrictions read like a cloud computing pricing plan rather than sensible restrictions.
It would be far more effective to enforce some kind of organisation of the local clubs to give some kind of structure to the whole thing...like having one or two people for a given area be responsible for passively monitoring that area to catch people that are knowingly or unknowingly causing interference.
The whole point of a HAM license is to ensure that you know when a) you're causing interference on critical systems and how to prevent it and b) making sure you know how to stay safe and not injure yourself.
Incentive licensing is a legacy thing and doesn't necessarily make sense, and a good deal of the FCC rules come from the '40's or earlier. But some of the rules are necessary. For example we can't have encryption because it would break the self-policing function (you'd not be able to tell what the message was, and you'd have to treat every one as an emergency communication). And some things, like a prohibition on music, are to curb wannabe broadcasters because we would like to have the frequencies for people to communicate one-on-one.
"For example we can't have encryption because it would break the self-policing"
Why does it matter what the contents of a message is as long as the signal isn't interfering with anything? The point of ham license is to prevent people being dumb and interfering with critical public systems. We already have laws governing copyright, we don't need additional regulation on top of those laws to enforce copyright.
My wifi is an encrypted form of radio.
there are a lot of arbitrary hurdles in HAMradio still...What's with the capitals? It's not an acronym.[ . . . ]
The whole point of a HAM license...
I think most HAMs would disagree with you.
The HAM radio scene is aging and shrinking...not enough people are picking up licenses for it to remain healthy. They're really itching for younger technical people to get their HAM license so they can expand what is possible in the HAM space and introduce new skills and technology.
I've long been into radio (I'm a nerd, I like tech) but I don't have a HAM license (yet)...I know a lot of HAMs that are about 20+ years older than me...they're all trying to get their teeth into SDR and the various tech that comes with it but they just don't have the people in the community with the knowledge...I get tapped a lot for info and I assist a few of them with SDR stuff...every single one of them keeps essentially begging me to get a HAM license because they want me to turn up at meets and be able to operate my own radio.
The catch 22 is that I'm not that interested because the scene is aging and shrinking. I'd be the youngest guy in the local club by decades (I'm 40 by the way) and I would still be considered old by any even younger folks considering joining...that and I'm more interested in other aspects of radio that are still essentially off limits for HAMs...I work in a lab that deals with broadcast television testing, streaming etc...so I'm more interested in the digital side of signalling than the analogue stuff and I can build setups to mess with that using a couple of SDRs linked together (a pair of BladeRF boards) in a shielded box.
As for understanding a morse message...I think it's probably enough to just recognise that a message has been sent in morse...knowing it by heart is probably less important now than it was...especially since every radio setup I've ever seen in a HAM enthusiasts shed has a laminated print out of basic morse code, right next to the radio..I would hazard a guess and say it's probably extremely likely that if you are in a situation where you're the only person in a room that is receiving a morse signal from somewhere, you will likely be able to find the information you need to decode it somewhere in that room a morse code cheat sheet is a pretty standard thing...it's probably more useful to make having a laminated morse code sheet next to a HAM setup mandatory than to force everyone to learn it...or even a full binder of standard shit that needs to be presented if your setup is ever inspected for some reason...a bit like a company ISO certification...nobody knows the entire contents of the binder, but one of the conditions of being ISO certified is that everyone knows where to find that binder if it is required.
FYI Ham isn't an acronym :-)
A relatively small group of highly-technical people and I have been working hard to make things more attractive to young people. Some highlights are FreeDV and CODEC2 https://freedv.org/ . We really did a lot of industry-leading innovation on ultra-low-bandwidth digital voice CODECs and continue to do so. M17 which is a series of VHF/UHF digital communication implementations using CODEC2 including an entire Open Hardware walkie-talkie (hams call it an "HT") and an Open Hardware repeater design. There is also the work of Joe Taylor on WSJT, which is a number of different forms of HF digital communication, and there is probably a lot that others can add.
It'd be more attractive if the kit was cheaper. It's a very expensive hobby...for reasons I can't fathom...most of the kit I've seen and used costs a bomb but it's not particularly sophisticated in terms of electronics etc most of it isn't even well built, I've got cheap Chinese soldering irons with better build quality...it's not like radio gear is bleeding edge technology...it's likely expensive because the industry around manufacturing it is probably tied up with licensing etc etc.
>The HAM radio scene is aging and shrinking...
Bollocks.
Been a "ham" for 45 years now.
Dropping of Morse test really HAS increased the number of users and has totally defied logic (great!)
The bands are full of it more than ever which has even surprised me as a Morse user.
Number of hams contributing to the hobby, often with software is up.
The downsides, VHF and UHF usage is down, no local chats, it's all on HF now, but that's about it.
Plenty of young blood in their 30's are producing intelligent contributions to the scene.
The death of the hobby was often spoken about from the 1950's and 60's, and it still has not happened in the slightest.
I think the poster is referring to Red Hat / IBM's contract with its users to only provide security/bug data and patches immediately to RHEL customers, and if the RHEL customers themselves disclose that data, they can no longer be RHEL customers. This is generally seen as exploiting a loophole in the GPL, and was also topic in Open Source Security v. Perens. The license I wrote has specific terms to prohibit that.
Original anon coward here:
Thanks for the clarification. I didn't know about that. I thought he was simply complaining about open-source being used in the ways that prompted you to write the new license.
And, I agree with the original poster - that's a pretty scummy thing for them to do.
Good luck with the new license. I did have a quick read, but the lawyer-speak went way over my head! :-)
Thanks! Unfortunately it is often the case that the developers out in the trenches don't know the size and kinds of abuse that are happening. I appreciate The Register for their their reporting on such things, and allowing me to be heard on their publication.
Or correcting a (common) misinterpretation of GPL…
Remember GPL Open Source does not mean given away for £0 to anyone (regardless of whether they are a customer or not) who wants to download the software…
No one is stopping people from paying for Open Source, the issue is we to make it absolutely clear, there is an expectation on the user (including hobbyists), that they will £contribute.
Which in some respects is the same as the new RedHat RHEL support/subscription licence; you pay the RedHat subscription because you are big enough to want and need software support and are able to afford the fee…
RedHat are simply saying they are only really interested in those who are prepared to pay the fee…
I suspect the larger Open Source companies, such as RedHat, may combine licenses, hence release code under POL and charge for support/updates.
POL may also make sense for Indian, Russian and Chinese OEMs, selling into the US market…
I've been running a small (closed source) software firm for about 25 years now. For probably the first half of that period the "GPL survey" was a fairly common request from our big corporate clients - "does your software make use of the GPL, or make use of any third party software that uses the GPL". We havent' seen it for a long time because I think the firms got used to the idea.
I can imagine if/when this license comes out and is adopted, we'll see the same process - a sudden flurry of panic from the big corporates to ensure they're not using any software that uses it, following by a dawning realisation of how prevalent it is, how much they depend on open source, and what the cost woud be to avoid it, and finally an acceptance that 1% of revenue is a not unreasonable licensing cost.
I'm sure it's going to take a lot of polish to get there, but from the summary in this article it sounds like a genuinely good solution for a very real problem and I hope to see it succeed.
For a small developer it could be a mixed blessing because it would bring their work in scope of the recent EU Cyber Resilience Act: https://www.theregister.com/2023/10/13/can_open
If it did could it raise the following situation: Developer A maintains project P as FOSS only. Developer B maintains project Q with a dual FOSS and Post-Open licence and gets payment from the latter. Developer B then contributes some code to project A. If payment for project Q makes developer B someone who becomes liable under the Act does this then taint project A with similar liability?
Yes, we would potentially be liable to do some things that the EU CRA requires. One benefit of having a central organization is that it's easier and cheaper to do that for the entire community. I understand that "central organization" is anathema to a lot of people for good reasons, and making the governance work is something I'm putting thought into.
Would this central organisation look like this?
https://www.itlos.org/en/
If not, I wonder about a) which court cases would be heard in and b) what remedies would be available to those bringing action for infringement of terms.
It will be interesting to see how this progresses.
Well fortunately we don't have to reinvent courts and law as they somewhat did have to with the Law of the Sea issues. The license, near the end, has a section on arbitration. The operating agreement (not yet written) would give one organization the right to sue on behalf of all developers (and that part is mentioned in the existing license).
Governance, IMO, is a larger issue. Individual developers should be the only ones with voting power. Making the organization something that people can trust is going to be a big problem.
Place of Arbitration, and 'law of contract' needs to be defined to make arbitration work.
I spent some time writing contracts with arbitration as sole remedy.
One place and one law system does not 'always' work, as some jurisdictions
allow their 'users' protection in only bringing law suit in their own jurisdiction.
Making the governance work is hard. Organisations tend towards corruption, when money is involved.
Consider what happened to the popular democracy and the "at large" governance provisions in early internet governance. Now we have policies that are designed more as revenue extraction opportunities than as ways to promote good governance.
So best of luck.
I disagree. I think it will be a harmful idea both in the short and long terms. There are several problems with it. I could write many pages on why, but I don't think you want to read that much, so here's a short list of the problems I see with it.
1. It limits the freedom to fork, because if I fork someone's project, who gets paid for use of my fork? Me or them? Or both of us somehow? This is an important issue because, if I get paid for the fork, the original authors will need to prevent me from forking to collect their revenue.
2. It introduces more incentives to get yourself included as a developer. How is the money allocated among developers? Does doing pointless work to increase your lines of code increase your payout? How much extra work does this add for the maintainers? If it is allocated equally to developers, then why don't I contribute a single commit from the accounts of everyone I know to get payouts?
3. It centralizes the authority for this in one organization. Nonprofit or not, that's no guarantee of anything. ISOC/PIR was a nonprofit, but that didn't stop a months-long fight to try to prevent them selling off the .org registry. Do we want to give much power to a single, license-mandated organization? Do we really think we'd have control over what decisions they make?
4. It goes against one of the aims of open source that caused Mr. Perens to resign from the OSI in 2020. From that article: "One of the goals for open source was you could use it without having to hire a lawyer. You could put [open source software] on your computer and run it and if you don't redistribute or modify it, you don't really have to read the license." This no longer applies for companies of a certain size. Sure, I'm not a company worth $5 million, so it's not me that's affected, but that doesn't make it good.
5. Your assumption that "an acceptance that 1% of revenue is a not unreasonable licensing cost". No, they won't do that. 1% of Google's revenue is $3.08 billion with more of that next year. That's just for projects that adopt this license. Other open source stuff doesn't get included. This means two things. First, if they pay it, they are almost certainly not paying any more to other open source software because they've already paid plenty in their mind. Second, they have a large incentive not to use this stuff and, where necessary, to build a different version. They have history in doing it. When Busybox demonstrated that they were eager to defend their licenses, Google made sure that they used something else in Android, and that got adopted elsewhere as well. Do you want to give companies an incentive measured in the billions per year to make sure these projects don't get adopted?
6. It eliminates the benefit of open source which made it usable without conducting license audits.
7. It continues the, in my opinion harmful, tendency to pick a villain and declare that their use of open source is exploitative. A license designed around my opinion on who is good or who is bad is not going to be a good one. Changing the person who makes the decision will not improve this. There is a reason why the original OSD had two explicit non-discrimination clauses and five in total. Encouraging people to drop this, which already goes against that definition, will likely result in even more of them being dropped.
I've long considered Bruce Perens one of the people who best expressed my views on open source, its structure, and its importance. That is no longer the case. If you want proprietary, write proprietary.
Forks would be paid for because money will be apportioned according to the use of the program - more paid users equals more money - and the size of your contribution. I plan to do this by instrumenting git repositories, and there is already some software that does this, but you are absolutely right that it is vulnerable to make-work and both the algorithm and the operating agreement would have to combat that. There are also some forms of developers who cannot be accounted for solely by lines of code and they might even have to have a "time card".
I never thought I would be disagreeing with one of my personal heroes but I think doublelayer has captured my views exactly.
I understand that the crisis in funding, managing and staffing critical open source projects is severe. But I live in hope we can find a better solution than this. The ISOC debacle must show us that this is just not going to work as a long term solution.
Thanks for the hero part.
The problem I am having is that pretty much every solution put up so far still makes the developer a supplicant. Or to say it more plainly, a beggar. If you want to get paid to make Open Source one of your very few choices is to work for a big company. And there will be conflicts of interest between the company goals and their Open Source project and your personal goals. Or we can have Linux Foundation take care of the issue, which is entirely in control of big companies (frequently in El Reg I have called them "loggers who speak for the trees").
Wouldn't you like to stay at home and just code on your project, and not have to run a front-line service organization, and get paid enough to support your family? That means turning the power differential on its head and giving developers the power. I have so far only come up with this way to do it.
I think one central disagreement we have is this: "If you want to get paid to make Open Source". You may want to be paid to do all sorts of things which doesn't guarantee that you will get paid the amount you want. One of the downsides of writing open source is that others can take your work and use it without having to pay you. They might, and you can do things to encourage it, but you don't have any guarantee of that specifically because I have the freedoms to use it, modify it, and distribute it without having to do something for you or get your permission. The alternative is obvious: proprietary. You write the software, you sell the software, you get money. People who try to pretend that these two can be merged end up making something that looks and works a lot like proprietary software, then try to claim that they're operating in the same spirit as actual open source authors. They are not.
I don't think I'm telling you anything you haven't seen before, in fact anything you haven't argued a lot better than I have. For example, I can refer you to this article. This includes comments from the OSI and from you about claims of something being open source when it's not. I don't think you're claiming that this new license would be an open source one as it obviously isn't compliant with the OSD, but I think it's also harmful to try to claim it's even slightly close to the spirit. If you think the original open source idea has failed, fine, but make it obvious that this is a third, unrelated, path so real open source isn't damaged as badly if any of my concerns expressed above prove valid.
There's a lot of reasons people start contributing.
- Kudos
- Their employer wants the thing
- Fun
The trouble is, if a project of yours gets extremely popular, the kudos doesn't pay the bills and your employer generally has other tasks they want you to do.
Getting emails from a big corporate demanding that you do X, Y or Z is rarely fun. It tends to be very draining, especially as the letters are sometimes quite threatening.
So it's pretty common for the original small team to get disillusioned or 'burn out', and quit the project. Someone else may take over, but can you trust them?
I think this is the major risk this is intended to help with - running interference when a big corporate sends nastygrams.
It doesn't run any interference. It isn't intended to. All it's intended to do is to get money from corporate users and hopefully return it to the developers, which I don't think it will actually do.
However, I am less concerned about the things that you mention. I already have a form letter for requests to add something to an open source project that aren't on my plan. It tells them that the suggested feature is not on my roadmap, that it is open source so they are free to contribute, and that I use a variety of methods to decide what is worth my time to implement it. Essentially, I tell them that if they want me to write something that I don't plan to write, either they provide me convincing evidence that a lot of people would benefit, they provide me with money, or they do the work. I will usually review their idea a bit so that, if it's something I won't merge, I can tell them ahead of time. If they have sent a request, they'll usually get something like that.
If they threaten me, they won't even get that. I do not respond well to threats. I haven't had the same experience that you have because I've received very few abusive communications. Those I have received have been from individuals, and I've informed them that I consider their messages inappropriate, and if they keep sending threats, add an email rule to automatically delete them.
The license itself actually prohibits people from calling it Open Source, or calling software under it Open Source unless it is actually dual-licensed as Open Source. I am very sensitive to the branding issue and have done my best to take care of that.
I am also trying not to damage Open Source, but first in my mind is the Open Source developers, who IMO deserve a better deal than they are getting for the fact that the whole industry seems to be built on their work now.
The other part is the Freedom one. Freedom should be about helping people. We don't do that very well today. We do have about the most effective corporate welfare program ever enacted. This seems rather unbalanced to me, and I think I could fix it.
Thanks, Bruce.
I think this is the main disagreement. I realise you are not proposing allowing people to call it Open Source. Instead, what you seem to be saying is that Open Source is not a suitable model for the future - primarily because, in your opinion, it is not sustainable.
Personally, I am not convinced that making Open Source projects into a closed source model is the right answer. It may well be a useful answer for some projects but I don't see it likely to work for the projects like XZ, and many others, which are small (few developers), with relatively little change, but widely used. Many of those developers are at least partially motivated by contributing to the greater good and making their own work freely available for others.
I feel a better solution to the problem lies with the distros, and other large projects which are themselves at least partially free. Those have much more chance to do things that can bring in money (sponsorship, services, ...) and they are in a strong position to contribute to these small projects (cash, people, testing, emotional support, consultancy, ...). If XZ could have used some debian developers (say - or even Google developers), instead of accepting input from unknown people on mailing lists, would the problem have been prevented?
My problem with the model we've been following for 27 years, or longer if you count Free Software and RMS, is that we actually have done pretty poorly at helping people. If you look at what the normal non-nerd person is using, there is Open Source in its infrastructure, and the applications are proprietary. The apps come from Google, Apple, and their friends, and they exploit the user in that their main revenue generator is to collect monetizable data on that user or to present information to that user that they haven't chosen (mainly advertising). Open Source enables that exploitation.
The problem is that our developers make software for themselves and people like them. How do you get them to make apps for the common person? Paying them is probably necessary. And then I got to thinking about how to pay them.
I also don't think this is a "closed" model. It can be read, modified, and redistributed and you don't have to pay anything unless you make over USD$5M/year end-user revenue or you put the software in a product that is sold. So, I think it is refocusing on helping the "little people" which we've been really poor at so far.
I am afraid that we aren't being realistic about XZ using Debian developers, as Debian is on the edge of not having enough of those to stay afloat IMO. And Google just laid off the Python team. Expecting our corporate "partners" to help us with every problem isn't working.
"The problem is that our developers make software for themselves and people like them. How do you get them to make apps for the common person?"
I don't think this correctly describes what exists. There are a lot of open source applications out there that do the same things as proprietary ones. Since you mentioned Google, I can think of very few things that Google has that there isn't an open source alternative to (mainly Search). People choose to use Google Meet instead of Jitsi or something like it because Google Meet doesn't require you to admin a server, do manual account management, or pay for bandwidth. People either don't understand the privacy differences between them or don't care, but the problem isn't that an open version is unavailable. The same thing applies to Docs and the online version of LibreOffice from Collabora, Maps and OSM-based software, and on and on.
You need to decide if you're attempting to pay existing developers and possibly enhance their offering, or creating software for the common person. The two are very different, and if you're talking about incorporating post open source components in a company's product but the post open institution paying the developer to maintain code, it means the former.
In either case, the same as eating an elephant : in small chunks.
Find a product where enhancing it would create a measurable benefit to those deciding to pay the post open fee.
Attempt to get funding in addition to whatever the cost to use all post open source is, from large companies. A float is likely to be necessary.
Academic institutions are a valuable resource too, if students can be leveraged to help.
From the funding you have, employ or contract people to achieve your specific aim. The issue here is that this is a company issuing jobs, where developers, support, and administration staff largely speaking do not get to choose many of their priorities. Either these are salaried jobs, or fixed price contracts with specific aims and payment on acceptable delivery.
Definitely offer consultancy and paid development on top of this.
Once there's a success, shout it from the rooftops. Measure if this results in additional income.
Assuming it does, move on to enhancing both another area that would get attention, and one that is important but mostly won't be noticed. Repeat until you succeed or run out of money.
> You need to decide if you're attempting to pay existing developers and possibly enhance their offering, or creating software for the common person.
I am not yet convinced they are mutually exclusive. I think a certain amount of funding can be dedicated to helping the common person, and that effort might become self-sustaining (in that companies have a need to support their employees with the same sort of software, etc.)
Yes, I am hoping that Post-Open can operate a front-line service organization for the whole collection, and pay the maintainers to fix their own software as part of that. But the maintainers would not have to deal with the customer directly.
Depending on how you try to do it, they may be mutually exclusive, or rather they may torpedo each other. Let's use an example I mentioned: Jitsi for video conferencing. Someone replied saying that they considered and rejected it because it wasn't good enough. Fair enough; they were probably considering it for actual work purposes whereas I was setting it up for an early pandemic situation where many other things were overloaded. It looked fine to me, but I wasn't trying to run a business from it. Let's say that we relicense Jitsi under this new license. The main effect will be that nobody ever uses it again.
A business can adopt Jitsi now. If they don't like what it does, they can pay someone, either their own employee or one of the original devs, to fix that problem and keep using it. Or they could just live with it. If they have to pay 1% of revenue for this, then they have to compare it to the alternatives. Teams does not cost 1% of revenue. Google Meet doesn't cost 1% of revenue. Nothing costs that much. Your version is now extremely more expensive than anything else. The money that's supposed to make the post-open version better won't show up because the proprietary ones are both better and cheaper.
This also raises a philosophical point. If someone made this post-open videoconferencing tool, why is that any better than a proprietary tool? Open source is better in my mind because of the freedoms it provides me. Some of those freedoms are already explicitly lost with a post-open version, and I don't see how most of the remaining freedoms will last if this takes off. It no longer works as a community effort. It's just another proprietary product with more onerous license terms. There are few differences in practice between a post-open product and all the other non-open "you can give us your code for free and we can still decide not to let you run it" licenses.
Jitsi I was mostly investigating during the pandemic. I wanted to use an open source solution where possible, but for consumer usage Zoom had more functionality, worked better, and was easier to set up and use despite (because of?) it costing money (and as was later discovered, having privacy issues). I've generally not looked back - consumer wise it's still Zoom plus Discord, for business use Teams is used, and whilst I have problems with that (unlike Skype for Business it doesn't integrate into Outlook, occasionally screen sharing doesn't find multiple monitors or doesn't work) I suspect it's still better.
You're making good points that I agree with though, chief are which that 1% revenue is too high a bar, but also that a substantial amount of development can be purchased for 1%, it may actually be cheaper to buy commercial closed source products (that include real updates and support) than pay 1%, and that as soon as money is charged post open programs are competing with everything commercial.
One reason I believe the licensing fee should be radically lower, but apply to basically everyone, is not only to increase the number of income sources and the probability the fee will be paid, but also to ensure that product direction is not potentially influenced predominantly by large companies, which basically applies to a non trivial amount of Linux development today.
I've bought products for open source OS, and contributed to open source projects (including money). There's a substantial functionality gap between Windows and Linux, and as much between Linux and FreeBSD. I would definitely contribute towards projects with specific aims that plugged a needed functionality gap, especially if it was designed to be cross platform.
I agree that we should try to fix this. I don't think your solution does, and from your statements, I'm surprised you think it does. The problems of paying developers and causing them to write user-focused software are quite independent of each other. If I'm completely wrong and the Post-Open license is a global success, it will pay developers for their work, but it won't do anything to make them write their software differently.
If you want to make open source software more popular among the general public, then you have two problems to solve:
1. Somehow get the average computer user to understand why open source, or proprietary but we try to pretend it's the same, is better than using what they already have. Your primary asset will be privacy. Your primary liability is that they will now have to pay for it (at minimum, they'll have to pay for servers where necessary and more powerful equipment where the current software would outsource to the cloud). If you can convince the general public to embrace privacy, I'm all ears. I've been banging my head against that wall for a long time, and I'm likely to keep doing it, but I can't say I've made much progress.
2. Convince developers to do the boring work making their software more user friendly. You can't count on companies doing this for them. Companies could have improved any number of applications, but few of them chose to do so. You could just ask them, but I don't think that's likely to get as much support as you'll need. My suggestion here is that you make an actual company where you pay them to do it, then try to sell the resulting software or, if you're making real open source, the hosting thereof. If you can solve problem 1, that will work fine. If you can't, it's likely to fail. I've seen a few people fail at this mission before. It hasn't stopped me from considering trying to do it from time to time, but it has stopped me from actually quitting my job to found a company competing with big tech with more expensive products.
I've probably posted more than enough on this thread, but I just can't leave these points alone.
point 2 - basically made it myself a bit further up
point 1 : You will not win on this, all you'll do is damage your head. People will use a product, see that it has verifiable instances of their data being harvested and attempts to influence their decisions (thinking social media here, Cambridge Analytica etc, but they're nowhere near the only instance), have it widely covered in the media, and then go back to using the same product again.
Look at posts on here where I've suggested a legally enforced period of security support for devices (which the EU and UK are coming around to agreeing on), and the fact people should also be restricted from using insecure devices. Look at the amount of push back at the suggestion people should pay money to keep themselves secure, increase device lifespan, or reduce choice in order to increase security or decrease e-waste.
Look at all the issues with IoT devices, social media, data breaches. See how it does not change consumer behaviour.
For the love of everything, concentrate on developing applications that are zero hassle to use and actually compete with the alternatives, privacy is a lost cause as a selling point
> Somehow get the average computer user to understand why open source, or proprietary but we try to pretend it's the same, is better than using what they already have.
Yes, you seem to understand that this has been fruitless so far.
The software has to be more desirable from the user's perspective. This requires, at the least, more sympathy for that sort of user than our folks have historically had. We have a chance of doing it simply because our priorities are different from Google (just using them as an example, it could be one of many companies), and Google does things to defend their business (like disabling ad-blocking in Chrome) that we don't have to do.
We could do that, and there are some examples where we have. There are some open source programs that have been widely adopted. I'm thinking of things like Firefox, Signal, Audacity, etc, where they have been designed so that the average user can use them and they have been adopted by many people in the general public. Firefox may no longer be the most used browser, but it's still used by a lot of people and doesn't take technical knowledge to run.
Getting people to build with that in mind is a challenge we should face, and it is more likely to happen if those people are effectively told to do it, which usually means paying them to do it. It doesn't work as well if people only do what they want. I know this firsthand. I've written a program which only has a CLI interface, and I know there are at least a few people who don't know how to use that, don't want to learn, and would like a GUI. But the work of writing a GUI for this is quite a bit (this program has a bunch of parameters and several of them have special parsers, so a simple form is not going to be enough). It is plenty of work for me to do and it isn't interesting, so I haven't done it yet. I know that, if I want the general public to use this, I'm going to have to get over that and actually start writing that bit.
What I don't see is how this payment model will actually encourage anyone to do that. It doesn't pay people specifically to design with the average user in mind. It doesn't exclude people who only write for technical users. Quite importantly, it doesn't help convince people to run the thing if the devs did make it easier to use, and another reason why we don't always design with that in mind is that not many average users will run it even if we did because they don't want to do the small amount of extra work that our version would necessarily have over a managed version. Consider LibreOffice. For a lot of people, this can do all the same things as Microsoft Office can. Some exceptions may exist for some power users, but for the average student, there is no important difference. I don't have Microsoft Office on my computer. I've told people about this and showed them what I have. Still, I have been asked to help them find deals on Office licenses, and when I showed them the options, they preferred paying for a non-subscription license rather than using the other version for free. This was not because LibreOffice wasn't capable of doing something; they never tried it and I know that it can do the stuff they need done. They just valued the relatively cheap price over their idea of what learning an alternative would require. If we want them to adopt an open source version, we will have to be able to explain why they should. License details won't change this.
> If we want them to adopt an open source version, we will have to be able to explain why they should. License details won't change this.
And learn the lesson of the 1980s… Remember much of the 80s was about promoting Open Systems and Open Systems Interconnect ie. Networking.
I suggest business got the message, but selected the tools to hand, namely Unix and its bundled networking stack TCP/IP and the Internet… once this happened I suspect you could have given OSI networking stacks away for free and people would refuse to use them; much in the way they are dragging their feet over IPv6…
People will use or pay for a friction less experience. Privacy is far down the list, that ship has unfortunately sailed. Neither do people generally care about security. They aren't selling points.
I would caution when making comparisons that they're made on the basis of actual end user experience. I tried Jitsi, the reason I rejected it wasn't the admin or bandwidth issues, it was simply less functional than the alternatives and actively got in the way of achieving a task easily.
Polishing apps for the 'common user' can be a thankless task that requires a noticeable amount of resource, it's not unreasonable to expect people to be paid for it (and as has been mentioned in other comments, this goes far beyond development, an entire support infrastructure is needed).
The situation is better than it used to be - Libreoffice is now quite accomplished, and both Firefox and Chromium are (mostly) equally functional on several platforms. The Steam Deck by meeting customer needs of easily usable mobile PC gaming, is slowly establishing a solid platform that developers will target - whilst not all the games run are native Linux, it provides an incentive for developers to target the APIs supported by that version of WINE.
> I think one central disagreement we have is this: "If you want to get paid to make Open Source".
What is missing is a sense of the public good/benefit and thus some form of compensation for “good behaviour”.
With utility patents, there is a kick back to the inventor: give your idea to the public and in return you get a period of exclusivity where you can earn some reward.
I suggest with Open Source, we need some form of compensation/reward to those who have contributed their ideas and efforts to Open Source. Currently, it seems the ethos is: thanks for your effort, now p*** off back to your hovell and maintain it for £0…
So go proprietary. We already acknowledge that public good by having copyright, and it's a lot longer and more powerful than patents. You can write whatever you want and sell it to anyone you want. The one thing you shouldn't do if you want to sell something is give it away first.
I've written code as open source, but I've also written proprietary stuff. There have been projects where I thought I might be able to sell them and that I'd rather do that than let anyone use and modify it for free. Advantage: I could get paid, and not through external schemes but for the work I'd already done. Disadvantage: I wasn't going to get free work from contributors or the free publicity from lots of users picking up the free version. I was free to decide how I'd sell this. I could let the buyers see the code or keep it private. I could let buyers modify the code or block them. But it was still proprietary, because in order to make sure that I could sell it, I didn't grant anyone a license to use, modify, and distribute the way that I do when I put an open source license on things. If they wanted to use it, they had to pay me for the privilege and it would come with more restrictions.
I fully get where you are coming from (all my “projects” have been proprietary because I wanted and needed to be paid), however, the reality of many current open source projects is different, hence the challenge is:
How are you going to get (honest) people to contribute to existing projects such as the XZ compression library ?
This I suggest is the major challenge with a more mature open source scene. If we really think open source is a good thing, we need to reward contribution - whether it is new original open source or maintenance and enhancement of existing open source; albeit a side effect might be that people wishing join a project might need to go through a process similar to employment (ie. Cv, interview, references, contract, oversight), so as to ensure we are rewarding real contribution.
I agree that a major strength of open source is that it can be used without a license audit, but the corollary of that is it's transparent to management. Most companies depend on open source, I can virtually guarantee that none of them have any idea how much. Until that changes, asking them nicely for any sort of support for OS development is pointless.
Whether it's $5m, whether it's 1% and exactly how the money is distributed are details that will shake out over time, I'm sure. But the central core of this idea will force companies to audit their use of open source, As I said above, this wasn't uncommon in relation to the GPL - industry will cope. Will some code be rewritten as closed source? Probably, but less than you think. It's not just cost of development time, that introduces instability into a system that most companies won't want. Big firms don't like change - give them a choice of paying out some money or writing their own version of libz or openssl, they're going to pay up.
The Open Source movement was always about idealism, but the XZ situation has been predicted for years. It's time for a cold dose of reality, both for the OS movement and industry.
(original AC above)
> I agree that a major strength of open source is that it can be used without a license audit
This is also going to be the Achilles heel of the Post-Open License, as without some form of licensing model, a circa £4M(*) revenue organisation which only uses a single system running POL software for some IT support function, will be paying the same royalty fee as a cloud provider with hundreds or thousands of systems running POL software delivering their line of business cloud service.
Interestingly, whilst I fully get the license audit issue (particularly with respect to On-Prem usage of Oracle, Microsoft and IBM mainframe software among others), with cloud the cloud providers do collect very clear service breakdown and audit data as part of their monthly invoicing…
(*) Exact revenue value is subject to exchange rate fluctuations…
I am not sure that is when it kicks in. The article says:
"The basic idea is companies making more than $5 million annually by using Post-Open software in a paid-for product "
So presumably your first example would not require licensing.
However, this is not what the draft text of the license seems to say. I think either The Reg has got it wrong (and you are right) or the license needs clarification.
As I understand it, the rules work as follows:
1. Company earning less than $5M, using the code but not in a product: no payment.
2. Companies under $5M: using in a product: 1%.
3. Companies above $5M, using the code anywhere: 1%.
So it sounds like the medium-sized company using it internally would have to pay around $50k per year for their internal use. This is why I don't think it will be accepted. Companies will get near that threshold and either hide the fact that they're using it or go find something else.
The fee is supposed to be 1% of revenue, so the cloud provider, unless they are also making only £4M, will be paying more. As I described above, I think that will mean that cloud providers end up making sure that projects like this are not used in their systems and their doing it will make sure they're not used in lots of other ones as well.
"Big firms don't like change - give them a choice of paying out some money or writing their own version of libz or openssl, they're going to pay up."
I don't agree. For example, when Elastic switched their license to a non-open one so that cloud providers couldn't use it anymore, AWS could have opened a negotiation, figured out how much to pay, and given them the money to keep hosting Elastic Search. They could have afforded that easily. If Elastic tried to bargain too aggressively, AWS could have just bought out the company. The recent sale to IBM is about the same as one year of 1% revenue collection. Amazon could have owned Elastic entirely, meaning that not only do they not have to pay any more fees, but they could start to collect them from other cloud providers instead. Amazon did not choose to do either of these things. They forked and supported it, allowing other contributors to help them, but still taking on plenty of extra work requirements. They did this because it costs less to pay some people to run this, including some of the people who contributed back when they didn't own it, than to buy or license it. If the price is high enough, companies will choose work over money, and 1% of revenue, while it looks small, really isn't.
It's notable that Debian cryptographically identified every developer and had a working software chain of custody from the early days.
Actually I get paid to do license audits and there is unfortunately a need in the corporate world. I think the big ones have Open Source compliance departments that cost them USD$7 Million and more per year. I think I can make compliance easier and cheaper for them, even if it includes writing a check.
The sales pitch of "I can remove your $7 million license department and all it will cost you is $3 billion per year" doesn't sound like it will convince many companies, especially because there are two reasons why their license department probably won't get any smaller at all:
1. I'm guessing that simply paying the assigned amount to the organization isn't enough and a listing of used projects and some way of figuring out how important it is to the company* will be needed to distribute funds as fairly as possible. Someone needs to track and report this. That sounds like the open source compliance department.
2. There will still be lots of software that is still open source, so the compliance department still needs to exist to deal with that.
You know this better than I do, so maybe I'm missing something.
* I assume that funds will be allocated based on how much a given project is used in the company, meaning that my 200-line library which I got someone to include in one rough internal tool won't receive as much money as the million-line project with critical security requirements used in hundreds.
I am hoping that a lot of existing Open Source projects will eventually dual-license. Making money is a good incentive :-) If you have the paid license, you no longer have to concern yourself with the Open Source license on that software.
I am not assuming that IBM (or any really giant company) will jump on early. I think the smaller ones first, and a lot that start free and get bigger. When the time comes that it makes sense for a really big company to jump on, I think the value to make it worthwhile will be there.
I also am not going to feel bad if we don't win everyone.
A lot of you will see more of how this plays out than I. I'm 66 years old...
"You could put [open source software] on your computer and run it and if you don't redistribute or modify it, you don't really have to read the license." This no longer applies for companies of a certain size".
This sentence starts off talking about personal freedom, then moves to Corporate freedom.
They are not the same kind of freedom. Corporations are not persons; they are commercial revenue generating legal entities.
The quote was also considering corporate requirements. So have all the open source licenses. It's been clear from the start that individual use only would not qualify. Maybe you think that is wrong, in which case you are free to write a different kind of license, but there is a reason why I don't support those.
"The quote was also considering corporate requirements".
No it wasn't. Here's the larger quote
"One of the goals for open source was you could use it without having to hire a lawyer. You could put [open source software] on your computer and run it and if you don't redistribute or modify it, you don't really have to read the license. This no longer applies for companies of a certain size. "
I see a pattern here where you invent new "context" to cover up for sloppy reasoning.
And still the flaw in this rationalization is equating persons with corporations.
You've misinterpreted my comment, mixing something Bruce Perens said (in quotes) with something I said. I was quoting his comments which you can read in more detail in this article. The effects of the license discussed there are, in fact, specifically applicable to companies. It is also specifically mentioned in the Open Source Definition:
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
I understand that you don't think corporations should have the same rights as individuals in such licenses. This means you will probably support Perens's current plan more than I do. It does not change the fact that open source licenses do not, and by the OSD are not allowed to, discriminate against companies. Post-Open licenses can and will, which is one reason I oppose them.
I can also tell that you're trying to bring corporate personhood into this. If I did, it wouldn't help your case as it is a generally used legal construct, but it is not part of my argument anyway. We can disagree about this and it sounds like we will. I just hope that you can understand what my opinion is and I yours, including the references I have made when making my arguments.
Problem number one: 1% of revenue (i.e. turnover) is a vast amount for many companies running on wafer-thin margins. Almost certainly, all large companies will simply reject such software and make it policy to forbid installing it. Companies even below the threshold are going to avoid it, for fear that one day they may grow or be acquired.
Problem number two: there is no reflection of the value provided. You use one teeny library? You pay 1%. You run your entire operations on an open source ERP suite? You pay 1%. Better to rip out the open source library, and pay for an ERP suite if you need it (which will in any case cost you less than 1% of your turnover).
Problem number three: who decides which authors get how much? For there to be any chance of fair distribution of the revenue to software authors, businesses will have to say which packages they use and roughly what proportion of benefit they get from them. Not dissimilar to licence audits in fact - although they could be optional.
Basically, they will get all of the downsides of commercial software, with none of the upsides (e.g. paid for support, patent protection etc)
Problem number four: it's no good for software authors either. There will be the Spotify / ICANN problem: if there *is* any revenue raised, most of it will be swallowed in the admin costs of the non-profit, and very little will trickle down.
Problem number five: most significant software is delivered as SaaS these days. If (say) AWS were to host this software, does that mean AWS pays 1% of its total revenue, or does it require its customers to pay 1% of *their* total revenue? Either way, you can be sure that AWS and the other big clouds will not touch this stuff. And if you can't run it in the cloud, it's irrelevant today.
Problem number six: there will be more duplication of effort as people have to rewrite software components which they would like to use, and were written under this license, to a more permissive one. It's an extension of the GNU-versus-BSD feud.
In short, this approach is dead in the water. No doubt there will be some authors who will try releasing software under this license. Their software may be used by a few hobbyists but it won't be touched by businesses, large or small, and the authors won't receive any money, so really they're no better off than they were before.
Problem number seven: companies will have to be *incredibly* careful about their dependency trees. Today if you use (say) an Apache-licensed piece of software, but it turns out that somewhere down its transitive dependencies it uses something GPL or BSD licensed, nobody is going to worry too much.
But just imagine if some library you indirectly depend on changes its licence to Bruce Perens' commercial collective licence. You could expose your *entire* company to a massive risk. (This is worse than, say, one of your staff downloading Oracle Java SE without realising that it isn't free)
As a result, companies will have to erect defences against this, and ultimately it could result in a chilling effect against open source software in general.
I think Perens is hoping for the opposite: that companies will say "what the hell: we might as well just pay 1% of our turnover so we don't have to worry about this". There's no chance of that. It would be cheaper to use that 1% to employ more staff to write exactly the software they need, or to pay for commercial software. This could even mean dealing directly with the authors of Perens-licensed software: it would always be cheaper to negotiate a standard commercial license from those authors, than to pay 1% of your entire company turnover to a fund (and the author would be very happy to receive a direct payment).
In this regard, such software is very similar to "shareware": it's available for download, you can try it if you want, and you can buy a licence directly from the author to use it for real. Except this time, if you *don't* buy a licence, there is an automatic penalty which is 1% of your annual turnover. Ouch.
Problem number eight: how are commercial software vendors going to incorporate such software into their products? They're not going to say "here, buy our product, but by the way you must also pay 1% of your company turnover to this central fund if you're not already doing so, because we've included these collectively-licensed components". Surely paying 1% of *their own* turnover would not work; otherwise people could set up middleman companies with very low turnover to resell this software, reducing the payments. The only option then would be for them to contact every author throughout the dependency tree, and negotiate individual non-collective licenses. Which means they'll probably just not use those components, but rewrite them themselves - or more likely, choose alternatives with proper open source licenses.
Problem number nine: most pieces of "open source" software don't have a single author and copyright owner. Even if they do, there may be many additional contributors to the work. How is the money distributed between them? Will all contributors be required to sign a CLA, and if so are they waiving their rights so that the "main" author gets everything? How do you rate 10 small contributions versus one big one, or a recent contribution versus an ancient one?
Problem number ten: authors and contributors are going to have to register their rights and their payment details somewhere, somehow (securely? with authentication?) How is this data going to be collected in an accurate and trustworthy manner?
In any case, all of this seems to fly in the face of the open source movement. From where I sit, it is about collaboration; the ability to work with and learn from other talented people, whilst also showcasing and sharing your own skills. It's about building something which not only serves your own needs but is a creation which you set "free" to be used by others - and if popular, could take on a wider existence of its own.
"The difference is that Spotify is a for-profit corporation. And they have to distribute profits to their stockholders before they pay the musicians." Surely they should be paying their suppliers before their shareholders! They would have nothing to sell without the musicians.
"Surely they should be paying their suppliers before their shareholders! They would have nothing to sell without the musicians."
Would that it worked that way. Your first responsibility as a for-profit corporation is to your stockholders (of course you still have to comply with laws). The "B" corporation actually changes the rules to _allow_ the company to be socially responsible! B corporations are not widely accepted yet.
My feeling is that the musicians are in general exploited by companies that distribute their content, just ask any recording artist about their relationships and then stand back.
People claim this about US (never heard it anywhere else) law but it seems not to be the case: https://www.nytimes.com/roomfordebate/2015/04/16/what-are-corporations-obligations-to-shareholders/corporations-dont-have-to-maximize-profits
B corps explicitly write in social responsibility but it makes little practical difference. There are also "certified B corps" which are a box ticking exercise. One I came across is an MLM!
They do. If they were to go bankrupt, the artists would get paid first. The statement is misleading. I think what that was meant to say was that Spotify, being a for-profit organization, is supposed to figure out the bare minimum they can pay the creators of the music so that they have as much as possible left to return to the stockholders. Theoretically, a nonprofit entity wouldn't do that. Some nonprofit entities actually are run with their charitable point in mind and would fulfill that requirement. Unfortunately, we have lots of examples where that isn't the case. There are three models:
1. Nonprofit entity is founded for a specific purpose and run by people who believe in it. They collect a small amount for their labor in running the organization, a reasonable amount for organizational overhead, and the rest of it gets correctly spent on their goal. I've seen people who don't believe this exists, but I know several firsthand (volunteer, not executive). Sadly, they aren't the only kind.
2. Nonprofit entity is run by people who run it for the purpose it was intended for but mostly do it to collect money. They get nice salaries and plenty of perks paid for from the budget. Generally, the goal still runs correctly and gets funded sufficiently, but it could be better. For instance, ICANN.
3. Nonprofit entity is run by people who only want money and start trying to figure out how to extract as much of it now as they can. Whether that harms the programs they're supposed to be running, risks running the organization into bankruptcy, or violates the philosophy under which they were founded, they go ahead if it sounds like they'll get paid enough for doing it. The programs sort of run for now, but can break at any time when they either sell them off or run out of the funds to continue supporting them. For instance, Nominet.
I'm not really convinced that the artists are preferred creditors of a business like Spotify. It would have to be a contractual term.
Arriving at an organization that everyone can trust is a really big problem. One thing for sure is that governance (voting) needs to be by individual developers, rather than anything like a corporation that concentrates power in one place.
In the case of bankruptcy, payments in contracts are preferred over payments to stockholders. The specifics of the contracts would decide where the artists fall in relation to bank loans, landlords, server bills, or the like, but they would definitely rank above payments to the stockholders. Outside of bankruptcy, the payments to the artists occur first on the balance sheet, before the profit numbers are calculated, and any dividend payments or effects on stock prices occur based on those subsequent profit numbers.
Of course, this is not what we're talking about anyway. The discussion was not about when they're payed. It is about how much they're payed. It wouldn't matter if they were sorted above any other debt from the business if the payments were tiny, and the complaints from artists are not about where they fall in the sorting algorithm, but about the absolute size of the payments.
"If they were to go bankrupt, the artists would get paid first."
In the event of bankruptcy, commercial law defines "Senior debt holders" who are first in line.
Employees and Suppliers (which is what the artists are) are not Senior.
You can see this in so many cases of corps filing for bankruptcy.
In and this race "not first " often means "excluded"
"n the event of bankruptcy, commercial law defines "Senior debt holders" who are first in line.
Employees and Suppliers (which is what the artists are) are not Senior."
Artists would not get paid first with regard to other people who the business owes money to.
However shareholder's get paid what is left over after everyone else is paid.
In circumstances in which the artists would not be paid, the shareholders would not get anything either.
The context of that sentence means that, of the two mentioned groups: artists and stockholders, the artists get their money first. You are right that other debt would get paid before artists, but the artists payments, if any, would come before any payments to stockholders.
“His rationale was that amateur radio should be a tool for young people to learn advanced technology and networking, rather than something that preserved antiquity”
A bit short-sighted. Learning Morse was a good introduction to the notion of encoding information into a semi-binary format. I recall writing a prog that would take a string of characters and output Morse. I also wrote a prog that could read Morse and write text to a screen - which never worked :(
Simple enough... The orgs he expects to pay have made a massive investment in internal development teams precisely so they can self support and don't have to pay....
Ask them to pay and they will just not use your software....
Actually these big companies are the customers of my open source compliance consulting business. At $500 an hour. So I have some idea of what compliance costs :-) I'm actually not aware that they have large internal departments devoted to servicing the open source software that they use. Indeed the reason they use open source so that they can devote most of their development funds to business differentiators rather than infrastructure.
"Ask them to pay and they will just not use your software...."
Sounds good let the parasite corporations expend their own efforts and pay to reinvent the wheel. Then they can stop using, I prefer the term stealing when applied to them, the efforts of other peoples work for free.
Not sure I think much of his idea, at least not the bits involving a non-profit set up as a middleman and no doubt existing (if it's like most of them) to cream off the top for a lot of well padded sinecures, and the '1% of revenue' figure is one of those things that sounds suitably trivial but is actually a huge number, especially as it comes off the top line not the bottom one.
It ends up sounding like an absolutely toxic expensive license you'd work hard to avoid touching in any way.
Seems overly complex to me, but like most of the other posters I agree something needs to happen. I am loathed to do anything to OSS licenses that make them less attractive. The musician analogy/comparison doesn't bode well - musicians really don't so well out of similarish systems. Good to see someone try though. I wish you all the luck. Some thoughts:
1. Someone needs to take IBM to court or close the loophole. To me their restriction is just that and thus illegal, but let's fix it one way or another.
2. Using the code as SaaS just needs to be counted as distribution and customers given the same rights to have the source code as that used on the server. A tweak to the GPL?
3. My guess is hyperscalers et al. would be happyish to throw key OSS developers some crumbs (upto N x $100k pa) for better code if there was a single central organisation that made it really, really easy to do so - i.e. removed any hint of employment liability, and dealt with (self)employed tax and sales tax around the world. The organisation would have to do some due diligence to make sure the right people (and not just the noisy ones) got rewarded. Perhaps throw in some sort of enterprisey like support thing to make the C level suite happy. This would be voluntary, but maybe my opinion of the hyperscalers et al isn't low enough!? They might just do nothing. Perhaps have a public record of who the good and bad guys are?
The two biggest examples, financially, of intellectual property are the music and film industries. In both, the accounting department is the main profit center. By "properly" identifying expenses, any given product can be shown to have occurred at a loss and thus generate no profits to be shared with lesser entities like actors, musicians, and programmers. Superstars who can negotiate contracts to be paid "above the line" are rare for a reason. And as the unions are quick to point out, there is always someone willing to work for nothing unless prevented.
Seriously, good luck with this.
Check out my credits on IMDB. I worked for Pixar for 12 years and know how the film industry does things. And that's why I say end-user revenue rather than profit. It was indeed the case in the film industry that people would say if your film made a profit, you were doing your book-keeping wrong.
One problem I have is that the description Open Source implicitly covers a multitude of sometimes conflicting sins.
At face value it ought to refer to any software for which the source code is freely available for inspection by anyone desiring to do so. The actual code might, like a patent*, be proprietary and subject to licencing and payment for use.
The use of "free" in english has the "beer" (gratis) versus "freedom" (libertas) dichotomy with the second resulting in the fairly unambiguous term "Libre."
The availability of the source is really the only commonality with a wide spectrum of constraints or restrictions of who can use what, for what purposes and a variety of quid pro quos ranging from acknowlegement, donation requests, smalk one time license payment from "for profits" through to full commercial licensing.
In isolation none of this is much of a problem but modern software is a melange of open source (and other) components with often conflicting constraints from the hundreds of licences that might be applicable.
It would be like designing with digital logic components like TTL, with hundreds of different voltage levels and unit loads.
Ideally a license template with an orthogonal set of sections into which a clause may be chosen from a predefined set with the hope that any software component's licencing could be encoded unambiguously and compared with the licensing requirements of any other components used. As there is a ordering induced I guess it might be a lattice. Anyway the idea is that open source software component selection could largely be mechanical in terms of licensing (and function.)
I have always thought the pachyderm in the room is software patents or more specifically the idea that algorithms or formulae can be "owned" in any sense.
*which also mean "open."
I have my doubts. It may benefit FOSS companies, but I see less value for the individual developer.
If you get paid, no matter how little, you generate an income. These incomes are subject to social security, taxes, the lot. So you put the burden with the individual to keep his tax payments right, or else they get in trouble.
Next, your tools. Working from an attick as a non-profit individual, your can in many cases enjoy the free (as in gratis) license agreements. The moment you get paid, this changes and legally you are obliged to switch to a paid license. Is there any money left after all the expenses?
The idea might fit companies that contrbute to open source: these are getting some revenue for their efforts. But I doubt if individual developers out there really benefit at the end.
I'm one of those people who gets the 1099 form from their customers and has a Schedule C on their taxes. There are upsides. I get to take the Standard Deduction _and_ take deductions for my company expenses. And it generally doesn't take me more than a day to do taxes.
Hand-wavingly I think if this takes off we could help the developers with some of these issues. But that is yet to be seen.
Even though I oppose this license quite strongly, I don't think this is a major concern. Getting small amounts of money may complicate tax filing, but it also gives you extra money to help deal with that problem. If the amount of the payment is so low that you don't care, you are free to decline the money, not receive it as income, and therefore not have to file. How much it adds to the difficulty of calculating your taxes depends on what country you're in, but for most situations, it's one number added and one piece of paper. I don't think developers are going to have too much trouble figuring this out.
The noncommercial use only tools are a valid concern, but I wonder how many developers are relying much on these in their work. A lot of development tools are already open source, so it doesn't apply to them. If the expenses would end up being more than the revenue from doing the work, then the developer has the options to find a tool that doesn't impose that cost or to decline the money so they're noncommercial again and can use the tool. While I don't think people would do that for tax reasons, if the tool prices were more than the revenue, they might.
I don't have a dog in this fight, except a small puppy as an end-user. What I can say though is that I'm doubly happy that Mr Perens is willing to have a sensible debate with the commenters here, and that in the main the latter are providing thoughtful objections and insights into a very gnarly matter. Thank you all, have a beer.
"pay 1 percent of their revenue ... That would cover all Post-Open software used by the organization."
I can't see that working if I've understood it correctly. It would mean that if one small division of IBM used Post-Open software in one small project then IBM would have to 1% of global turnover.
Even it only applied to that particular division then companies would set up a division just for products that used Post-Open software.
I can't see a way round this! Have I misunderstood it or do you have a solution to this.
I can see the financial package vendors eg. Intuit (Quick Books), Xero, Sage, Oracle, SAP etc. changing to this charging model (rather than a flat subscription fee) if it gets used.
For one of my clients that would represent a change from approximately £760 pa to £8,000 pa…
Hence I suggest the 1% is way too high.
However, in larger companies (or those with greater IT needs) depending on the financials, it might act as an incentive to switch over POL software, as the more you reduce proprietary licence costs there is no increase in the POL costs…
But look at the reality of IBM. They use Open Source everywhere! I am just figuring this would be the same for Post-Open.
It is indeed a hard decision if you are only going to use _one_ program. But I doubt anyone would do that for long. The whole point is that the expense of compliance for 1000 programs is the same as that for 1.
It is a great ideal, but not very practical. For one thing, participants have to settle for whatever share this organization deems fit, regardless of how important or popular the software in question is. Then there is the question of how to apportion the funds to the multiple developers on most projects, and to determine the worth of their contributions. A thousand lines of my code isn't worth anywhere near as much as a thousand lines of Linus Torvalds' code.
Bruce also talks only about "developers." Does that mean anyone who does documentation, translation, or art/media production for an open source product doesn't qualify?
The whole issue is a can of worms. There is also the problem of currency value translation. Bruce is an American. He naturally assumes this is all going to be done in American dollars, despite the fact that most developers are European, either by birth or nationality. I say this as a Canadian; it is the simple truth of the matter. The Americans are a "world power" because of the threat of nuclear devastation at the hands of theirs or someone else's basket of suicidal toys, not because they are the majority contributors to world knowledge and growth.
It's relatively easy to value textual things, even if they are translation or documentation. There are some people who would not fit the algorithm and might have to account for time. I am hand-waving because this isn't done yet. I think it can be solved but can never be perfect.
The organization will probably be based in California because of favorable law (this was very important for winning my court case, for example, the plaintiff was in Connecticut and I might have lost it and probably would not have been able to recover my defense costs if I had to use that state's law).
The license allows for future flexibility regarding what the currency will be. There are good mechanisms for paying people internationally. Monetary conversion is a bit of an issue in that some countries have official rates that are wildly different from their market rates.
I have a feeling that your same statement would apply wherever it was based.
I don't think we're at the point that the UN would accept us as an international organization and give us a .int URL. Nor do I think organizations that have become pseudo-governmental have done the greatest job. I spent some time examining GS1 (the UPC barcode folks) and IMO the IETF model would have been much better.
That leaves me picking a place. And the farther away, the more expensive, especially if a personal court appearance is necessary. And there is the complication that I don't have the right to do business just anywhere. The Estonian E-passport is an interesting concept, but I don't know at this point if it's better.
The (very real) problem is US government interference, something the IT industry has seen a lot of over the decades, which as its level of psychosis increases will only get worse…
A simple example, in the current political climate, would a US based POL organisation be able to collect monies on behalf of say Huawei and forward said monies to Huawei.
Trouble is the UK isn’t a good place either, given the close relationship with the US, so this isn’t a pitch for a UK HQ…
Don’t know why my last comment was anonymous…
Whilst I would agree, there is a need to get started, I wouldn’t be so complacent, remember the world only got serious open source cryptography by leaving the US and so legally avoid US export controls…
But then perhaps a California based organisation can successfully make the major US HQ’d multinationals give up 1percent of their global revenues…
Personally I sit on the BSD side of the fence, but taking it at face value and hoping open source can get properly resourced I see several issues :
1) I presume the 'use in products generating >$5 million revenue' is due to being able to determine (how?) the product does contain post open source. Nevertheless it has one large problem : why is it excluding SMEs? My guess is this is because small to medium companies would simply decide not to contribute, and ban staff from using any post open source. I'd also change 'use in' to 'use' - why should someone pay if they're bundling a gawk lib in their product, but not if they use gawk in a daily support task?
2) 1% revenue is ridiculous. Even larger companies will simply ban all post open source and re-develop internally. This helps no-one. Pricing should scale from small teams of a few people upwards on a number of employees basis.
My other points are more variably snarky and possibly off topic :
As soon as money is involved it needs to be pitched at a low, low price point (1% revenue is not low) otherwise people will ask what exactly they're getting for it. You're better running a low fee to use, and increasing fees for determining the roadmap/custom features, and consultancy.
Oh &deity; a lot of open source is awful, even supposed large projects. Closed source (basically : Windows) is not perfect, but the effect of a very large amount of money and resource thrown at an OS and its applications can be clearly seen. So much of it is written for individual use cases, not designed around what an end user or administrator would reasonably expect, never mind to surprise and delight them. It's understandable someone is creating this for free to help themselves and optionally others, but as soon as money is involved, expectations rise.
I used to use OS/2, and spent a fair bit of money on applications. 16 bit Windows could fill gaps if necessary, until I moved to NT at the end of the 90s. Now I'm trying reasonably hard to move off Windows to FreeBSD and the difference is stark. Linux is an order of magnitude better, but still not exactly perfect. There is, far, far, *far* too much needing to write your own code for what I would expect are either reasonable use cases, or if they're marginally more difficult, where I managed to pay a fairly moderate amount of money to get a Windows application that achieved what I wanted.
And to open the can of worms, Bruce brings up a suspicion I've had for a while about GPL coders
'Wouldn't you like to stay at home and just code on your project, and not have to run a front-line service organization, and get paid enough to support your family?'
I'm certain a proportion (not all) of GPL developers want to do basically whatever they want to their own project, and be paid as much as a closed source equivalent product. It's a very human desire : all the cake, none of the baking. It's also just as much a fantasy as wanting great services but 'someone else' always paying tax.
It's perhaps possible to make a living writing post open code but there will always be a need for non code writing tasks, and the size of an organisation to cover the admin, and support will be considerable. Each person working for that will expect market rate (or close to it), and developers are not necessarily going to be in control of the direction of products.
If this ever occurs, I see this devolving into infighting as to who gets what part of the pie, and why.
It looks like the original commenter understood that and thought that was a bad idea. I think that's one of the only good ideas in it, so I won't be arguing their point for them, but I don't think your clarification did much to counter their statements.
The proposed license isn't intended to simplify licensing for corporations, much in the same way that individual employment contracts are not intended to simplify employment for the individual.
Currently, there is no pie to fight over - isn't that the bigger issue ?
If some corps don't want to go with the license, that's not actually a negative for the developer. Maybe that corp will do it as a "real" open source project ? ha ha.
But on the matter of cost trade offs, I'll share a typical table with you:
Cost of Licence: Capped at 1% of TR (Total Revenue)
Cost of alternative : Untenable.
Upper management does not have the inclination or wherewithall to set up a development organization, staff it and oversee it on an ongoing basis.
To say nothing of committing to regular production releases.
The complete lack of pie is the larger issue, yes. I would also suggest that some open source communities have a culture issue : more people (not just companies) need to contribute time and money to projects, and buy product. Linux users using WINE? You should be buying Crossover.
However, pitching a license so that it's untenable for companies (corporate or not, I think it should target SMEs too, Bruce doesn't) restricts what end users are going to use. Microsoft sells products cheap for education in large part to maintain their monopoly when the end user moves and expects to be using the same program in their job. If it's likely that the time spent learning a post open source product is not transferable fewer people will bother.
So far as the license cost is concerned, it's a matter of pitching it low enough to be acceptable but not high enough to be annoying.
The company I work for is moderately sized; 1% of TR per year runs into the millions. They recently did an audit of all systems in order to avoid the increased licensing charges of Java, it was uninstalled unless there was a specific reason for it. That's an indication of how low the licensing needs to be. This isn't a poorly resourced or cheapskate company, either.
A development division may have a cost and management overhead, but a reasonably sized team can be purchased for 1% of TR, and any code output is less encumbered by licensing. You've the option to pick and choose between commercial and open source options, and potentially resell your generated product. I suspect for larger companies 1% of TR is potentially significantly more than choosing a number of carefully selected commercial products that have a flat site license.
" Linux users using WINE? You should be buying Crossover."
Excellent point. I'll think about that, personally.
"So far as the license cost is concerned, it's a matter of pitching it low enough to be acceptable but not high enough to be annoying."
Exactly. And "pitching up" from Zero won't fly. Pitching down from millions is do-able. It's kind of like, why negotiate with a union when you can hire scabs.
"A development division may have a cost and management overhead"
This is different from my basic point (and to be clear, I am speaking specifically of a functionally equivalent in-house development) : for a LOT of companies the most substantial "cost" is the intellectual courage to enter the world of Production software development. And that's not a scaled cost. it's a cliff (or Moat) buttressed with FUD.
They simply will not make that leap, short of an exisitential threat.
That's why the Java conversion isn't really illustrative - there are free drop-in replacements available. But did your company actually consider the ongoing support ? Not saying it WILL BE an issue, but management tends to focus on the up-front costs instead of the long term consequences and risks.
For the specific Java example, we're not a Java shop, most software is written in .NET, and from what I know of the various development teams, use of Java is low to non existent. The JRE, however, had been installed on many desktops for historical reasons I can't remember.
However, it is directly comparable to Bruce's idea. With post-open source a company pays 1% revenue regardless of if they use 1 or 1,000 open source products/components. Buying the JRE is the same : if one user in a 50,000 employee company wants to use it, you pay the 50,000 employee price, not the single employee. No company who isn't intrinsically committed to that technology throughout their organisation is likely to accept that.
We do consider ongoing support; one team uses a specific source control that's a notable annual expense, but obviously as it's critical to produce software for customers, it's easily justified.
Agreed on the cliff comment, and that it's easier to pitch down than up. It ultimately comes down to a sales decision, and smaller numbers of large companies charged a lot vs large numbers of small users charged a little are two separate and valid models. The large company model is actually my personal preferred option for software development, I just think 1% is pitching it too high, and that culturally open source users need to get used to paying and/or contributing regardless of their size.
Practical implementing of the POZCL license sounds incredibly complicated - ultimately it relies on a large number (the vast majority) of open source authors joining a single "front" organization giving that "front" bargaining leverage, and hoping against all odds that it will be an altruistic "front". All that while the current status quo sees forks of every popular open source software project which attempts to go partially closed.
Nevertheless, many claim that underfunded open source is one major source of security vulnerabilities that impose enormous costs on the IT industry and the public in general. So there **should** be strong motivation to address that.
However, what we see instead is large companies firing their open source related employees in order to focus money on general AI, stock buybacks, and shareholder dividends, with one justification being that the AI magic wand will fix security problems. IMO, the better approach would have been to refocus open source related staff on security issues, and also develop software-security-task-specific AI tools with the assistance of those human experts. But I don't have to answer to activist investors in charge of moving billions around to find the highest short term returns.
software-security-task-specific AI tools ... for example detecting patterns for security injection flaws, etc,, and using that to scan massive amounts of legacy code. Even then you still humans for the training and to judge the flagged code, issue CVE, etc.
Overall, I like the idea but this new license would definitely need a better name. "Post-Open" doesn't really convey any meaning regarding what it intends to address.
@Bruce_Perens it's definitely commendable your initiative on tackling this problem! Cheers.
I've had an extremely quick scan through, seen some things that caught my eye that I think are a very good idea, and have a suggestion that I acknowledge may already be covered (and apologies in advance).
Administration
The thing that particularly caught my eye was the idea of an Administration. When one looks at large OS projects, the Linux kernel is an obvious candidate. What has kept that together is the energy and work of Torvalds. There's the group that marshalls the work behind GNU Radio too. And, so on. All projects need an administrator, and it looks like this license draft encourages one into existence on a formal basis. That's a good thing.
Suggestion
My suggestion is drawn from the issues that face organised projects. One of the oft-discussed things about the Linux kernel project is the impossibility of re-licensing it; there's too many contributors outright owning too much code who are now either dead or hard to contact. For any project, license inflexiiblity can become a really bad issue, and it can kill projects as those contributors who want a change in direction dispute fruitlessly with those who don't and have no mechanism for reaching agreement.
So perhaps clauses about how much ownership there is of contributed code could be included? It makes sense that if a project under this license has the concept of an Administration that that Administraion has some predefined portion of control over all the code, and some formalised mechanism by which the project as a whole can vote on re-licensing, and the rights a contributor (or their estate) can lose if they stop participating in such votes.
There are kinda precedents for this; the GNU Radio project encourages assignment of copyright to the FSF. Personally speaking I think that's going too far; you lose all your rights as a contributor. Sure, you get a sublicense, but you can't make money from it because you've given them the right to distribute it for free, which is what they're commited to doing. Worse, the FSF could relicense it and monetise it themselves, and wouldn't owe the original developer a bean. Without copyright assignment, arguably GPL goes too far the otherway; the needs of the project and all the other contributors are blocked by the will of the one who disagrees, or who ignore them, or who are now out of contact (and this is why re-writes occur, which is a way out but it's a daft way out).
I suppose what I'm saying is that, as well as a license that describes what rights recipients of a project's output have, a license that sets out what rights The Project itself has would perhaps aid things. The Project is, afterall, a recipient of a contributor's work too, and a predefined definition of what the Project's Rights and Terms are could help the project survive longer term. Those terms can be two way - rights, benefits, obligations, penalties.
Effectively it would amount to the license inferring the existence of a company, without necessarily incorporating a Company in the formal legal sense. By contributing, and that being accepted, one would become a member of that company-like organisation, one has signed up to its rules and processes, the company-like organisation has some rights of its own over the work you've contributed, but through active and continued engagement (not necessarily more contributions, just paying attention to the voting emails) one retains and benefits from the rights one has gained too.
I've no idea whatsoever as to whether a license could ever make such things stick. But if it could, it could give projects a chance of adapting to changing circumstances with as much consent as can be raised, without giving blocking power to any one particular contributor.
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
