Oolite Bulletins

As in shipyard, so 'any of all' ( a lot of visual potential )

P.S. I am pm's self-restricted to one pm every three years

Not lost, but since this where discussion of licenses seems to take place:

Does anybody know what the status is of the license for NuVipers?

The original OXP on Oosat has nothing that I can see.

The original thread seems to have been lost in the Great Deletion.

Cholmondely wrote: ↑Thu May 20, 2021 12:20 pm

Does anybody know what the status is of the license for NuVipers?

One can assume that an author who uploaded his work to the expansion manager had a proper license. Sometimes, for what reasons ever, it just happened that he forgot to add it to the manifest.plist.

Complete shipyard to be found here...

https://bb.oolite.space/viewtopic.php?f=4&t=12484

from commanderxairon RX

montana05 wrote: ↑Fri May 21, 2021 12:34 am

Cholmondely wrote: ↑Thu May 20, 2021 12:20 pm

Does anybody know what the status is of the license for NuVipers?

One can assume that an author who uploaded his work to the expansion manager had a proper license. Sometimes, for what reasons ever, it just happened that he forgot to add it to the manifest.plist.

It seems quite ok to forget the license. Or why else has this field not been marked mandatory?
http://wiki.alioth.net/index.php/Manife ... ional_keys

hiran wrote: ↑Sat May 29, 2021 8:30 pm

montana05 wrote: ↑Fri May 21, 2021 12:34 am

Cholmondely wrote: ↑Thu May 20, 2021 12:20 pm

Does anybody know what the status is of the license for NuVipers?

One can assume that an author who uploaded his work to the expansion manager had a proper license. Sometimes, for what reasons ever, it just happened that he forgot to add it to the manifest.plist.

It seems quite ok to forget the license. Or why else has this field not been marked mandatory?
http://wiki.alioth.net/index.php/Manife ... ional_keys

It does not seem to be an issue nowadays. The missing licenses all seem to be from years ago.

hiran wrote: ↑Sat May 29, 2021 8:30 pm

It seems quite ok to forget the license. Or why else has this field not been marked mandatory?
http://wiki.alioth.net/index.php/Manife ... ional_keys

For my feeling it should be mandatory, probably offering CC BY-NC-SA 3.0 and the resent CC BY-NC-SA 4.0. How would you handle the conditions/clauses some authors add ?

montana05 wrote: ↑Sun May 30, 2021 1:28 am

hiran wrote: ↑Sat May 29, 2021 8:30 pm

It seems quite ok to forget the license. Or why else has this field not been marked mandatory?
http://wiki.alioth.net/index.php/Manife ... ional_keys

For my feeling it should be mandatory, probably offering CC BY-NC-SA 3.0 and the resent CC BY-NC-SA 4.0. How would you handle the conditions/clauses some authors add ?

This is like a versioning issue. If they add conditions, basically they have their own version of license.
That means they need to give it a name and put that into the manifest. Somehow we need to be able to resolve the name.

So what we could do is only accept distinct values for the manifest field. Either it is a well-known value (such as "CC BY-NC-SA 4.0"), or it must resolve to a path within the OXP so we can find the license when we need it. But such a definition has to be made, published and then can be implemented in processes and tools.

hiran wrote: ↑Sun May 30, 2021 8:52 am

montana05 wrote: ↑Sun May 30, 2021 1:28 am

hiran wrote: ↑Sat May 29, 2021 8:30 pm

It seems quite ok to forget the license. Or why else has this field not been marked mandatory?
http://wiki.alioth.net/index.php/Manife ... ional_keys

For my feeling it should be mandatory, probably offering CC BY-NC-SA 3.0 and the resent CC BY-NC-SA 4.0. How would you handle the conditions/clauses some authors add ?

This is like a versioning issue. If they add conditions, basically they have their own version of license.
That means they need to give it a name and put that into the manifest. Somehow we need to be able to resolve the name.

So what we could do is only accept distinct values for the manifest field. Either it is a well-known value (such as "CC BY-NC-SA 4.0"), or it must resolve to a path within the OXP so we can find the license when we need it. But such a definition has to be made, published and then can be implemented in processes and tools.

May I correct you, CC BY-NC-SA 3.0 does offer the possibility to add clauses (please check Super-Sidewinder for an example), I am not sure about CC BY-NC-SA 4.0, but I will update myself on that. However, a drop-down will not be able to include all variants without confusion for a non-lawyer. So, lets say, we ask for the clauses in a readme.txt to be published, if the author "forget" about that what we do ? Assume it's a plain CC BY-NC-SA 3.0 and therefore overwrite the manifest.plist ?

montana05 wrote: ↑Sun May 30, 2021 9:48 am

hiran wrote: ↑Sun May 30, 2021 8:52 am

montana05 wrote: ↑Sun May 30, 2021 1:28 am

For my feeling it should be mandatory, probably offering CC BY-NC-SA 3.0 and the resent CC BY-NC-SA 4.0. How would you handle the conditions/clauses some authors add ?

This is like a versioning issue. If they add conditions, basically they have their own version of license.
That means they need to give it a name and put that into the manifest. Somehow we need to be able to resolve the name.

So what we could do is only accept distinct values for the manifest field. Either it is a well-known value (such as "CC BY-NC-SA 4.0"), or it must resolve to a path within the OXP so we can find the license when we need it. But such a definition has to be made, published and then can be implemented in processes and tools.

May I correct you, CC BY-NC-SA 3.0 does offer the possibility to add clauses (please check Super-Sidewinder for an example), I am not sure about CC BY-NC-SA 4.0, but I will update myself on that. However, a drop-down will not be able to include all variants without confusion for a non-lawyer. So, lets say, we ask for the clauses in a readme.txt to be published, if the author "forget" about that what we do ? Assume it's a plain CC BY-NC-SA 3.0 and therefore overwrite the manifest.plist ?

If we are going to do that, should that not be added to the uploading dialogue box: that the act of uploading will automatically assign CC BY-NC-SA 3.0 as the default option unless CC BY-NC-SA 4.0 is chosen?

Cholmondely wrote: ↑Sun May 30, 2021 10:37 am

If we are going to do that, should that not be added to the uploading dialogue box: that the act of uploading will automatically assign CC BY-NC-SA 3.0 as the default option unless CC BY-NC-SA 4.0 is chosen?

Currently, we are using CC BY-NC-SA 4.0, CC BY-NC-SA 3.0 is mainly found in older packages. My idea would be that every OXP/OXZ published without a proper license will automatically get a CC BY-NC-SA 4.0, regardless of the authors thoughts and the location of the package. This would basically be an extent of regulations in place already. Like usually open for discussions.

montana05 wrote: ↑Sun May 30, 2021 9:48 am

hiran wrote: ↑Sun May 30, 2021 8:52 am

montana05 wrote: ↑Sun May 30, 2021 1:28 am

For my feeling it should be mandatory, probably offering CC BY-NC-SA 3.0 and the resent CC BY-NC-SA 4.0. How would you handle the conditions/clauses some authors add ?

This is like a versioning issue. If they add conditions, basically they have their own version of license.
That means they need to give it a name and put that into the manifest. Somehow we need to be able to resolve the name.

So what we could do is only accept distinct values for the manifest field. Either it is a well-known value (such as "CC BY-NC-SA 4.0"), or it must resolve to a path within the OXP so we can find the license when we need it. But such a definition has to be made, published and then can be implemented in processes and tools.

May I correct you, CC BY-NC-SA 3.0 does offer the possibility to add clauses (please check Super-Sidewinder for an example), I am not sure about CC BY-NC-SA 4.0, but I will update myself on that. However, a drop-down will not be able to include all variants without confusion for a non-lawyer. So, lets say, we ask for the clauses in a readme.txt to be published, if the author "forget" about that what we do ? Assume it's a plain CC BY-NC-SA 3.0 and therefore overwrite the manifest.plist ?

I do not think CC BY-NC-SA 3.0 refers to a document that you can modify on the fly. So if you add something you get a document that may be based on CC BY-NC-SA 3.0 but that differs. Hence it is a new document.

I also agree that a drop-down with a few well-known license names will suffice. But a simple drop-down suggesting some values and still allowing user input will suffice. Either the user picks one of the suggested values or enters his own one.

Now for the OXPs where the author did not specify any: We should make him specify something. If he/she/it refuses or is unreachable, a first method might be to take the respective OXPs from the expansion manager. Either until the license issue is fixed or until someone created a replacement. This has been the process in many open-source projects when they stumbled over incompatibiliy in copyrights.

I have other questions:

What do we do with OXPs that come with unknown fields (e.g. licence - obviously a typo that should be license)?

What do we do with OXPs where manifest content and Expansion Manager list show different data? (e.g. Taranis, where the minimum required version from the OXP is 1.74 while the Expansion Manager thinks it is 1.79)?

hiran wrote: ↑Sun May 30, 2021 6:33 pm

What do we do with OXPs where manifest content and Expansion Manager list show different data? (e.g. Taranis, where the minimum required version from the OXP is 1.74 while the Expansion Manager thinks it is 1.79)?

Don't have any answers to your questions, but the manager saw daylight in Oolite version 1.79. Hence that's the lowest you can go.

hiran wrote: ↑Sun May 30, 2021 6:33 pm

... licence - obviously a type that should be license...

Depends which country you're from/in - I believe both spellings are used.