What Have We Learned from This Open Source Project? • Hacker News Board

Re: What Have We Learned from This Open Source Project?

#31

Post by EvanPlaice » Mon, Feb 08, 2016, 2:05 AM UTC

legulere wrote: post #14

anc84 wrote: post #4

Earlier quoted context omitted.

It's about missing guarantee of future freedom rather but I am sure you know that.

Copyright owners can always decide to release future versions under whatever license they please.

The thing is, contributors hold an implicit copyright to any work they produce. So, it's not possible to change the license without either extracting code contributions or gaining approval from all contributors. That's why many GPL/LGPL projects couldn't change licenses, even if they wanted to.

Sufficiently unrestrictive licenses (ex MIT) allow anybody to use the code for whatever their purpose, commercial or otherwise. Even then, prior art limits others from seizing ownership and limiting access to the original creators/contributors.

Disclaimer: IANAL but this is only my understanding from working in OSS.

Re: What Have We Learned from This Open Source Project?

#32

Post by schoen » Mon, Feb 08, 2016, 3:51 AM UTC

cyphar wrote: post #25

reitanqild wrote: post #2

> You can choose the most permissive software license, and people will still argue with you about your choice. The irony of people getting annoyed because of "missing restrictions".

I wish people would take the time to realise that the Linux kernel would not be anywhere near as reliable or widely used if Torvalds had used a more permissive license. The GPL means that all users of the software have freedom, no matter who packages the software. As a result, you end up having a single point of reference for Linux rather than 1000 proprietary forks that are all equally shit.

... although there are still proprietary forks, especially in embedded systems, because of limited resources (and apparently sometimes appetite) for GPL enforcement.

(Conservancy, one of a tiny number of organizations that does this work, has been having a lot of financial troubles lately: https://sfconservancy.org/)

Re: What Have We Learned from This Open Source Project?

#33

Post by reitanqild » Mon, Feb 08, 2016, 4:11 AM UTC

cyphar wrote: post #28

reitanqild wrote: post #23

Earlier quoted context omitted.

Could equally well happen if the code was released under GPL as long as all copyright holders agree?

In theory yes, in practice you couldn't even hope to get all of the copyright holders' permission. You'd have to surgically remove the code of everyone who didn't consent to the relicensing (good luck) and everybody would hate you for it.

Well, then you have code written for a company on company and code written under a contributor agreement.

A lot of code that ended up under free licenses has been proprietary first and while they cannot revoke the free licenses from already released code they can make their next release non-free as long as they haven't accepted outside contributions without a suitable contributor agreement.

Re: What Have We Learned from This Open Source Project?

#34

Post by wingerlang » Mon, Feb 08, 2016, 4:17 AM UTC

kuschku wrote: post #18

RKoutnik wrote: post #11

"Do not start an open source project if you need praise, warmth and love from your fellow human beings." Ugh, very true. Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. Worst is the issue reports about a fixed bug, followed by "What version do you have?" aaaaand silence. At the very least come back and close the issue.

Which is why many people now have automated bug reporting tools. Which is sad.

What's wrong with automated bug reporting tools? I am very grateful for the 100/1000s of automated reports we get, they would be near impossible to shake out of even a technical user.

Re: What Have We Learned from This Open Source Project?

#35

Post by jrochkind1 » Mon, Feb 08, 2016, 4:29 AM UTC

lotyrin wrote: post #22

RKoutnik wrote: post #11

"Do not start an open source project if you need praise, warmth and love from your fellow human beings." Ugh, very true. Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. Worst is the issue reports about a fixed bug, followed by "What version do you have?" aaaaand silence. At the very least come back and close the issue.

Yeah. Open source seldom realizes it needs the same infrastructure as a commercial product: separate project management issue queue and support issue queue. What are we doing next, what version did we fix Y in, what VCS branch are we working on Z in, who is working on X, etc. are separate from Who reported problem, what version of the product do they report having used, what did they expect and what did they get, is…

I know what you mean, but there's another side. For instance just on:

> Support tickets probably shouldn't be public, for that matter.

Open GitHub issues, combined with Google, have turned out surprisingly useful to me as a user of open source packages. Often an answer to some trouble I've run into is found in an issue -- both 'support' ticket style issues, and development roadmap style issues, and the line sometimes gets blurred.

Also, there's a positive aspect of the blurring of the boundaries in open source -- when a user contributes code, or documentation.

But yeah, people running open source projects need to at least think about how they're going to deal with project management as well as support at some point, and just the thinking about it and the iterating to figure out how to do it better is for some a chore they don't want to do. The projects that figure out how to do this well are the ones that are a joy to use or to contribute to though.

Oh, and my experience I'm talking from is with open source code packages meant for use by developers. Open source end-user applications (including OSs like Linux) are a different animal, and are _much harder_ to deal with support and project management and the overlap, in my observation. Not sure which you were thinking of, but now I'm thinking maybe end-user apps.

Re: What Have We Learned from This Open Source Project?

#36

Post by jrochkind1 » Mon, Feb 08, 2016, 4:31 AM UTC

kuschku wrote: post #18

RKoutnik wrote: post #11

"Do not start an open source project if you need praise, warmth and love from your fellow human beings." Ugh, very true. Folks forget that most FOSS work is volunteer & berating the hackers who make it won't help one bit. Worst is the issue reports about a fixed bug, followed by "What version do you have?" aaaaand silence. At the very least come back and close the issue.

Which is why many people now have automated bug reporting tools. Which is sad.

I'm not sure what you mean, what kind of tools, that are sad?

Re: What Have We Learned from This Open Source Project?

#37

Post by jrochkind1 » Mon, Feb 08, 2016, 4:36 AM UTC

jnbiche wrote: post #21

reitanqild wrote: post #19

Earlier quoted context omitted.

I guess you can take code under a permissive license, fork it and release it under a less permissive license yes. IANAL though. That is my whole point: MIT and BSD code is free-er than GPL and AGPL because you can go from MIT and BSD to AGPL but not the other way around.

No, you can't relicense someone else's MIT or BSD code, only code you've written. Only a copyright holder can license his/her code, or someone to whom the copyright holder has given explicit permission to do so.

Technically true, you can only offer a license on code you've written. But effectively you can still take a MIT/BSD project, and fork it and release as another license, legally.

The original code will still be under the permissive license. But you can take it, and fork it, and continue to develop the fork, and all your new additions can be licensed under the more restrictive one (including GPL).

To be clear about what's going on, you could put a notice saying that anything taken from Source Project X was MIT, all further changes were (GPL). Perfectly legal. But really, how would people know which parts are which except diff'ing it, they might as well just go back to the original -- or they can always diff if if they want regardless of license of course. MIT/BSD don't require attribution or anything, they just say do whatever you want with the code.

So forking and just saying "the license is [eg] GPL" is pretty much the same thing. It's legal. You can't stop people from continuing to use the original code without complying with the GPL, but your fork is GPL.

IANAL. Maybe if it ever got litigated it'd end up different. It might not get litigated, for a while.

Re: What Have We Learned from This Open Source Project?

#38

Post by jrochkind1 » Mon, Feb 08, 2016, 4:43 AM UTC

cyphar wrote: post #27

jnbiche wrote: post #21

Earlier quoted context omitted.

No, you can't relicense someone else's MIT or BSD code, only code you've written. Only a copyright holder can license his/her code, or someone to whom the copyright holder has given explicit permission to do so.

Yes you can. The MIT and BSD licenses explicitly allow sublicensing. That's part of their whole schtick and why free software people don't particularly like them (you can sublicense them to be proprietary).

The MIT license explicitly (um, er, literally, explicitly) allows sub-licensing by mentioning it. The BSD does not mention sub-licensing, so I wouldn't say it explicitly allows it. But yeah, it effectively allows it, of a fork anyway.

Re: What Have We Learned from This Open Source Project?

#39

Post by pitay » Mon, Feb 08, 2016, 5:42 AM UTC

jrochkind1 wrote: post #36

kuschku wrote: post #18

Earlier quoted context omitted.

Which is why many people now have automated bug reporting tools. Which is sad.

I'm not sure what you mean, what kind of tools, that are sad?

I think he means reporting built into the program itself, such as when the program crashes. I don't know why it is sad.

Re: What Have We Learned from This Open Source Project?

#40

Post by cyphar » Mon, Feb 08, 2016, 7:12 AM UTC

schoen wrote: post #32

cyphar wrote: post #25

Earlier quoted context omitted.

I wish people would take the time to realise that the Linux kernel would not be anywhere near as reliable or widely used if Torvalds had used a more permissive license. The GPL means that all users of the software have freedom, no matter who packages the software. As a result, you end up having a single point of reference for Linux rather than 1000 proprietary forks that are all equally shit.

... although there are still proprietary forks, especially in embedded systems, because of limited resources (and apparently sometimes appetite) for GPL enforcement. (Conservancy, one of a tiny number of organizations that does this work, has been having a lot of financial troubles lately: https://sfconservancy.org/ )

> ... although there are still proprietary forks, especially in embedded systems, because of limited resources (and apparently sometimes appetite) for GPL enforcement.

As you said the software freedom conservancy is having financial troubles (why the Linux foundation doesn't just cut them a cheque is beyond me). However, a lot of embedded systems use BSD and other such systems. And ultimately, that's not the point I was making. The point is that the GPL not allowing proprietary forks is a benefit (both from a freedom aspect, but also from a technical aspect) and has given us all much better technologies as a result. The "freedom" to make proprietary software (which is a misuse of the term) is a tiny "benefit" (I don't think it is a benefit) when compared to the end results of GPL software like Linux.